Version 5 turns a downloader into a self-hosted data service
Version 5 accepts Douyin and TikTok posts, profiles, playlists, comments, short links, and share text, then places 93 REST operations over the resulting service layer. Requests are asynchronous by default, returning HTTP 202 and a task identifier, while a wait option restores a synchronous call. Parsed records can enter a PostgreSQL archive, and the same host can schedule repeat collection, save media, expose a CLI, and serve a React console.
The current default README is English, and the documentation directory contains 17 pages in both English and Chinese. This matters because older impressions of the project no longer describe main accurately. The v5 branch is a rewrite with an identity pool, API keys, roles, Redis work queues, and stored content. It also removed Bilibili, and Douyin follower and following endpoints are absent because they require a signed-in session.
Four signing methods still depend on changing upstream behavior
Douyin_TikTok_Download_API implements a_bogus, X-Bogus, X-Gnarly, and X-Dynosaur signing in Python, with a browser fallback. Guest identities can be minted through a headless browser, checked for health, rotated by the scheduler, and retired when they stop working. Imported signed-in cookies can widen access. The security policy still treats changed signatures and dead endpoints as upstream breakage.
What happened when we ran it
Our sandbox installed commit bcbbfa1 in 52 seconds, adding 98 packages and occupying 219 MB. The build succeeded in 9 seconds. The run used a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and a Python 3.12 uv image. Pip-audit reported 0 known vulnerabilities in the installed packages.
Pytest exited with code 1 after 36 seconds. It reported 2,472 passed, 7 failed, 465 skipped, and 19 collection or setup errors of 2,498. The supplied summary names failures in internationalization, public-endpoint rules, and demo access checks, but every shown line ends with dtk.core.crypto.SecretKeyMissing. Our scan also found 3 CI workflow files, a tests directory, and no Dockerfile.
A missing 32-character secret stopped the test suite
DTK_SECRET_KEY must be present and at least 32 characters, according to both the test log and the current security documentation. The lab deliberately supplied no secrets, so the observed result is straightforward: the checkout built, then its test command did not pass in that environment. The log does not establish that adding a key would clear all 7 failures and 19 errors, so a configured rerun belongs in any adoption check.
The guided installer and manual example both generate credentials rather than shipping defaults. A deployment needs the master key, a PostgreSQL password, and a Redis password before its services start. Changing the master key later makes stored cookies and proxy credentials unreadable. That makes secret backup part of ordinary operations, not a one-time setup detail, especially when the archive and identity pool are meant to survive upgrades.
Docker Compose adds databases and a TLS boundary
The current README recommends Docker Compose and documents application, worker, migration, database, Redis, browser, and downloader responsibilities. PostgreSQL 17 must include TimescaleDB, while Redis 8 carries queues and short-lived state. Published images cover linux/amd64 and linux/arm64; the optional browser image is built locally from a pinned CloakBrowser commit. The lab signal that found no Dockerfile describes commit bcbbfa1, while the current README describes container files under docker/.
A manual install needs Python 3.12 and uv, plus Node 22 when the console is built. It also makes the operator recreate the container controls and service supervision. Public exposure requires another layer: the application does not provide TLS, redirect HTTP to HTTPS, or set HSTS. The security guide recommends leaving port 8000 on loopback and placing a configured reverse proxy in front, with trusted forwarded-address handling.
MCP keeps all 93 operations behind an API key
MCP always requires an API key, even when an operator opens selected REST endpoints publicly. It shares parsing, tasks, archive searches, and downloads with REST and the CLI. Roles run from demo through viewer and operator to admin, while key scopes narrow what a caller may do. Two sensitive options can return an identity's cookies or a signed upstream URL, so v5.0.1 keeps them operator-only and disables them in the demo playground.
Version 5.0.1 fixed demo controls and shipped the same day
Release v5.0.1 arrived on September 11, 2026. Its main user-facing fix cut the demo navigation from 20 visible entries to the 11 that a read-only visitor could use, instead of showing pages that answered 403. The release also corrected a mobile drawer, a 62-pixel overflow on the tools page, and two console code defects. Those details show active attention to the public demo.
GitHub recorded the last push on September 11, 2026, and listed 20,064 stars with 1 open issue and pull request combined. That remaining item asks for collection details and a collection identifier parameter, rather than reporting a system-wide failure. Same-day code and release activity support a healthy maintenance judgment. The low open count is still only a queue snapshot, not proof that every upstream endpoint currently works.
The 2,472 passing tests justify a configured trial
Our run got 2,472 tests through before pytest finished with 7 failures and 19 errors tied in the visible log to the absent master secret. That is substantial exercised code, yet the exit status matters. Teams that need the full REST, MCP, archive, and scheduling stack should rerun with an isolated test secret, exercise their own Douyin and TikTok requests, and plan for upstream repairs. Anyone who mainly wants media files should choose the smaller operational surface of yt-dlp or a focused downloader.