Letting other people in, safely.

Reaching your server

Your server sits on your home network. The internet can't see it, which is a feature. There are three ways to change that, and they differ enormously in how much they expose.

Choosing an approach

Tailscale

The least you can do while still getting remote access, and for many people it's genuinely enough.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Install the app on your phone and laptop, sign into the same account, and your server appears at a stable address like http://server:8096. No ports opened, nothing public.

Reverse proxy with Caddy

A reverse proxy sits in front of everything, terminates HTTPS, and routes by hostname. Caddy is the friendliest option because it obtains and renews certificates without being asked.

1. Point a domain at your home

   Buy a domain, then create records pointing at your public address. If your address changes — most home connections — use a dynamic DNS updater, or Cloudflare's API with a small updater container.

   # One record per service, or a wildcard
   jellyfin.example.com  →  your.public.ip
   id.example.com        →  your.public.ip

2. Forward two ports

   In your router, forward 80 and 443 to your server. Those two only — never the application ports themselves.

   Port 80 is needed for certificate issuance, not for serving your site. Caddy redirects it to HTTPS automatically once certificates exist.

3. Add Caddy to your stack

     caddy:
       image: caddy:latest
       container_name: caddy
       ports:
         - "80:80"
         - "443:443"
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile:ro
         - ${CONFIG_ROOT}/caddy/data:/data
         - ${CONFIG_ROOT}/caddy/config:/config
       restart: unless-stopped

   The /data volume holds your certificates. Losing it means re-issuing them, and issuers apply rate limits — so keep it.

4. Write the Caddyfile

   One block per service. Caddy handles certificates for each name automatically.

   id.example.com {
       reverse_proxy pocket-id:1411
   }
   
   jellyfin.example.com {
       reverse_proxy jellyfin:8096
   }
   
   photos.example.com {
       reverse_proxy immich-server:2283
   }

   Services are addressed by container name, because Caddy is on the same Docker network — not localhost, which inside Caddy's container means Caddy.

   Testing without burning your rate limit. Certificate authorities limit failed attempts. While experimenting, add acme_ca https://acme-staging-v02.api.letsencrypt.org/directory at the top of the Caddyfile. Certificates won't be trusted by browsers, but you can confirm routing works, then remove the line.

5. Bring it up and check

   docker compose up -d caddy
   docker compose logs -f caddy

   Watch for certificate issuance. Errors here are almost always DNS not resolving yet, or port 80 not actually reaching the server.

Reloading after a change

Adding a service means adding a block and reloading. A reload swaps the configuration with no dropped connections — it is not a restart:

# check the syntax first
docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

# apply it with no downtime
docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

The Caddyfile is mounted live, so editing it on the host or through Arcane is enough — only the reload is needed.

What to never expose

Publishing a hostname makes it reachable by everyone, including automated scanners that will find it within hours. Some things in this stack must not be among them.

Reach the "never" items through Tailscale instead. You can run both: a public proxy for the things family use, and a private network for everything administrative.

Connecting your apps

This is where expectations need managing. Single sign-on across a media stack is not the solved problem it appears to be — most of these applications have no OIDC support at all, and the most important one has an awkward caveat.

What actually supports it

Immich

The best-supported of the three, and the one where SSO is most worth having, since it's the app family members use daily on their phones.

In Pocket ID, create a client with these callback URLs:

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

Then in Immich, under Administration → Settings → OAuth:

Jellyfin — read this before starting

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

Native OIDC has been proposed upstream and is being worked on, but it isn't in a released version at the time of writing, and the discussion points at a future major release. Until then, this is the situation.

Given that, decide honestly whether it's worth it:

If you're proceeding

The original plugin was archived in May 2026. Use the maintained fork, which keeps the same plugin ID (so it upgrades in place) and adds a proper admin UI. Add its repository under Administration → Plugins → Repositories, install SSO Authentication from the catalogue, and restart Jellyfin.

https://raw.githubusercontent.com/K0lin/jellyfin-plugin-sso/manifest-release/manifest.json

In Pocket ID, create a client whose callback URL follows the plugin's pattern — the provider name at the end is whatever you choose to call it, and must match on both sides:

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

Configure the plugin with your issuer URL, client ID and secret, enable it, tick folder access, and restart Jellyfin — configuration changes don't take effect until you do.

The login button isn't added automatically. Add a custom link in Jellyfin's config/web/config.json:

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

Everything else

For apps with no OIDC support, you have three honest options.