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

4 acronyms in this thread; the most compressed thread commented on today has 5 acronyms.

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

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?

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 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.

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.

Pangolin on a cheap VPS.

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

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.

Authentik (and other auth systems) are super heavy for single/low-user systems. They’re geared for more MSO use than SOHO. For auth, I’d really recommend something lighter, like Pocket-ID (as long as you don’t mind passkeys instead of passwords - Seerr and BookOrbit support WebAuthn so you can use it directly, and Jellyfin supports it with an extension for the web interface + you can set password for a Jellyfin account for clients that need direct auth). For any service that doesn’t support it, Pocket-ID has an auth gateway/wrapper you can use with your reverse proxy (I use Caddy, config is fairly straightforward).

For security, I’d recommend some automated IDP systems. You could run Suricata on your router (if it can host heavier apps), which is what Ubiquiti uses. It can talk to your firewall and set up rules on the fly to block intrusions, specific users etc.

Beyond that I’d also recommend crowdsec. One half is the detection (you hook it up as part of your reverse proxy, so it can inspect packets and full flows), and the other is the actioning (you hook it up with your router/gateway/firewall to apply blocking rules). Big benefit is that their open database (the free to access one) has all the 0-day fingerprints and CVE-specific behaviour is detected and blocked.

Here’s a quick preview of what it’s been doing today on my setup:

Since most indirect attackers (people randomly probing your homelab instead of directly targeting you and your services) will come from various data centers (routed through a VPS or directly relying on the infrastructure), a 4h block is generally enough to not interrupt other services while blocking attackers from probing once they hit a limit.

And of course you also need proper container network setups. For example, every single container I can, I run in rootless, read-only mode. This means the container itself can’t be edited - only a handful of paths (left as volume mount points) are RW: the config folder, media folders only if the container needs write access to them, and caches. Each path is mounted noexec so even if a backdoor is found into the container, the attacker can’t do much as they can’t execute anything they’d deliver as payload (can’t write to paths that are executable, can’t execute from writeable paths), and since the container is rootless, there aren’t many tools to run: no ash/bash/zsh/fish, no interactive shell at all, no operating system beyond a barebones Linux kernel and the bare minimum tooling needed for the specific software.

Docker networking is also hardened, with routing strictly limited, and containers only seeing other containers they need access to.

I’d also recommend using LLMs to expand on your security. No I’m not talking about giving Claude access to your entire network and homelab… But you can ask for general hardening guidance, and most frontier models will gladly walk through your stack using basic reporting (you run a command on the homelab nodes, it returns a report, you give that report to the model), and give recommendations on making it more secure.

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.

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.