this post was submitted on 23 May 2026
154 points (97.0% liked)

Selfhosted

60409 readers
732 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?

top 50 comments
sorted by: hot top controversial new old
[–] slazer2au@lemmy.world 61 points 1 month ago (1 children)

At the very minimum stick a reverse proxy in front like caddy, nginx, or Traefik. Then have some middleware like crowdsec to inspect what's going on. Then whitelist the IP or the country IP block.

There is much more but those would be the bare minimum.

[–] NarrativeBear@lemmy.world 16 points 1 month ago

I too would like to know more. Jellyfin has been something that I am still heditating to expose online without a VPN.

I have Plex behind a reverse proxy (HAproxy) with Crowdsec and firewall rules all behind Cloudflare. My firewall rules in HAproxy block access a few different ways, like if request are higher then 60 requests a second, or if there is strange path traversal. Used the following guide as a start.

https://www.archy.net/building-a-native-fail2ban-with-haproxy-stick-tables/

[–] prenatal_confusion@feddit.org 25 points 1 month ago (1 children)

Reverse proxy with auth in front of the actual jellyfin login. Like pangolin.

[–] BakedCatboy@lemmy.ml 14 points 1 month ago (14 children)

How do you get apps through something like that? Do you have to open your browser and hit the URL periodically to handle auth there and it just remembers your IP?

load more comments (14 replies)
[–] Nibodhika@lemmy.world 19 points 1 month ago (7 children)

Secure is relative, you should be aware that jellyfin itself has security issues https://github.com/jellyfin/jellyfin/issues/5415 most of which are harmless, but at least one is fairly serious and allows people to watch your media without authentication, and adding an extra layer of authentication on the proxy would likely cause issues with clients.

That being said, if you're okay with those security issues what I would do is have a cheap VPS, connect both machines to tailscale, and have something like Caddy on the VPS to do the forwarding.

[–] exu@feditown.com 28 points 1 month ago (3 children)

Just leaving this here

Now, let's address this clearly once and for all. What is possible is unauthenticated streaming. Each item in a Jellyfin library has a UUID generated which is based on a checksum of the file path. So, theoretically, if someone knows your exact media paths, they could calculate the item IDs, and then use that ItemID to initiate an unauthenticated stream of the media. As far as we know this has never actually been seen in the wild. This does not affect anything else - all other configuration/management endpoints are behind user authentication. Is this suboptimal? Yes. Is this a massive red-flag security risk that actively exposes your data to the Internet? No.

https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290

[–] Appoxo@lemmy.dbzer0.com 10 points 1 month ago

It really seems overblown of an issue...

[–] Nibodhika@lemmy.world 5 points 1 month ago (1 children)

Except most people have almost the same structure because of media organizers like radarr/sonarr. At the very least they should hide that behind a setting to not require auth (since the header should be there for most clients) so only people running an old client would be affected. They could also add an extra salt to that hash or something similar.

I agree, it's not critical, but it shouldn't be hand waved either. And like I said, security is relative, I would argue for most people this is fine, but I still think this should be taken more seriously.

[–] BakedCatboy@lemmy.ml 5 points 1 month ago (4 children)

Yeah not only would a lot of people have the same media name, because of docker mounts, probably a lot of people have the same path to the media inside of the docker container even if the external location is different. I bet you could make a rainbow table of sorts of the most popular movie/TV torrents combined with the most common place in the container for media to be mounted, then use shodan to get a list of hundreds of instances that you could scan for the common hashes.

I'm just seeing the issue for the first time and noticed it was raised 5 years ago - surely that was enough time to at least put forward a changeover date and give clients time to update.

load more comments (4 replies)
load more comments (1 replies)
load more comments (6 replies)
[–] SteveTech@aussie.zone 18 points 1 month ago (4 children)

Possibly mTLS, which you'd configure in your reverse proxy. You could email them the certificate and instructions on installing it. I believe for Chromium browsers on Windows you basically just double click the cert and click through the wizard. Firefox I know has a thing in the settings for importing the cert. Android you just tap on the cert and make sure it opens with 'Certificate Installer' if it gives you the option.

[–] purplemonkeymad@programming.dev 4 points 1 month ago (3 children)

I recently did exactly this. Only works with the web UI, no apps support it, but working well and those without the cert just get a 400 error. Not sure if non technical tbh, since you will get warnings when adding your root certificates to any device, and that might scare some who don't understand what it does.

Also set it up through wireguard, so can punch out of double NAT.

load more comments (3 replies)
load more comments (3 replies)
[–] rumba@lemmy.zip 13 points 1 month ago (2 children)

Run the jellyfin in a container that only has read privileges to the videos ( make sure you can't get out to your whole NAS from there), put that behind a Cloudflaired tunnel.

It's not technically secure, but if they can't get a foothold in your network and the only thing they can access is your video catalog, that's a reasonable amount of risk.

[–] Bazoogle@lemmy.world 9 points 1 month ago (2 children)

Gotta be careful with cloudflared and media. They can block you if they detect copyrighted materials, even if it's your own DVDs. You can setup TLS certs so the traffic is at least encrypted

load more comments (2 replies)
load more comments (1 replies)
[–] EncryptKeeper@lemmy.world 12 points 1 month ago (7 children)

The biggest problem with that Jellyfin to this day is that you can’t.

Seems like every new open source selfhosted app implements OIDC compatibility, but for some reason, I can only assume is technical debt, Jellyfin hasn’t.

load more comments (7 replies)
[–] NeryK@sh.itjust.works 11 points 1 month ago (3 children)

For a remote and non-technical user I would say IP whitelisting offers a decent tradeoff.

On your end you expose your jellyfin port to internet, but restrict at the router level to your user's client IP address as soon as you have it. Obviously in practice this works best if the address does not change often.

[–] Bazoogle@lemmy.world 5 points 1 month ago (1 children)

Also not as ideal if their ISP uses CGNAT. Still waaay better than fully open, but you would be giving access to many households

load more comments (1 replies)
load more comments (2 replies)
[–] zaggynl@feddit.nl 8 points 1 month ago (7 children)

Ask them to visit https://ipv4.icanhazip.com/ and give you back the number, then whitelist in your webserver, as well as your LAN/VPN range, deny rest. Explain they can only reach jellyfin from their home internet. Repeat if they get 403 forbidden after they get a new WAN IP.

That or VPN like openziti, wireguard but gets more complicated.

[–] floral_toxicity@lemmy.world 4 points 1 month ago

https://www.moanmyip.com/

It's exactly what it sounds like.

load more comments (6 replies)
[–] skeevy_scallops@feddit.online 8 points 1 month ago (2 children)

call me crazy but I just use a couldflare tunnel since my domain is already provided through them. They make it really easy to add sub-domains attached to specific ports on the local machine and automatically adds the proper DNS entries. Additionally they have a ton of domain security/anti-bot measures you can set up.

load more comments (2 replies)
[–] cupcakezealot@piefed.blahaj.zone 8 points 1 month ago (2 children)

if theyre close, add them to your tailscale, if not and you have a web serve, use a reverse proxy.

for tailscale, you'd probably have to walk them through setting it up but then its one and done

[–] WeirdGoesPro@lemmy.dbzer0.com 6 points 1 month ago

That’s basically the VPN solution but with a little more flexibility.

If you want to actually expose the service, you can use Tailscale to connect it to a VPS and then expose that port to the web with Nginx, but if you do that, be prepared on the security front because…you know…open internet be full of hazards.

load more comments (1 replies)
[–] pnelego@lemmy.world 8 points 1 month ago

To be totally honest I'm not sure you can harden jellyfin enough for public Internet exposure without also breaking basic functionality of the platform.

This is why everyone is always pushing so hard for a VPN/Tailnet of some kind. The public internet is a bit to much of a wild west to be exposing arbitrary services to it unless you really know what you're doing.

[–] anon_8675309@lemmy.world 8 points 1 month ago (2 children)

Another way:

Expose using caddy. Use basic auth for the web UI only. This exempts the Jellyfin app clients from basic auth that they don’t support but requires it before anyone even gets to the Jellyfin UI. This obfuscates the fact that your endpoint is even a Jellyfin end point.

load more comments (2 replies)
[–] quips@slrpnk.net 7 points 1 month ago

A reverse proxy is what you are looking for. I recommend Caddy.

You’ll also need a domain, but they can be had for very cheap.

[–] kcweller@feddit.nl 6 points 1 month ago (5 children)

Set up a reverse proxy with https always on. And get a good (physical) firewall, preferably something akin to opnsense, pfsense, openwrt. Exposing is always a risk, and if you do want it, you have to bear the responsibility for your own security. Keep things up to date, set up monitoring and a good logging system (Wazuh) comes to mind.

Exposure means a security risk. How you deal with that security risk is your choice.

Cloudflare and the likes forbid usage of their stuff for these things.

[–] syaochan@feddit.it 4 points 1 month ago (2 children)

How does a reverse proxy helps for security? I mean, the problem here is that exposing Jellyfin on the internet is dangerous: the only way to improve security via a reverse proxy would be mTLS, but I'm not sure how it would work client side.

[–] kcweller@feddit.nl 4 points 1 month ago (1 children)

By setting up a reverse proxy you redirect the traffic through that specific proxy which means less open ports (basically just 80/443), less monitoring, the ability to easily put a WAF inbetween, etc.

load more comments (1 replies)
load more comments (1 replies)
load more comments (4 replies)
[–] INeedMana@piefed.zip 6 points 1 month ago

If they could be using web UI (I'm not sure how a client would work with auth like that) then it kind of depends on how much hassle they can live with and how secure you want to be

Simplest would be to use https://doc.traefik.io/traefik/reference/routing-configuration/http/middlewares/basicauth/
You set up username and password and share those with the user. But it can be brute-forced

Something more secure but also a bit more demanding would be some kind of email otp
https://docs.goauthentik.io/add-secure-apps/flows-stages/stages/authenticator_email/
Set up authentik to send time-limited link to their email that well let them through. But they would have to authenticate every time they access

[–] AllYourSmurf@lemmy.world 6 points 1 month ago

I agree with reverse proxy + middleware. I’d also suggest something like Jellyswarm as the front end. That way I can connect to other friends’ servers too.

[–] 8j1obzlb@piefed.social 6 points 1 month ago (2 children)

I agree with the folks saying reverse proxy of some kind + WAF. That way end users don’t have to deal with the VPN, but your home system is not directly exposed.

I’ve been doing something similar with SSH local port forwarding and a $5/month VPS. Haven’t come anywhere close to my network quotas, and performance has not been an issue for home use with 2-5 concurrent users most of the time. I forward the local caddy ports to unprivileged ports/user on the VPS, then use the firewall on the VPS to forward that port to 443 and lock down the rest.

load more comments (2 replies)
[–] blah3166@piefed.social 6 points 1 month ago

best practice states security through obscurity is not to be relied upon, but compare ssh logs after one year on the default port vs a non-standard port and you'll immediately see why you want to use a non-standard https port for non-professional services. it cuts 99.9% of the noise/attempts.

Depends on what you mean by "secure." My personal setup is Jellyfin LXC on proxmox --> Wireguard to VPS -> Nginx reverse proxy on VPS.

This setup relies somewhat on Jellyfin's auth, but I'm comfortable with that risk. The LXC is blocked from sending local traffic on my network by firewall rules. Yes, someone could exploit a vulnerability in Jellyfin (though looking through the CVEs I'm not overly worried about that), then escape the LXC and fuck with my server. But that's a lot of work for no profit.

For more protection (in sense of reducing traffic that even interacts with your server), I'd recommend getting a wildcard cert for the domain so that the actual subdomain jellyfin is on is undisclosed to anyone not using your service.

Security isn't about making everything impregnable, it's about making attacks more trouble than they're worth. Otherwise, we'd all live in fortified bunkers surrounded by landmines. 🙃

[–] atzanteol@sh.itjust.works 5 points 1 month ago (1 children)

Your vps isn't doing anything useful security wise.. it's just sending traffic directly to jellyfin.

You'd get the same protection with just port forwarding to a local proxy in front of jellyfin. Or you could even leave out the proxy if you didn't need it.

load more comments (1 replies)
load more comments (4 replies)
[–] Clutter@sh.itjust.works 5 points 1 month ago (3 children)

Perhaps (and I know I might be weird) running pangolin on something like hetzner? (Which I do)

load more comments (3 replies)
[–] DecentM@lemmy.blahaj.zone 5 points 1 month ago (2 children)

Not at all, there's legal risk if you're hosting your blurays. Cloudflare even explicitly forbids such use. VPN or nothing imo.

[–] imhungry@leminal.space 5 points 1 month ago (2 children)

Wow, Cloudflare is against piracy? Every single site I've ever seen in my life is registered with Cloudflare and uses their DNS with the exception of PTB I believe.

[–] DecentM@lemmy.blahaj.zone 9 points 1 month ago (1 children)

Not sure about that, I think it's more just that they don't want people streaming terabytes of traffic through their edge.

load more comments (1 replies)
load more comments (1 replies)
load more comments (1 replies)
[–] irotsoma@piefed.blahaj.zone 4 points 1 month ago

Reverse proxy with fail2ban or crowdsec. It's possible to set up things like Pangolin which ultimately use a VPN between external and internal access points but not at the client, though it takes more setup if you want to use apps over pangolin instead of just the browser.

load more comments
view more: next ›