No login yet, one worker per machine, and a quick start that stops in the middle of a line

The web interface has no login, and the server is published on a host port

Under the planned features list, the fourth item is user sessions, described as logging in required to access the web interface, and it sits in the not yet implemented column. The current features column has the web interface itself, a job queue, bulk job creation for videos in the same directory, preset management with upload, rename and delete, and directory watchers that create jobs automatically on criteria. So the set of things reachable without authentication is not a read only view: a visitor can queue encodes, replace the preset files the workers use, and register a watcher that fires on new files. The quick start then maps the server to host port 9999 with a plain `9999:9999` mapping and no proxy, no TLS and no credential in front of it. Anyone who can reach that port has the whole control surface. The project does say up front that it is under heavy development and to use it at your own risk, and it points at a known issues section for the detail.

The quick start block ends inside the worker's user comment

The fast path is a compose file with two services, and the copy of it in the README does not survive to the end. The server is complete: image `ghcr.io/thenickoftime/handbrake-web-server:latest`, container name handbrake-web-server, `user: 1000:1000` with a comment explaining that it should be edited to a uid and guid with permission to reach the media, and that `0:0` runs as root which is not recommended, then the port mapping and two volumes, your data at `/data` and your media at `/video`. The worker block names `ghcr.io/thenickoftime/handbrake-web-worker:latest` and sets the container name, then the file ends in the middle of the same kind of user comment:

user: 1000:1000 # edit to run as user (

The server's volume comment says to ensure the media path is the same across all containers, which is exactly the instruction the truncated worker block should have carried. Anyone pasting this file gets a worker with no volumes of its own.

The server is cheap, the worker is not, so one worker per machine

The two components are split by cost, and the split is stated in bold in the summary. The server acts mainly as a coordinator for the workers and additionally serves the client interface, and the work it does is not computationally expensive, so it can run on low end or low power devices with no issue. The worker does the heavy lifting through HandBrakeCLI, receives jobs from the server, and processes media according to a provided preset configuration. That work is described as very computationally expensive, and the recommendation is a single worker instance per machine, with the machine either having a high core count CPU or having GPU hardware encoding features available to the worker. So the scaling story is horizontal by machine, not by process: adding a second worker container to one box splits the queue between two processes on the same hardware, while adding machines is what actually adds throughput.

Presets still come out of the desktop app, and creating one is planned

The encoding configuration is not authored here. HandBrake Web uses presets configured in the desktop application of HandBrake and exported to .json files, and those exported files are uploaded through the web interface in the Presets section. The first item on the planned list is a preset creator that would build presets directly in the browser, so today the workflow is: open HandBrake on a machine with a display, configure and export a preset, then upload the file. The second planned item is uploading video files to the server through the interface, which means the source material reaches this platform by some other route, since the worker mounts your media path from the host. The third planned item is AMD VCN. The fourth is the user sessions already discussed. Hardware acceleration for the two vendors that are supported is described as needing additional configuration, with the details deferred to a wiki page.

The same hardware acceleration bullet appears under both lists

Look at the two feature lists side by side. The current features column ends with hardware accelerated encoding, described as using a GPU to speed up encoding times, with sub items for Intel QSV on discrete and integrated Intel hardware and NVIDIA NVENC on discrete NVIDIA hardware. The planned features column opens with a bullet whose parent text is identical, the same words about using a GPU to speed up encoding times, and its only sub item is AMD VCN for discrete AMD hardware. So the identical heading is doing two jobs, and a reader scanning for whether GPU support exists finds the same line in both lists. The sentence explaining that AMD support is planned spells it as not yet implimented, a typo that also makes the line easy to skim past. The disclaimer at the top of the file is worth repeating here, because this project is not related to or part of the official HandBrake development and simply uses the HandBrake CLI component underneath.

The manifest points at a personal git host and ships a branch deleting script

The root manifest is a workspace shell. It is named handbrake-web, sits at 0.8.1, which matches the newest release tag, describes itself with the single word HandBrake Web, and pins pnpm 10.16.1. It carries no dependency list at all, which is what you would expect from a file whose scripts are all `cd` into a sub package. Two entries are worth a second look. The repository field is a URL on `git.goodforyou.games` for a user called ncunningham, not the github.com address the project lives at, so anything that clones from the manifest does not clone the repository you are reading. And the last script, `git:cleanup`, checks out main, fetches with prune, then pipes every branch except main through `git branch -D`, which force deletes local work without asking. The tree is four packages, client, server, shared and worker, plus a compose directory, a handbrake directory, docs, a devcontainer and an editor configuration.

Two releases in December 2025, then a push in March 2026 and nothing since

The release cadence is short and then stops. v0.7.3 is dated 2024-11-27, v0.8.0 is dated 2025-12-09 and v0.8.1 is dated 2025-12-10, so the 0.8 line shipped across two consecutive days after a year of nothing. The last push to the main branch is dated 2026-03-27, roughly three and a half months after that release and about six months before now, and no release has been published since v0.8.1. Two smaller things sit in the same file. The badge row at the top contains two links to the same milestone, the identical milestone 7 URL appearing twice, so one badge is either a mistake or a placeholder for something that was never filled in. And the contributing line points at `./CONTRIBUTING.md`, which exists in the tree, under a link text that misspells it as CONIBUTING. For a separate tool, the project also publishes a minimal HandBrakeCLI image at `ghcr.io/thenickoftime/handbrake-cli`, described as a bonus made simple by reusing the outputs of the main build.

Editorial conclusion

Handbrake Web fits a home lab where encoding should run on a machine with a GPU and be triggered from a browser, and where you are willing to keep the HandBrake desktop app around for authoring presets. Do not expose the server to a network you do not control, because login is a planned feature rather than a shipped one, and the interface can upload, rename and delete presets and create automatic watchers on top of that. Before the first run, read the setup wiki page in full, because the quick start block in the README is incomplete, and complete the worker service yourself with the media path the comment insists must match across containers. Check the image tags too, since both services are pinned to latest. The last release is v0.8.1 dated 2025-12-10 and the last push to main is dated 2026-03-27.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. TheNickOfTime/handbrake-web on GitHub