Are your exposed services all on their own ports externally, or behind a reverse proxy?

Putting them behind a reverse proxy makes sure that attackers at least need to know the correct hostname to access your service.

This is security by obscurity which isn’t proper security but it means that all of the port scanners out there likely won’t know your jellyfin server exists when a vulnerability for jellyfin is released.

If you use let’s encrypt or something similar be aware that all issues certs show up in a public log so attackers like to harvest that log as a list of valid domain names. Switch those certs to wildcards so that you aren’t advertising those valid hostnames.

There are often options in reverse proxies, or sometimes your router to do geo based blocking. If you can limit connections to your local country only you eliminate huge portions of the botnets out there.

Combining this with auto updates/reboots on your services is probably enough to keep you safe, but if you want to really secure things a separate DMZ vlan for your services to prevent an attacker from compromising additional services on your LAN.

The more network segmentation you can do the better. An ideal setup is every app/container in its own network/ACL that only allows traffic to the specific network devices that it needs to talk to. This is a lot to manage if you do this with your router/vlans. Containers orchestrators (i.e. k8s) make this easier, but don’t protect you from kernel level exploits to break out of the containers. I believe proxmox has VM level ACLs now so you could skip the vlans and do your segmentation at that level instead.

Never call yourself an idiot. Not a good IT engineer? (Just saying, I don’t know you) That doesn’t make you stupid at all.

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?

I use Pangolin on a kinda cheap VPS on Hetzner (they’re now a bit too pricey), and route my services through Site Connectors (Newt, it’s called). Dealing with opening my firewall is a pain I don’t wanna think about, but Pangolin creates a websocket and can do NAT traversal from the Site Connector, so no swiss-cheesing your firewall.

It’s nice because you can contain different services with VLANs to further segment and protect your network, and each Site Connector can work for many services (if there’s no firewall rules restricting it/VLANs) or you can put a Site Connector on each server individually, if segmentation is important to you.

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

So the public services are purely for private use, to sync your mobile devices? You can install Wireguard on Android, send them over there. Though for e-reader, since they are Kobos (basically Android), you can trick it to install the app. Or even another launcher/book reader.

Not sure why nobody here recommended netbird reverse proxies. It has crowdsec out of the box plus blocking/allowing ip ranges. On top of it, it also support pin or password based auth, so you can have 2 layers of auth.

But i haven’t hosted jellyfin yet, only opencloud and a couple others. Haven’t seen anybody pwning it based on the logs

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

Pangolin on a cheap VPS.

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?

There is some great advice in here but I wanted to throw my two cents in by saying bollocks to Hetzner, they get circlejerked far too much. Go with Contabo instead, 4 core 8GB VPS with 100GB SSD is $5 a month right now and has a generous 30TB/month bandwidth allowance.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

9 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.

[Thread #151 for this comm, first seen 30th Oct 2026, 19:00] [FAQ] [Full list] [Contact] [Source code]

Hetzner is great as a provider, highly recommend.

I use authentik with fail2ban, crowdsec and ufw. I use netbird to act as a VPN between different servers - most services need users to login through there but have a couple on the internet. I also restrict countries to ones my clients are on and update when im going on holiday.

I use caddy as my reverse proxy with rate limits and crowdsec. I moved from NPM just to try it and liked it.

SSH is on a different port and restricted to keys only. I also setup ntfy to notify my phone if there are logins (to check it’s just me).

I use unattended upgrades for security but try to upgrade frequently the servers and docker services.

Don’t put them on the internet. Seriously, don’t put stuff on the internet. These days critical CVEs are coming out weekly and it is unlikely that you even detect the compromise.

What is your use case? Maybe there is a better way

crowdsec is super easy to setup