For whatever it is worth to you I’ve hardened my jellyfin docker compose this way. I’m obscuring some things in this that are local to my network.

The container is read only. It mounts the media read only. It should be fairly isolated from getting privileges it shouldn’t have. The only things lost in this setup are the ability to delete media from a jellyfin client (something I never do) and the ability to manipulate files directly stored with the media. I use bazarr for subtitles so don’t need jellyfin to download them and I don’t keep trickplay or any other jellyfin metadata related files alongside the media. I feel pretty confident with this that even if the jellyfin codebase had a serious 0 day that the worst I’d lose is metadata and server setup, and important config files I have backing up to another machine.

I’m sure there’s things I’ve overlooked with this setup so I’m very open to being told there’s a better way to do something.

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    mac_address: OBSCURED # see macvlan note below
    hostname: jellyfin
    user: ${PUID}:${PGID}
    group_add:
      - "992" # my render group id
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp:exec,nosuid,nodev # exec some plugins can write to /tmp, no-nosuid,nodev for security
    networks:
      macvlan:
        ipv4_address: OBSCURED
    healthcheck:
      test: [ "CMD", "curl", "-fsS", "http://127.0.0.1:8096/health" ]
      interval: 1m
      timeout: 10s
      retries: 3
      start_period: 30s
    environment:
      - TZ=${TZ}
      - JELLYFIN_PublishedServerUrl=OBSCURED
      - JELLYFIN_DATA_DIR=/config/data # consolidates these dirs under /config, migrated from linuxserver.io setup
      - JELLYFIN_CONFIG_DIR=/config
      - JELLYFIN_LOG_DIR=/config/log
      - JELLYFIN_CACHE_DIR=/config/cache
      - HOME=/config
    volumes:
      - ./jellyfin:/config
      - ${MEDIA}:/media:ro
    devices:
      - /dev/dri/renderD128:/dev/dri/renderD128 # isolate to just the renderD128 device
    device_cgroup_rules:
      - 'c 226:128 rw' # further limits access for the renderD128 device

networks: # I went with macvlan to preserve mdns for local discovery, otherwise you need to use host level networking
  macvlan:
    driver: macvlan
    driver_opts:
      parent: OBSCURED # Replace with host network interface name (find via: ip route | grep default)
    ipam:
      config:
        - subnet: OBSCURED/24 # Your local LAN network CIDR
          gateway: OBSCURED # Your local router IP address

Backup.
Update.
Don’t keep all in one place.
Update.
Don’t forget to backup.

Get Jellyfin off the open internet. For family who’ll never install a VPN app, the setup that holds up is WireGuard on their router, or Tailscale on whatever TV box they use, set up before it ever ships to them. They never see it. If something has to stay public, CrowdSec plus Pocket-ID is a lot lighter than Authentik for three users. I’m building a home box that ships locked down like this by default, so I’m curious: which broke first for your family, remote access or the logins?

Ask yourself: is there any service that really, really needs to be public? Or is this only about availability for you or a very limited group (family, friends), which could be implemented via a VPN solution?

I have three services which are public. Jellyfin, Seer and BookOrbit (for syncing Kobos).

don’t expose services to the internet. expose a proxy.

Imagine if your house had doors to the outside for every room in your house. not very secure, right?

I’m going to hope when you mentioned NPM you were referring to nginx proxy manager.

also, use a separate host for your proxy that is firewalled off from everything else on your network other than the host with your services and only on those specific ports. it doesn’t have to be powerful, just has to have a fast network connection. I wouldn’t use anything less than 1gbps. you could vlan as well, but that would require advanced routing or a second NIC for your services host. don’t forget to firewall your services host off the rest of your network.

finally, monitor the shit out of that proxy host. use SIEM tools like graylog, wazuh, splunk, etc. you cannot make an impenetrable fortress, it’s only a matter of time before you experience a penetration. setting up proper logging and alerting is imperative to securing your network.

If you don’t mind I’d share my scenario with you, but I’m far from a professional myself, so in the same time I’m also asking any thought about my own approach.

For my public facing services (e.g. Nextcloud) I’ve created a separate VLAN which is completely isolated from the rest of the system, I’ve deployed an nginx LXC with Crowdsec/fail2ban, and opened very specific “pinhole” style firewall rules towards the service layer VLAN in OPNsense. I’ve also separated this service / app VLAN layer from the database layer (which is another VLAN with strict firewall rules and SSL). For authentication I use what the service offers natively, except for some cases of keycloak / hardware key.

Based on my research, this should be a solid baseline, but honestly noone more knowledgeable than myself has confirmed it, so take it with a grain of salt.

Pangolin on a cheap VPS.

Hetzner is usually the top choice for non us cloud

Wireguard is fairly simple to configure and many routers support it; it could be made to be transparent to your relatives.

to get something that is idiot proof.

The problem with Jellyfin in particular is that it needs to support binary streaming protocols. You can implement some gateway/firewall-based security in front of Jellyfin, but in the end it is still Jellyfin’s internal mechanisms mostly responsible for its own security. I don’t use Authentik but I have read many good things. The only real “advantage” of it is that it forces your users to somewhat better credential handling. Jellyfin still only supports LDAP, so the users will have to enter their Authentik username and password – very similar to just local accounts managed by Jellyfin. So IMO, not offering you that much extra in terms of security. You will be better served by firewall tools like fail2ban, crowdsec, geo-fencing, etc.

Depending on where/how your users access Jellyfin you could have something a bit tighter. If they never run it on a TV you could do something more advanced like mTLS where you issue them a certificate with a TTL of several years, walk them through installing it on their phones/laptops, and then have that in a reverse proxy. But at that point you might as well walk them through setting up a VPN mesh network.

For Seerr, it’s just a standard web app .You could put a reverse proxy in front that requires OIDC with Authentik. Seerr is also pretty close to having native OIDC integration. Personally I prefer having two rounds of OIDC – reverse proxy really narrows what the public can see as a first layer.

For BookOrbit, I am not familiar enough with the Kobos. My guess is, you could put BookOrbit behind a reverse proxy that enforces OIDC, but you might have to allow a bypass for /api route. Then you’re relying on BookOrbit to authenticate all /api requests through API tokens. This would look like the normal Kobo linking process, so no real difference, but then your BookOrbit web UI is locked behind OIDC authentication.