Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?
You must log in or # to comment.
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.
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.
You’ve got a couple benefits. If you have a domain name, and aren’t advertising it publicly, then you can use the reverse proxy to point that domain to a non-standard port that Jellyfin runs on.
Security through obscurity is not good security, but it does prevent the majority of port scanning attacks. You can also use fail2ban on the reverse proxy side to try and mitigate some attacks.
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.
Cf used to have it against the rules, but it’s fine now.
Ah cool, didn’t know!
Cloudflare and the likes forbid usage of their stuff for these things.
😬
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.
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/
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol Plex Brand of media server package VPN Virtual Private Network nginx Popular HTTP server
4 acronyms in this thread; the most compressed thread commented on today has 13 acronyms.
[Thread #311 for this comm, first seen 23rd May 2026, 22:30] [FAQ] [Full list] [Contact] [Source code]
Good bot.
Meh. If someone hacks my server and watches TV then idc, have at it. They earned it
Didn’t down vote, and I get what you’re saying to a certain extent. I’m not touting my server as hack-proof in the least, but it would take some work. My concern wouldn’t be someone hacking in and listening to my personal music collection I’ve been working on for decades…it goes all the way back to 1937.
I would be more concerned that my compromised server was used as a zombie attack on some other server. The first VPS server got ransacked and used over-nite to (unsuccessfully) DDoS another business site.I got a ton of nasty grams for that boner. I didn’t loose anything but time.
Bitcoin miners are easy to spot. I’ve never really understood why someone would hack into a small server and deploy a nefarious miner. On a huge corporate server farm, sure. But not some small selfhost VPS somebody found on lowendbox.
Because they’re not mining on just one, they’re mining on thousands.
I understand economy of scale, but how much could you actually mine over nite on a little droplet before junior sysadmin notices that there is an influx of nasty grams in his in box and his little 4 banger VPS is maxed out on resources.
Long enough to make it worth it. Most people aren’t paying that much attention.
Sure… If someone managed to stream some of my media… They probably earned it… But then they exploit a vulnerability to perform arbitrary code execution, and leverage that to hack everything else on my network…
I’m learning a lot of this as I go and have not exposed any services to the internet yet, but would VLANs not contain the damage to a limited portion of the network? Because that’s the plan I’m working toward. Not just for Jellyfin but a handful of other services.
That… might work. Do you have a different physical server for each service though?
The issue is once someone is in, then they can try to jailbreak and move laterally to get to other things. Other devices, into the file system.
Jellyfin might not be your concern, but are there other files on that server? Or services? Secrets passwords etc? If anything else is on that vlan, what security flaws might be there that an attacker could use?
There is no personal information on anything in that proposed VLAN currently, and in the future, the most personal stuff it will include is a chat program to replace Discord. In all, I’m assuming I can run the reverse proxy and most services (not even a dozen) on a mini PC, and then somewhere between 1-4 on a NAS. Two devices total on this VLAN, unless I learn of something that would change this plan.
If Jellyfin gets compromised, you risk everything else on the same server getting compromised, as well as everything that server can reach.
VLANs can certainly reduce what is at risk, but wouldn’t the machine running the Jellyfin client be reachable from the Jellyfin server? And if they manage to move laterally to the client machine, what could they then reach from there?
Again, still learning, but my understanding is that that’s what VLAN rules can protect against.
That depends a lot on what you do with them…
VLANs work on a layer where devices can either reach each other or they cannot.
Let’s say you have your main desktop computer in the “main” VLAN, and your Jellyfin server in the “jellyfin” VLAN, and a third server for your home-assistant in the “home-assistant” VLAN, and finally some IOT devices in the “iot” VLAN.
You connect the VLANs as follows:
- “main” can reach the Internet, but you also want to access your jellyfin and home-assistant, so you connect it to those two VLANs (“jellyfin” and “home-assistant”)
- “Jellyfin” can reach the Internet (because you want updates), but Jellyfin doesn’t need to reach anything else on your local network… However since you already connected “main”, then “jellyfin” can reach it.
- “home-assistant” needs to reach the Internet, but also the “iot” VLAN where some of the devices it controls resides. You also already connected “main” because you wanted to access home-assistant from your computer.
- “iot” is blocked from reaching the internet, and it’s only connected to the “home-assistant” VLAN because home-assistant needs to reach it.
Remember that all connected VLANs much be bidirectional.
Now someone compromises your Jellyfin. They now control and has access to everything on the Jellyfin server, but they also have network reachability to your main computer, because your “main” and “home-assistant” VLANs are connected. They can now try to exploit your main computer.
If they are successful in exploiting your main computer, then they can use your main computer to jump to the home-assistant server because again, these two VLANs are connected. And you likely have the credentials for accessing home-assistant available on your main computer somewhere.
Now they are on your home-assistant server, and they can now start trying to exploit your IOT devices.
If VLANs are connected, they don’t care which direction the traffic flows.
If you want to control traffic flow directions you need a firewall. A firewall can sit between VLANs and block traffic coming from one to other, but not the other to the one.
Remote code execution is a concern. Your server and your network as a whole (including other VLANs) are susceptible to attack if Jellyfin is compromised. If Jellyfin is running on the host, it would be trivial to hack your server (and anything else running/connected to it). If Jellyfin is in a Docker/Podman containers, it doesnt prevent attacks against the host (sandbox escape, kernel privilege escalation, etc), or against your network over some ports. Even if the server is on it’s own VLAN, a vulnerability or weakness in your router could still lead to a compromise, meaning that any devices that is in any way connected to your router (including personal devices) could be attacked.
There is a lot of depth to this topic of course. And at some point you just calculate your risks and weigh your options. There is no such thing as perfect security of course.
Reverse proxy with auth in front of the actual jellyfin login. Like pangolin.
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?
You don’t.
Gotcha I see, just checking if I missed something since that was the issue last time I tried doing something like that. These days I just yolo it and expose jellyfin to the public Internet.
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.
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.
If there was a Jellyfin app that supported adding a custom header to the server connection, you could set your reverse proxy to just let the connections with that secret key header through, and make everything else go through the extra auth middleware. But as far as I know, none of the Jellyfin apps have that feature, even though it has been requested. Lots of other selfhosted apps do have the feature though, and I use it in a few places as well.
Would you need to? Are apps a viable vector in? Basic auth in front of web ui does make sense though.
What do you mean viable? The web UI is just an app that is delivered to your browser, it makes more or less the same API requests as an app would make, so IDK why the risk would be lower with an app?
If an attacker can access the login endpoint for example to brute force or dictionary attack, it doesn’t matter if the web UI is or isn’t accessible if the login endpoint it uses is exposed for an app. The attacker could serve their own copy of the web UI and proxy requests to the API your app connects to. Blocking the html from being served doesn’t make a difference.
Okay then use a vpn.
That’s exactly the point I’m getting at. Putting an auth wall doesn’t work with many apps, and if you add exceptions to the API then you’re not really protecting anything.
@BakedCatboy @anon_8675309
I think that could be fixed with authentication through headers (netbird reverse proxy supports that, no idea about pangolin though) but apps should also support adding custom headers on requestsYes that’s what I would like to advocate for. I did something similar with LunaSea, but often people suggest doing that with Jellyfin and are not aware that almost no apps support it, and that adding exceptions for the API makes you basically as secure as not having it. But people tend to get very defensive when you try to tell them that something won’t work, so I try to phrase it as a question to see if I can get them to understand what the limitations are in a way that’s less confrontational.
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.
See if there are any apps that will handle the VPN tunneling transparently, then provide the web interface, all in one.
If you can’t find any that work like you want, I would put an authenticating reverse proxy in front of jellyfin. But last time I tried that, it only half worked. I don’t know if that’s changed.
Worst case, a reverse proxy that only exposes the necessary endpoints. Or a WAF that can block known attacks.
In any case, you should have a firewall rule as narrow as possible to only limit access to them. Static IP address if possible, then subnet, then ASN. Whatever is the most restrictive but still works.
How much access do you have to their system? I would set up a script on their end to poll https://ipv4.icanhazip.com/ and send you their IP. I would then trigger a firewall rule change on your end to that information. This keeps the access to only their IP, with maybe a few minutes between polls where it might be different.
Ask them to use the Jellyfin web, and you expose it to the public via Netbird / Pangolin locked behind SSO
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.
This is solid. I wonder if you could rig up a ddns somehow to keep it seamless?
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.
It’s exactly what it sounds like.
You really can’t assume your visitors are going to have static IPs.
What happens when they visit from their phone? A friend’s WiFi? Their home connection that has a regularly changing IP?
So far I’ve seen WAN leases expire after a long time, say months, or quarter year, so is doable. If becomes an issue I’ll work with them on a VPN solution but is a pain for non-technical users or non-supported hardware. That’s also why I explain “use from your home network only”.
What’s your concern about running it behind a reverse proxy, like caddy or nginx?
I don’t consider Jellyfin a fully secure and audited application to host, unsecured endpoints come to mind, that and the less exposed to the whole internet the better.
https://github.com/jellyfin/jellyfin/issues/13987
Things like these scare me:
https://blog.lastpass.com/posts/notice-of-recent-security-incident
afaik but I’m not sure, Jellyfin lacks support for OIDC AuthN which is a clear sign that you cannot expose this publicly.
There’s a plugin for that.
Plugin is arrived
*Archived, arrived just means it is here
You don’t say. My autocorrect had a mind of its own again. Fixed it.
says repo is archived
Oops. I tried it in the past and just linked to quickly without taking a close look at the repo. I’ve updated the above posting. Thanks for pointing this out.
Perhaps (and I know I might be weird) running pangolin on something like hetzner? (Which I do)
This is the way I do it with services. Has auth. Rules for access per service. Handles reverse proxy. And can integrate crowdsec. Not a security guru…
Pangolin?
Pangolin reverse proxy https://github.com/fosrl/pangolin
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.
What exactly about jellyfin makes this oidc style access more difficult to manage?
Jellyfin just doesn’t have it, period. There’s a third party plugin that will kind of tack it on to the Webui, but none of the Jellyfin apps will work with it.
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. 🤞
The plugin was neat, but if the clients don’t support it, it’s pretty much useless.
Mobile clients should use QuickConnect for it (statement by the sso plugin maintainer). Else it should work with everything that uses the WebUI.
Quick connect is not SSO. Because the topic is about non-technical end user friendly solutions, this isn’t a great one because this requires your user to login using a web browser on a different device and then use that for the quick connect and it’s just more clunky than it should really be.
It’s honestly easier in this situation to just configure your end users device with a mesh VPN like Tailscale or Netbird and then all they ever have to do is login with whatever password you gave them.
Does Tailscale count as a VPN for you? It’s how I roll. Well, I run my own headscale server, but the free Tailscale tier is going to be fine for any reasonably sized personal project.
Tailscale is a vpn for all that matters.
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
