Version goes from 5.0.0.dev0 to 5.0.0 in the four places that carry it. `system.check_updates` now defaults to on. It was off with the note "the user opts in rather than being opted in", which is the right instinct aimed at the wrong thing: the check is made by the operator's browser and never by the server, so it carries nothing about the deployment. What it opts you into is finding out you are out of date, and an instance that never learns that is the more common harm on a self-hosted tool. Air-gapped boxes turn it off. Added the notice that goes with it: after signing in, once per 24 hours per browser, a modal if a newer release exists. Never for the demo account — a visitor cannot upgrade anything, and telling them how the operator runs their box is a small leak for no benefit. The comparison moved to lib/version.ts and got fixed on the way. The old one was an equality check that treated *anything* different as newer, so an instance built from main at 5.1.0.dev0 was told to upgrade to the older 5.0.0. It now understands that a pre-release is behind the release of the same numbers, which is exactly the 5.0.0.dev0 → 5.0.0 case this release creates. Seven cases checked, including that one. Both READMEs get an Updating section: pull, migrate, up, and the fact that named volumes mean the identity pool and archive stay put. Also two files for publishing releases — a bilingual template and the 5.0.0 notes written against it. English first, breaking changes above the feature list, and every entry says what the reader should do. Not committed here: nothing is tagged or published yet.
Documentation
Everything you need to run, use, operate and contribute to a self-hosted Douyin_TikTok_Download_API v5 instance.
中文文档:README.zh-CN.md — every page here exists in both languages and they say the same thing.
Start here
If you have never run this before, read these three in order. They take about half an hour and leave you with a working instance you understand.
| Page | What you get | |
|---|---|---|
| 1 | Quick start | The stack running on one host, an administrator account, and one link parsed — from the console and from curl |
| 2 | Concepts | The mental model: identities, signing, scheduling, tasks. Enough to predict what a request will do before you send it |
| 3 | Console overview | Finding your way around, and the four pages that tell you whether the instance is healthy |
By what you are trying to do
Deploy and configure it
- Installation and deployment — the compose file service by service, every
DTK_*variable, profiles, reverse proxies, upgrading, running without Docker - Configuration reference — the two configuration layers, and all 54 runtime settings with defaults and when to change them
- Security — what the software protects, what you are responsible for, and which operations hand out a credential
Use the console
- Console overview — the shell, Overview, System, Logs, Diagnose
- Identities and proxies — the pool, its state machine, minting, importing cookies, proxies, the Scheduler and Endpoint access pages, and the circuit breakers
- Playground and tools — driving any endpoint from the browser, signing, decoding a signature, parsing links, minting on demand
- Downloads, library and watchlist — putting media on your own disk, finding it again, and collecting a target on a timer
- Users and API keys — roles, scopes, keys, and who can do what
Every entry in the sidebar is covered by one of these pages, and
Console overview
carries the table that says which: Scheduler (/scheduler) and Endpoint
access (/endpoint-access) are in Identities and proxies, and Backup
(/backup), Notifications (/notifications) and Settings (/settings) are
in Operations.
Build against it
- REST API guide — authentication, the uniform envelope, the asynchronous model and
?wait=, paging, errors, worked clients in three languages - MCP and AI agents — pointing Claude Code, Claude Desktop, Codex or Cherry Studio at your instance
- CLI reference — every
dtkcommand and option
Keep it running
- Operations — the Settings, Backup and Notifications pages: backups and restore drills, alert channels, retention, monitoring, capacity, safe upgrades
- Troubleshooting — symptom, cause, fix, plus the complete error-code table
- FAQ and glossary — the questions people ask before deploying, and every term this documentation uses
Change the code
- Contributing — development environment, repository layout, the test layers, the quality gates a change has to pass
The full set
| Page | ||
|---|---|---|
| 01 | Quick start | From nothing to a first successful request |
| 02 | Installation and deployment | Compose, environment, profiles, upgrades |
| 03 | Configuration reference | All 54 runtime settings |
| 04 | Concepts | The mental model |
| 05 | Console overview | Shell, Overview, System, Logs, Diagnose |
| 06 | Identities and proxies | The pool and the scheduler |
| 07 | Playground and tools | Playground, Tools, API docs |
| 08 | Downloads, library and watchlist | Keeping content |
| 09 | Users and API keys | Access control |
| 10 | Operations | Day two and after |
| 11 | REST API guide | Calling the HTTP API |
| 12 | MCP and AI agents | AI clients |
| 13 | CLI reference | The dtk command |
| 14 | Troubleshooting | When something is wrong |
| 15 | Security | Threat model and responsibilities |
| 16 | Contributing | Working on the code |
| 17 | FAQ and glossary | Questions and terms |
What is not here
The endpoint reference. Every endpoint, parameter, constraint and response
shape is generated from the code that serves the requests, so it is never out of
date and there is no copy of it to go stale. Your own instance serves it at
/docs inside the console, and at /swagger, /redoc and /openapi.json —
none of them needs a login. Both languages: append ?lang=zh.
The REST API guide is the companion to that reference — it
explains the things a list of endpoints cannot, like what a 202 means and when
retrying can help.
A note on accuracy
Every command, setting name, default value, endpoint path and error code on these pages was checked against the source it describes. If you find one that is wrong, that is a bug worth reporting — please open an issue and say which page and which line.
Getting help
- Issues — public, keeps its history, and anyone who has hit the same thing can answer
- Email
Evil0ctal1985@gmail.com— reaches one person; best for anything that does not belong in public
Read Troubleshooting first, and include the output
of the Diagnose page or dtk diagnose with whatever you report. It answers most
of the questions a maintainer would otherwise have to ask you. If the stack will
not start there is no api container to run the self-check in and neither surface
can answer — say so, and send
docker compose -p dtk -f docker/compose.yml logs instead.
