Files
Evil0ctal b4f6ff5c15 feat: 5.0.0, and tell people when there is a newer one
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.
2026-09-10 07:07:35 -07:00
..

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.

The DTK console

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

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 dtk command 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.