How to Use Jellyfin with TorBox and a Debrid-Based Library

Jellyfin and debrid can work together, but not in the way many people expect.

If you come from Stremio, your brain wants one thing. Pick a title, hit play, stream from cached sources on demand. That model works because Stremio is a playback client. Jellyfin is not that. Jellyfin wants files, folders, metadata, posters, watched states, collections, users, and a library that feels stable. It wants to manage media, not chase a stream link every time you press play.

That difference matters more than people think. I see a lot of users assume there must be a neat plugin that makes TorBox content appear inside Jellyfin like magic. I wish that were true. It is not. You can make the setup work, but you need to pick the model that fits how you watch.

If your goal is fast on-demand playback, Stremio with TorBox is the cleaner path. If your goal is a family Jellyfin server with posters, watch history, request tools, and media managers doing the heavy lifting in the background, you are talking about a deeper stack. That stack can be powerful. It can also become the kind of hobby that eats your Saturday afternoon.

Before you start, it helps to understand what a debrid service does in this chain. If you want a refresher on the basics, this guide on what a debrid service is and how it works gives the short version.

Why Jellyfin and Stremio are not the same use case

With Stremio, the app acts like a search-and-play frontend. You choose something, an addon finds sources, your debrid account checks what is cached, and playback starts. The media does not need to sit in a tidy library on your server. The app handles the moment.

With Jellyfin, you are building a home media system. You care about folders. You care about naming. You care about whether a TV season lands in the right place and whether episode metadata matches. You care about resume progress and what your family sees on the home screen. That is a very different mood. More polished, more controlled, and yes, more work.

I think this is where people get tripped up. They ask for “Jellyfin with debrid” when they mean “I want Stremio convenience inside Jellyfin.” That gap is the hard part. Jellyfin works best when it can scan a storage location and treat it like a normal library. So the task is not direct streaming from TorBox into Jellyfin. The task is making TorBox-backed content look enough like a normal media library that Jellyfin can manage it.

Approach 1 using Stremio with TorBox and keeping Jellyfin separate

This is the path I would point most people toward, even if it is not the flashy answer.

You use Stremio with TorBox for on-demand viewing. Then you use Jellyfin for your local files, ripped discs, home videos, curated collections, or media you already store on your server. The two apps do not need to integrate. They can sit side by side and do different jobs.

That sounds almost too plain, but plain is underrated. If you want both experiences, this split setup gives you both without forcing one app to pretend it is the other. Stremio stays fast and disposable. Jellyfin stays organized and stable.

If you need help with the Stremio side, this Stremio setup guide is a solid place to start. If you are set on TorBox, you can sign up here and use it as your debrid layer for Stremio playback and the advanced Jellyfin route later on if you choose to build it out: https://torbox.app/subscription?referral=646f833b-88b3-48c3-a2ba-555229a3011c.

The upside is obvious once you live with it for a bit. Stremio handles instant watch requests. Jellyfin handles the media you want to preserve and present cleanly. No weird mounts. No fake download client layer. No trying to explain to someone in your house why a title vanished because a remote cache expired.

The downside is that your watched history and media discovery live in two places. Some people hate that. I get it. It feels messy. Still, for casual users, this covers almost the whole need. You get debrid streaming when you want speed, and you get Jellyfin when you want a proper server. I would take this trade most of the time.

Approach 2 building a Jellyfin library on top of TorBox

This route is for people who already think in terms of Radarr, Sonarr, indexers, request apps, and mounted storage. If that sentence felt normal to you, keep going. If it felt like a foreign language, Approach 1 is probably your answer.

The architecture looks like this. Radarr and Sonarr manage movies and shows. Prowlarr feeds indexers into them. Decypharr, or CatBox if you use ElfHosted, sits between the arr apps and TorBox. It presents itself as qBittorrent, so Radarr and Sonarr think they are talking to a standard download client. Behind the scenes, it routes those download jobs to TorBox. TorBox handles the remote download and cache. You mount TorBox storage over WebDAV using webdav.torbox.app. Jellyfin scans that mounted storage as a normal media library.

When it works, it feels clever. Maybe a little too clever. But clever can be enough.

Step 1 set up Jellyfin and decide where the library will live

Start with a working Jellyfin server. If you are still building that part, this guide to installing Jellyfin with Docker Compose can save time. Pick the host where you want your mounted TorBox storage to live. That might be the same machine as Jellyfin, or a separate box that shares the mount over your network.

I prefer keeping the mount on the same host as Jellyfin if possible. Fewer moving parts. Fewer weird permission issues. Less chance you forget which machine owns what.

Create library folders that match how Jellyfin likes to read media. A movies path and a shows path are enough to start. Keep the naming plain and predictable.

Step 2 connect Radarr Sonarr and Prowlarr

Radarr manages movies. Sonarr manages TV. Prowlarr sends indexers into both. This part follows the same pattern as a standard arr stack. Add your indexers in Prowlarr, sync them to Radarr and Sonarr, then set quality profiles and root folders.

The difference comes later at the download client layer. You are not pushing jobs to qBittorrent or SABnzbd. You are pushing them to a bridge that pretends to be qBittorrent while handing work off to TorBox.

If you already run the arr tools for local downloads, this part will feel familiar. If not, expect a learning curve. The arr stack is powerful, but it has that “one checkbox away from chaos” energy. You need patience.

Step 3 add Decypharr or CatBox as the download client bridge

This is the piece that makes the setup possible.

Decypharr acts like a qBittorrent-compatible endpoint. Radarr and Sonarr can talk to it using the usual download client settings. Decypharr then routes magnet or torrent jobs to TorBox. CatBox on ElfHosted serves a similar role and may be easier for people who want less self-hosting overhead.

Why does this matter? Because Radarr and Sonarr expect a download client they understand. They do not know how to speak directly to TorBox. The bridge translates the workflow into something the arr apps can use.

You will need to configure the bridge with your TorBox account details, make sure the qBittorrent API emulation is reachable from Radarr and Sonarr, and test that a manual request moves through the queue. Do not skip the manual test. If the bridge fails here, the rest of the stack does not matter.

Step 4 send downloads to TorBox and mount storage over WebDAV

Once the bridge can pass jobs into TorBox, you need a way for Jellyfin to see the resulting files. This is where WebDAV comes in. TorBox exposes storage through webdav.torbox.app, which you can mount on your server using your OS tools or a container-friendly mount method.

After the mount is in place, point Radarr and Sonarr root folders to paths that map cleanly to what Jellyfin will scan. If your bridge and mount agree on folder structure, imported media can appear where Jellyfin expects it.

This part can feel fragile. WebDAV is handy, but I would not call it graceful under stress. Network hiccups happen. Mounts can drop. File locking can get weird. Keep that in mind before you trust it like local SSD storage.

When TorBox is doing the debrid side of the stack, this is the account layer everything depends on, from cached downloads to WebDAV access: https://torbox.app/subscription?referral=646f833b-88b3-48c3-a2ba-555229a3011c.

Step 5 point Jellyfin at the mounted folders and tune scanning

Add the mounted movie and TV folders as Jellyfin libraries. Let Jellyfin fetch metadata, posters, cast info, and episode data as it would with local files. This is the payoff. Once content lands in the mount with proper names, Jellyfin can present it like a normal server library.

Still, I would avoid aggressive scan schedules. TorBox has a 30-day cache expiry policy. If your setup depends on files staying present forever, you are going to get annoyed. A title can vanish from remote storage after inactivity, and then Jellyfin sees a missing file. That means broken items, stale metadata entries, or libraries that need cleanup.

This is where CatBox has a smarter angle than a plain continuous scan model. Its lazy-materialization approach means media gets materialized closer to when it is needed, instead of trying to hold a giant permanent remote library together through constant scanning. For a debrid-backed library, that makes more sense to me. Trying to force remote cache into behaving like long-term NAS storage feels like picking a fight with the wrong problem.

What this setup is good at and where it gets annoying

When Approach 2 is humming along, it can feel close to the dream. You request a movie through Jellyseerr or Overseerr. Radarr picks it up. Prowlarr finds sources. The bridge sends the job to TorBox. The file appears through WebDAV. Jellyfin scans it, fetches art, and your users see a polished library entry with watch tracking and metadata. That is a strong setup for a shared home server.

It also has weak spots. Remote mounts are less predictable than local disks. Debrid cache is not permanent storage. The bridge layer adds one more service that can fail. The arr stack likes consistency, while debrid systems are built around availability and cache state. Those goals overlap, but they are not twins. You feel that tension after a while.

I do not say that to scare you off. I say it because this setup attracts people who enjoy solving systems. If that is you, it can be satisfying. If you want a quiet life, it can be maddening.

Who should use Approach 2

Approach 2 makes sense if you already run Radarr and Sonarr, want automated library management, and treat Jellyfin as the center of your media setup. It fits shared family servers. It fits homes where users send requests through Jellyseerr or Overseerr. It fits people who care about a clean poster wall and one place for watch history.

It also fits tinkerers. I mean that with affection. This is a tinkerer stack. You are stitching together tools that were not built as one native Jellyfin feature. You can get a polished result, but you earn it.

If your goal is to sit down, search, and play with the least friction, Approach 1 is the safer call. I keep coming back to that because it saves people from building a machine they do not need.

A practical way to choose

Use this test. Ask yourself what would annoy you more.

If it would annoy you more to switch between Stremio and Jellyfin, Approach 2 may be worth the effort.

If it would annoy you more to maintain WebDAV mounts, bridge services, import paths, and cache expiry edge cases, stick with Approach 1.

That sounds blunt, but blunt is useful here. For casual viewers, Stremio plus TorBox handles almost the whole job. For power users with an arr stack and a shared Jellyfin server, the advanced route can turn debrid-cached content into something that feels like a managed library. It is a clever setup. It is also a commitment.

And if you do build it, give Jellyfin the finishing touch it deserves. A polished server feels better to use, and that is half the point. If you want your interface to feel more cinematic, take a look at these Jellyfin preroll videos and this guide to Jellyfin cinema mode and preroll setup.