202

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 new old
[-] slazer2au@lemmy.world 92 points 3 weeks ago

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 23 points 3 weeks ago* (last edited 2 weeks ago)

I too would like to know more. Jellyfin has been something that I am still hesitating 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 36 points 3 weeks ago

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

[-] BakedCatboy@lemmy.ml 18 points 3 weeks ago

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?

[-] halcyoncmdr@piefed.social 5 points 3 weeks ago

You can set pangolin to allow access to an entire resource or just certain paths without the front auth, instead relying on the built in auth.

Your random plex/emby/jellyfin server isn't going to be a huge target and the built in auth is good enough for the limited access your media system should have.

[-] BakedCatboy@lemmy.ml 21 points 3 weeks ago

Wait so if you're gonna allow access without authentication then why bother putting pangolin in front of jellyfin? Does it help in some other kind of way? I don't really get how it helps without interfering with apps accessing jellyfin.

load more comments (1 replies)
load more comments (12 replies)
[-] SteveTech@aussie.zone 25 points 3 weeks ago

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.

load more comments (7 replies)
[-] Nibodhika@lemmy.world 19 points 3 weeks ago

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 34 points 3 weeks ago

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 11 points 3 weeks ago

It really seems overblown of an issue...

[-] Nibodhika@lemmy.world 7 points 3 weeks ago

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.

load more comments (5 replies)
load more comments (1 replies)
load more comments (6 replies)
[-] rumba@lemmy.zip 18 points 3 weeks ago

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 14 points 3 weeks ago

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 3 weeks ago

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 12 points 3 weeks ago

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.

load more comments (4 replies)
[-] pnelego@lemmy.world 11 points 3 weeks 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 11 points 3 weeks ago

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)
[-] cupcakezealot@piefed.blahaj.zone 10 points 3 weeks ago

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 3 weeks 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)
[-] zaggynl@feddit.nl 10 points 3 weeks ago

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.

[-] 8j1obzlb@piefed.social 9 points 3 weeks ago

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)
[-] AllYourSmurf@lemmy.world 8 points 3 weeks 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.

[-] quips@slrpnk.net 8 points 3 weeks 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.

[-] skeevy_scallops@feddit.online 8 points 3 weeks ago

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)
[-] blah3166@piefed.social 7 points 3 weeks 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.

[-] Seefoo@lemmy.world 7 points 3 weeks ago

You can do a reverse proxy + authelia (or other auth service). It's still more risky than a VPN IMO, buts wayyyy better than some of the other options in this thread

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 3 weeks ago

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)
[-] PeriodicallyPedantic@lemmy.ca 6 points 3 weeks ago

I'm kinda disappointed with this thread, I'm in a similar position to OP, but all the responses are just like "use a reverse proxy and make your URL hard to guess" and other measures which are not very secure. \

It seems like that's about as good as you can get at the moment, because the mobile apps barf if you try to add in auth in front of the reverse proxy, but a lot of people seem to be providing this advice like it's good enough rather than as good as you can get.

load more comments (8 replies)
[-] DecentM@lemmy.blahaj.zone 6 points 3 weeks ago

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 6 points 3 weeks ago

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 11 points 3 weeks ago

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 (2 replies)
load more comments (1 replies)
[-] kcweller@feddit.nl 6 points 3 weeks ago

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.

load more comments (9 replies)
[-] BandDad@lemmy.zip 6 points 3 weeks ago

If anyone has any tips for getting Tailscale running via Docker on my Openmediavault machine, I'm open to it. Everyone lauds it for being dead simple and I cannot for the life of me get it running on the machine it needs to be. Not sure my wife can/will handle anything more complicated.

[-] kiol@discuss.online 5 points 3 weeks ago

Just read their actual documentation. You'll want to either way.

load more comments (1 replies)
[-] Clutter@sh.itjust.works 6 points 3 weeks ago

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

load more comments (3 replies)
[-] INeedMana@piefed.zip 6 points 3 weeks 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

[-] crypt0cler1c@infosec.pub 6 points 3 weeks ago
[-] halcyoncmdr@piefed.social 22 points 3 weeks ago

Yeah, let me just walk my normie friends and parents through setting up a VPN on their TV so they can stream their shows.

load more comments (2 replies)
[-] bhamlin@lemmy.world 18 points 3 weeks ago

VPNs are not trivial to use for normies.

load more comments (2 replies)
[-] irotsoma@piefed.blahaj.zone 5 points 3 weeks 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 ›
this post was submitted on 23 May 2026
202 points (97.2% liked)

Selfhosted

59939 readers
296 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam.

  3. Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.

  4. Don't duplicate the full text of your blog or git here. Just post the link for folks to click.

  5. Submission headline should match the article title.

  6. No trolling.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS