Tdarr and Unmanic on a Seedbox: Which Library Jobs Are Worth Running

What these two do, and what they are not

Tdarr and Unmanic are library optimisers. You point them at your media folder, tell them what a good file looks like, and they work through everything you own, converting whatever doesn't match. Then they keep watching, so new files get the same treatment.

That is not the transcoding your media server does. Plex and Jellyfin transcode live, once per stream, when a client can't play a file as it is. Tdarr and Unmanic rewrite the file on disk so that transcode never has to happen again.

One thing to be clear about first, because it catches people out. The Transcodes column on our plans page is about the live kind: 2 on Appbox Lite at 5 euros, up to 10 on the 18 TB plan. That is your media server's streaming headroom, and these two don't spend it. They spend CPU on a box you share with other people, which is a different budget with different rules.

The difference that decides it on a shared box

Tdarr is the bigger project, 4,335 stars against 2,510, and its README calls it "Distributed transcode automation using FFmpeg/HandBrake + Audio/Video library analytics + video health checking".

The word doing the work is distributed. Tdarr is two pieces: "Tdarr_Server - Central process which all Nodes connect with" and "Tdarr_Node - Processes running on same/other devices which collect tasks from the Server". The idea is that you run the server on one machine and throw work at it from several others, so your gaming PC's GPU chews through the queue overnight.

On our boxes you get one node, the one inside the container. Tdarr exposes three ports: 8265 for the web UI, 8266 for the server, 8267 for nodes. Our install publishes 8265 only, so a node running on your laptop at home has nothing to connect to. We also set internalNode=true, because without it the server comes up with zero workers and nothing transcodes at all.

So the headline feature, the one that makes Tdarr the better-known of the two, is the one our install can't give you. Unmanic has no node concept at all, so with Unmanic you lose nothing. That's not a reason to skip Tdarr. It's a reason to stop picking it for that reason.

Which jobs are cheap and which are not

Here is the part nobody writes down, and it's the only question that matters on a shared box. Ask one thing of any job you set up: does it re-encode the video? If it doesn't, the job is close to a file copy and you can run it across your whole library tonight. If it does, you are committing a core to that file for as long as it takes, and a library-wide run is a week of it.

Start with the third row. Image-based subtitles, the PGS tracks you get on Blu-ray rips, are one of the most common reasons a media server burns a transcode on a file that would otherwise direct play. Pulling them out to a sidecar costs almost nothing and buys back streaming headroom you already pay for. More on that in the 4K and transcoding guide and in do you need a GPU for Jellyfin.

The last two rows are where people get into trouble. Converting a library to HEVC to save disk can pay for itself, but the cost isn't a number you look up. It's hours of a shared CPU per film, and you own the consequences.

The cache is the part that bites

Both apps work the same way underneath: they write the new file somewhere else, check it, then put it back. That "somewhere else" is the cache, and it is the single setting that decides whether these apps are pleasant or miserable on a seedbox.

Unmanic's docs call it the place where "task files will be temporarily stored while workers are carrying out jobs on them", and upstream's Docker example mounts three volumes: config, library, and a third for the cache at /tmp/unmanic.

Our Unmanic install mounts the first two and not the third. Your config lands in ~/.config/unmanic and your library at ~/media, but the cache is left at its default inside the container. That is a different filesystem from your media, so every finished file has to be copied back across a device boundary instead of just being renamed into place. On a 40 GB film that is the difference between instant and several minutes, repeated for every file in the queue.

So the first thing to do after installing Unmanic is open Settings, find the cache path, and point it at a folder under /config, which is ~/.config/unmanic on your box. Same disk as your media, so the move back becomes a rename. The trade is that the cache then counts against your storage quota, so leave room for it.

Tdarr is already wired the right way. We set TMPDIR to a /temp mount under ~/.config/tdarr, same disk as your media, so any library you create defaults its transcode cache there. The catch: Tdarr fixes that path when the library is created and keeps it. If an older Tdarr library crawls on the very last step, that's why, and recreating it is the fix.

How many workers, and the bit of the terms that applies

Unmanic's worker count goes from 0 to 12. Its docs are blunt about it: "For most people, there is no benefit to running more than 3-5 workers total across all groups", and "start with one worker initially, and then increase this value slowly".

On a shared box, start with one and mostly stay there. Each worker holds the file it is reading and the file it is writing at the same time, so cache use scales with worker count, and so does the chance of filling your disk mid-job.

One line in our terms applies directly, and it isn't the bandwidth one. We reserve the right "to change any custom settings that are made and to disable you if you make the server unusable for other members". Unmetered covers traffic, and the fair use rule there is a bandwidth rule: "you can not exceed 3 times the amount of bandwidth an average user uses during a given month, on a given plan". Neither is about CPU. The unusable-for-others line is, and eight Tdarr workers grinding HEVC for a fortnight is what it's written for.

Nobody is going to shout at you for converting your library. One worker, overnight, jobs from the top half of that table, and this never becomes a conversation.

How the install is wired here

Both are Docker apps, so they follow the same shape as the rest of our container apps: one click, own subdomain at tdarr.USERNAME.SERVER or unmanic.USERNAME.SERVER, password in front. What each can see:

• Tdarr gets your media at /media. Its library source folder is free text, so you can add more than one.
• Unmanic gets the same folder at /library, and it supports more than one library path.
• If your account has a Flexdisk, both get it at /flexdisk, read and write, so you can add it as a second library. Read and write because both of them replace the source file in place.

Three things worth knowing before you start:

1. Don't change PUID. We set PUID=0 and PGID=0 on purpose. Under rootless Docker, container user 0 maps to your own account on the slice, so finished files land owned by you. Any other value maps into a range that doesn't own ~/media, and the write-back fails with a copy error that looks like a permissions bug in the app.
2. An upgrade keeps your settings, an uninstall deletes them. Config lives in ~/.config/tdarr and ~/.config/unmanic. Upgrading stops the container and rebuilds it around the same folder. Uninstalling removes the folder, and your flows, plugin stacks and presets go with it. Export first.
3. Both images track latest. An upgrade pulls whatever upstream published, so read the release notes before you click it on a library you care about.

Plugins, and one licence difference

Tdarr has two plugin systems side by side, which is confusing until somebody says it out loud. Its docs put it plainly: "Classic plugins are an old type of plugin which can either be used in a plugin stack or a flow", while "Flow plugins are new type of plugin with more capability and can only be used in Tdarr Flows". Stacks are the older list of steps, flows are a graph with branches, and a flow can call a classic plugin. Starting today, start with flows.

Unmanic has one plugin system and a much shorter menu. Its docs call the whole app "a simple tool for optimising your file library", which is a fair summary of the difference.

If licensing matters to you: Unmanic is GPL-3.0, and GitHub reports no standard open-source licence for Tdarr. Unmanic's last release was v0.4.1 on 14 August 2026; Tdarr publishes no GitHub releases at all, so its Docker tag is the version.

Which one should you install

Unmanic if you want the library tidied and then want to stop thinking about it. Smaller, GPL, four moving parts (scanner, file monitor, task handler, web UI), and one thing to fix after install, which is the cache path above.

Tdarr if you want to see what's actually in your library before you change any of it. The analytics and the health check are the real reasons to pick it, not the distributed transcoding you can't use here. Flows are more capable once you want conditions.

Neither if you have one file to fix. Install Remux from the app catalogue, or run ffmpeg over SSH.

One piece of advice for both: run a new preset against five files before you turn it loose on twelve terabytes. Both apps replace the source file, and getting the audio mapping slightly wrong across a whole library is the kind of afternoon nobody enjoys.

What's next?

• 4K transcoding on a seedbox: GPU vs CPU
• Do you need a GPU for Jellyfin?
• The complete Arr stack guide
• Plex vs Jellyfin on a seedbox
• Why your seedbox is slow