this post was submitted on 23 May 2026
151 points (96.9% liked)

Selfhosted

59558 readers
740 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 posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

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

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

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
[–] EncryptKeeper@lemmy.world 11 points 5 days ago (4 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.

[–] Strit@lemmy.linuxuserspace.show 2 points 4 days ago (3 children)

Jellyfin had a third party plugin for OIDC. It was archived recently, but I heard Jellyfin has plans to implement it directly into the software. 🤞

load more comments (3 replies)
load more comments (3 replies)
[–] pnelego@lemmy.world 8 points 5 days 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.

[–] rumba@lemmy.zip 13 points 6 days 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 6 days 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)
[–] Nibodhika@lemmy.world 18 points 6 days 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 27 points 6 days 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 6 days ago

It really seems overblown of an issue...

[–] Nibodhika@lemmy.world 5 points 6 days 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 6 days ago (1 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.

[–] Flatfire@lemmy.ca 4 points 6 days ago (3 children)

Jokes on them, my paths are a shitshow and I can't be bothered to organize them properly

load more comments (3 replies)
load more comments (1 replies)
load more comments (6 replies)
[–] anon_8675309@lemmy.world 8 points 6 days 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)
[–] NeryK@sh.itjust.works 10 points 6 days 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 4 points 6 days 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)
[–] quips@slrpnk.net 7 points 6 days 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.

[–] PeriodicallyPedantic@lemmy.ca 4 points 5 days ago (8 children)

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)
[–] zaggynl@feddit.nl 7 points 6 days ago (5 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 5 days ago

https://www.moanmyip.com/

It's exactly what it sounds like.

[–] hereiamagain@sh.itjust.works 3 points 6 days ago (1 children)

This is solid. I wonder if you could rig up a ddns somehow to keep it seamless?

[–] zaggynl@feddit.nl 2 points 3 days ago

Something like reverse dynamic DNS for end users? Hm, only if it would be easy to setup, is on the same level as a VPN client I'd say.

load more comments (3 replies)
[–] Seefoo@lemmy.world 3 points 5 days 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

[–] kcweller@feddit.nl 6 points 6 days ago (8 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.

load more comments (8 replies)
[–] Clutter@sh.itjust.works 5 points 6 days 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)
[–] nibbler@discuss.tchncs.de 3 points 5 days ago* (last edited 5 days ago) (6 children)

If client certificates and basic auth is not supported by jellyfin:

  • reverse proxy
  • strong random subdomain
  • wildcard certificate
  • tls1.3 only
  • doh/dot only

1-3 make random scanners unable to find your service, 4&5 even hide it from your ISP. Dot/doh service will still know your subdomain, so be your own dot/doh ! :D

load more comments (6 replies)
[–] DecentM@lemmy.blahaj.zone 5 points 6 days 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 6 days 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 6 days 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)
[–] Jason2357@lemmy.ca 2 points 5 days ago (3 children)

Put Jellyfin and a reverse proxy in an isolated vlan or DMZ, with no ability to reach into your lan at all and everyone connects in the same way. Its just movies, thats all you lose if it gets hacked. Set up some monitoring too in case it becomes a botnet node so you can destroy it and start over.

load more comments (3 replies)
load more comments
view more: next ›