Now make them talk to each other.

Recent versions no longer ship a fixed default password. One is generated on first start and written to the log:

docker compose logs qbittorrent | grep -i password

In Arcane, open the qBittorrent container and read its logs — the line is near the top.

1. Open http://your-server:8080 and sign in as admin with that password.
2. Go to Tools → Options → Web UI.
3. Set a real username and password under Authentication.
4. Tick Bypass authentication for clients on localhost only if you understand it. Leave it off otherwise.

Under Tools → Options → Downloads:

These are paths inside the container. With the shared layout, /data is your DATA_ROOT, so /data/downloads is really /srv/data/downloads on the host.

Categories put each app's downloads in their own subfolder and let each app see only its own work. You do not need to create them by hand — when you connect Sonarr, it creates tv-sonarr for you, Radarr creates radarr, Lidarr creates lidarr.

To check afterwards, look at the left sidebar in qBittorrent. If a category is missing, the connection from that app is not working.

Seeding and cleanup

Under Tools → Options → BitTorrent you can set a share ratio and what happens when it is reached. Pausing rather than deleting is the safe default — hardlinked files are safe to remove, but if you are not using hardlinks, deleting the torrent deletes the file your library points at.

The generator can produce a deploy-to-arcane.sh that creates and starts your project through Arcane's API. It needs a key, and that key should be scoped.

Creating the key

1. In Arcane, go to Settings → API Keys and create one.
2. Grant only these three permissions:

   environments:read

   so the script can find which environment to deploy into

   projects:create

   to create the project

   projects:deploy

   to start it

3. Copy the key. It is shown once.

If the names differ on your instance

Permissions follow a resource:action pattern, and the exact set depends on your Arcane version. Ask your own instance rather than guessing:

bash deploy-to-arcane.sh --permissions

That lists every permission your Arcane offers. If a call is refused, the script names the specific permission that was missing rather than failing with a bare error.

Running it

bash deploy-to-arcane.sh

It prompts for the URL and the key. The key is typed with the input hidden and held only in that shell process — never exported, never written to disk, and never passed as an argument, since arguments are visible to anyone running ps.

1. Open http://your-server:9117.
2. Press Add Indexer, search, and add the ones you use. Public indexers need nothing; private ones need your account details.
3. Press Test on each. A failure here will also fail in Sonarr, so fix it now.
4. For each working indexer, press Copy Torznab Feed and keep the URL.
5. Copy the API Key from the top right of the page. It is the same for every indexer.

Settings → Media Management, scroll to Root Folders, press Add Root Folder:

On the same page, turn on Rename Episodes. Sonarr will then name files the way Jellyfin expects, which fixes most artwork problems before they happen.

Settings → Download Clients → + → qBittorrent:

Press Test. A green tick means the connection works. Then Save.

Settings → Indexers → + → Torznab → Custom. Do this once per indexer you added in Jackett:

Press Test, then Save.

Settings → Profiles. The defaults work, but two adjustments save trouble:

• Cap the quality. A 1080p profile is the sensible default for most hardware. 4K files are enormous and will force Jellyfin to transcode on almost any client.
• Set a size limit. Under the profile, a maximum size per episode stops a single release filling your disk.

Settings → General → Security → API Key. Copy it — Bazarr and Jellyseerr both need it.

If downloads finish but never import

Sonarr and qBittorrent disagree about paths. Compare what each one sees:

docker compose exec qbittorrent ls /data/downloads
docker compose exec sonarr ls /data/downloads

Different listings mean different mounts. The proper fix is matching volumes; the patch is Settings → Download Clients → Remote Path Mappings, telling Sonarr that the client's path is really its own.

Settings → Sonarr, toggle it on:

Then Settings → Radarr with radarr and port 7878. Press Test on each, then save and restart Bazarr when it asks.

1. Settings → Languages — create a profile, add the languages you want, and set it as the default for series and movies.
2. Settings → Providers — add subtitle sources. Most need a free account; create one and enter the details.
3. Settings → Subtitles — turn on Use embedded subtitles so Bazarr does not fetch what your files already contain.

Dashboard → Libraries → Add Media Library:

Repeat with content type Shows and folder /media/tv, and Music for /media/music.

If a library comes up empty

The mount is wrong, not Jellyfin. Check what it can actually see:

docker compose exec jellyfin ls /media

Nothing listed means the volume path in your Compose file does not match your real folder.

Dashboard → Users → +. For each person:

• Set which libraries they can see under Library Access.
• Turn off Allow media playback that requires transcoding for casual users if your server is CPU-limited — the difference between one device quietly overloading the machine and it politely refusing.
• Leave administrative permissions off unless they need them.

Dashboard → Playback → Transcoding. On native Linux with an Intel chip, set hardware acceleration to Intel QuickSync and enable the codecs your hardware supports. This requires the device mapping in your Compose file:

devices:
  - /dev/dri:/dev/dri

1. Open http://your-server:5055. Choose Sign in with Jellyfin.
2. Jellyfin URL: http://jellyfin:8096. Sign in with your Jellyfin admin account — this becomes the Jellyseerr owner.
3. It offers to sync your Jellyfin libraries. Tick the ones people should be able to request from, and run the scan.
4. Next it asks for Radarr and Sonarr. Add both.

Adding Radarr

Sonarr is the same with sonarr, port 8989, and root folder /data/media/tv. Sonarr also asks for a Language Profile — pick your default.

1. Settings → Users → Import Users from Jellyfin. Everyone with a Jellyfin account appears.
2. Set Global Movie Request Limit and Global Series Request Limit — something like 5 per week is sane.
3. Decide on auto-approval. Leaving it off means requests wait for you; turning it on for trusted users saves you being a bottleneck.

1. Open http://your-server:2283 and create the admin account. The first account is the administrator.
2. Administration → Settings → Storage Template — turn it on if you want files organised by date on disk rather than by upload id. Decide this before uploading much; changing it later means moving everything.
3. Install the Immich app on your phone, and enter the server URL. On the same network that is http://your-server:2283; from outside you will need remote access first.
4. In the app, Backup → choose which albums to back up → enable background backup.

1. Open http://your-server:3030 and create your account.
2. Point it at your music. Inside the container that is /music, which maps to your media folder's music directory.
3. Let it scan. Audio analysis is CPU-heavy and takes a while on a large library.
4. To connect Lidarr, give Kima the URL http://lidarr:8686 and Lidarr's API key from Settings → General.

Native apps

Kima implements the OpenSubsonic API, so apps like Symfonium, Amperfy and DSub can connect to it directly. Point them at your Kima URL with your Kima username and password.

Open http://your-server:8000 and sign in with admin and the generated password from your .env.

Add URLs through Add, or import bookmarks and RSS feeds. Each snapshot keeps several formats at once — HTML, PDF, screenshot and more — so storage grows faster than people expect.

Open http://your-server:8001 and sign in with admin and the TA_PASSWORD from your .env.

1. Settings → Application — set your download quality and format.
2. Subscriptions — add channel URLs.
3. Downloads — run a scan, then start the download queue.

Open http://your-server:3001, create your account, then Add New Monitor:

Repeat for each service you care about:

An HTTP monitor tells you the app is answering. A container monitor tells you the container is running. They fail in different ways, so both are useful.

First check your Compose file has the socket mounted — in the generated stack this line is commented out by default:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock:ro

Then in Uptime Kuma, Profile → Settings → Docker Hosts → Add Docker Host:

Save, then Add New Monitor with type Docker Container, container name jellyfin, and the Docker host you just made.

Status Pages → New Status Page. Add the monitors you want visible, and Kuma gives you a clean public page.

This is the one part of Uptime Kuma that is reasonable to expose publicly — it shows only up or down, not your admin interface. If your household keeps asking whether the server is down, this answers it for them.

You need a domain whose DNS is managed by Cloudflare. The free plan is enough.

1. Go to the Cloudflare Zero Trust dashboard.
2. Networks → Tunnels → Create a tunnel, and choose Cloudflared as the type.
3. Name it — home-server is fine — and save.
4. Cloudflare shows you install commands for various platforms. You do not need them. You only want the token — the long string beginning eyJ inside the command it displays.
5. Paste that token into the generator's Connection step, or into CLOUDFLARE_TUNNEL_TOKEN in your .env.

docker compose up -d cloudflared
docker compose logs -f cloudflared

You are looking for Registered tunnel connection, usually four of them to different Cloudflare locations. The tunnel then shows as Healthy in the dashboard.

Nothing was opened on your router, and no certificate was issued on your side — Cloudflare handles HTTPS at their edge.

This is the part that surprises people: your Compose file contains no routing at all. Which hostname reaches which service is configured entirely in Cloudflare.

In the tunnel's Public Hostname tab, add an entry per service:

Use the container name, not localhost. cloudflared runs in a container on the same Docker network, so localhost would mean cloudflared itself — the same rule as everywhere else in this stack.

DNS records are created for you automatically — there is nothing to add by hand.

A tunnel publishes a service to the whole internet. Anything without solid authentication of its own should have a login in front of it.

Under Access → Applications, add a self-hosted application for the hostname, then a policy — allow specific email addresses, or a whole domain. Cloudflare then requires a one-time code before the request ever reaches your server.

1. Visit https://id.example.com. On first run it presents a setup wizard.
2. Create the admin account and register a passkey when prompted — your phone, laptop, or a hardware key.
3. Register a second passkey on a different device immediately.

If you are locked out anyway

Pocket ID's CLI can issue a one-time login link:

docker compose exec pocket-id \
  /app/pocket-id one-time-access-token admin

That prints a URL valid once, for a short window. Open it and register a new passkey.

Every app you connect needs a client entry in Pocket ID. The process never changes:

1. Administration → OIDC Clients → Add OIDC Client.
2. Name it after the app.
3. Enter that app's callback URL — each app documents its own, and the ones you need are below.
4. Save. Pocket ID shows a Client ID and a Client Secret. The secret is shown once — copy it now.
5. Paste both into the app, along with the issuer URL.

Most apps only need the issuer and will discover everything else themselves:

https://id.example.com/.well-known/openid-configuration

The one where SSO is most worth having, since Immich is the app family members use daily.

In Pocket ID

Create a client named Immich with these callback URLs — all three:

https://photos.example.com/auth/login
https://photos.example.com/user-settings
app.immich:///oauth-callback   # the mobile app

In Immich

Administration → Settings → OAuth:

Arcane supports OIDC directly. Create a client in Pocket ID with Arcane's callback URL, then enter the issuer URL, client ID and secret in Arcane's authentication settings.

Jellyfin has no native OpenID Connect support. There is a community SSO plugin, and it works — but it carries a limitation that matters enormously for a media server.

Native OIDC is being built upstream, but the discussion points at Jellyfin 13.0 at the earliest, and it will not reach current servers. Until then this is the situation.

Which plugin

The original 9p4/jellyfin-plugin-sso was archived in May 2026 and is unmaintained. The actively maintained fork keeps the same plugin ID, so it is an in-place upgrade if you already had the old one — and unlike the original it has a proper admin configuration UI rather than API-only setup.

Installing

1. Administration → Plugins → Repositories → Add, and paste the repository URL above.
2. Administration → Plugins → Catalog, find SSO Authentication, install it.
3. Restart Jellyfin.
4. In Pocket ID, create a client whose callback URL follows the plugin's pattern. The provider name at the end is yours to choose, and must match on both sides:

   https://jellyfin.example.com/sso/OID/redirect/pocketid

5. In Plugins → SSO Authentication → Settings, add an OIDC provider with your issuer URL, client ID and secret. Enable it, and set folder access.
6. Restart Jellyfin again — configuration changes do not take effect until you do.

Adding the login button

The button is not added automatically. Edit config/web/config.json:

{
  "customLinks": [
    { "name": "Sign in with SSO",
      "url": "/sso/OID/start/pocketid",
      "icon": "lock" }
  ]
}

Sonarr, Radarr, Lidarr, Bazarr, qBittorrent, Uptime Kuma, ArchiveBox and Tube Archivist have no OpenID Connect support. You have three honest options.

Keep them private — recommended

Do not publish them. Reach them over Tailscale or your LAN, and let their own login be a second layer rather than the only one. For administrative tools you touch occasionally, this is the right engineering answer for a home setup.

Forward authentication

A proxy component checks authentication before passing a request on, putting a login in front of apps that cannot do it themselves.

Just use their own logins

A strong unique password on each, in a password manager. Unglamorous, and completely fine.

Adding someone

1. In Pocket ID, Users → Add User.
2. Send them a one-time link so they register their own passkey on their own device. You never handle a credential for them.
3. Create groups if you want them — media-users and media-admins is plenty for a household. Apps that read group claims can map them to their own permissions.

Removing someone

Because accounts live in several systems, offboarding is a checklist rather than one button:

• Delete or disable them in Pocket ID — stops SSO logins immediately.
• Delete their Jellyfin user separately.
• Remove them from Jellyseerr so pending requests do not linger.
• Decide what happens to their Immich library before deleting that account, since it removes their photos.
• Revoke active Jellyfin sessions, or a signed-in device keeps playing.