I use a reverse proxy via NGINX Proxy Manager to expose to the web but allow easy access for my users. I pay $10 a year for a domain name to make access easier.
this post was submitted on 25 Apr 2025
80 points (97.6% liked)
Selfhosted
46327 readers
728 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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
You should maybe reconsider this for security reasons. You should implement a Whitelist or a VPN. Jellyfin is notoriously insecure software, check here:
Just please implement a VPN or Whitelist, do not just open a port and go
Yes that is the GitHub issue I was referring to
I use a VPS and a Wiregusrd tunnel together with geoblocking and fail2ban. I've written my setup down, maybe this will help you https://codeberg.org/skjalli/jellyfin-vps-setup
Oof, a lot of vitriol in this thread.
In the end, security is less about tooling and config, and more about understanding the risks and acting accordingly.
I expose jellyfin to the internet, but only to a specific public IP. That reduced my risk considerably.
I expose jellyfin to the internet, and some precautions I have taken that I don't see mentioned in these answers are: 1) run jellyfin as a rootless container, and 2) use read-only storage where ever possible. If you have other tools managing things like subtitles and metadata files before jellyfin there's no reason for jellyfin to have write access to the media it hosts. While this doesn't directly address the documented security flaws with jellyfin, you may as well treat it like a diseased plague rat if you're going to expose it. To me, that means worst case scenario is the thing is breached and the only thing for an attacker to do is exfiltrate things limited to jellyfin.
I have it as an unprivileged container behind a reverse proxy and HTTPS/HSTS. I know it's not perfect but I keep backups of important shit and monitor things regularly.
I agree that Jellyfin needs to improve its API security, though. Their excuse that "it would break clients on old APIs" is moot when C# comes with API versioning features out of the box.
You can share jellyfin over the net.
The security issues that tend to be quoted are less important than some people claim them to be.
For instance the unauthorized streaming bug, often quoted as one of the worst jellyfin security issues, in order to work the attacker need to know the exact id of the item they want to stream, which is virtually impossible unless they are or have been an authorized client at some point.
Just set it up with the typical bruteforce protections and you'll be fine.
It's not impossible, Far from it. The ids are not random uuids but hashes derived from the path. Since most people have a similar setup to organize their media, this gets trivial very fast
load more comments
(3 replies)
Fine is a relative term
You probably are fine but the company who is getting attacked by your compromised machine isn't
I don't think jellyfin vulnerabilities could lead to a zombified machine. At least I've not read about something like that happening.
Most Jellyfin issues I know are related to unauthorized API calls of the backend.
I think it is a matter of time honestly.
Jellyfin has grown enough in popularity that it is likely a target for a state actor looking to create some minions. Just because there isn't any known remote code execution vulnerabilities doesn't mean there couldn't be one in the future.
Maybe I'm being paranoid but it seems way safer to just not expose Jellyfin.
Any software can have zero-day exploits for that matter.
That's is absolutely true
Avoid exposing things unless you really need to and follow best practices.
This. Just setup fail2ban or similar in front of Jellyfin and you'll be fine.
You can share jellyfin on the net. I do.
The issues shared wide and large are mostly moot points, where the attacker needs to already have access to the jellyfin itself to have any surface.
Its FUD and I am convinced spread by Plex people in an effort to cover up their fuckup and enshittyfication.
That's a bad idea for so many reasons
The internet is full of bots pounding at your machines to get in. It is only a matter of time until the breach Jellyfin. At the very least you want a reverse proxy with proper security.
I don't see why you would put something like Jellyfin in the internet. Use a VPN solution.
I have had jellyfin exposed to the net for multiple years now.
Countless bots probing everyday, some banned by my security measures some don't. There have never been a breach. Not even close.
To begin with, of you look at what this bots are doing most of them try to target vulnerabilities from older software. I have never even seen a bot targeting jellyfin at all. It's vulnerabilities are not worth attacking, too complex to get it right and very little reward as what can mostly be done is to stream some content or messing around with someo database. No monetary gain. AFAIK there's not a jellyfin vulnerability that would allow running anything on the host. Most vulnerabilities are related to unauthorized actions of the jellyfin API.
Most bots, if not all, target other systems, mostly in search of outdated software with very bad vulnerabilities where they could really get some profit.
Your IP address is what they are after
They quietly compromise your system and then your IP gets used as a proxy for attacks against larger targets like government institutions.
How would you know that you were compromised?
I know this sounds far fetched but if you remember there was a Lastpass breach due to Plex. You need to very careful with the public internet.
IP addresses are fairly public.
In order to get that kind of infection there need to be a serious vulnerability. None of the services I expose have those kind of vulnerabilities, and I keep them updated.
A Zero-day may be possible, but it can happen with any software.
Any way, even if some of my services got infected that way, I have them all in docker containers. If they managed somehow to insert any malicious software it would have disappeared in the next restart of the container.
And in order to have a software that breaks out of the container it would need to also have some sort of zero-day docker exploit. Two zero-days needed for accomplish that...
Every expose software I have is running on a caddy reverse proxy. And caddy is the only authorized author on my firewall so it gets more difficult to try to run an unexpected malicious software through it.
The internet is full of bots pounding at your machines to get in. It is only a matter of time until the breach Jellyfin.
If you are talking about brute force attacks for your password, then use a good password.. and something like fail2ban to block ips that are spamming you.
This point doesn't exactly match, but: public services like google auth don't require users use vpns. They have a lot more money to keep stuff secure, but you may see my point.. auth isn't too trivial of a feature to keep secure nowadays. They implement similar protections, something to block spammers and make users have good passwords (if you dont use a good password, you are still vulnerable on any service).
The password is totally irrelevant for the most part. The worst case is that they get access to the dashboard
The problem is when major security vulnerabilities are found like remote code execution
I love Jellyfin and use it. I also think the security issues are very serious and it's irresponsible to not fix them. At the very least they can make a new API and give users the option to enable or disable the insecure one until clients get updated. But they don't.
I've decided to remove public access to my Jellyfin server until it's resolved, though it's still accessible behind my VPN.
load more comments
(8 replies)
Netbird/Tailscale
You also could use Wireguard as it is a p2p protocol by default.
If you have IPv6 access you could put in on a IPv6 address
When I did this I set up a VPN on my network and forced anyone that wanted to use it to get on my network.
load more comments
(7 replies)
There are two routes. VPN and VPS.
VPN; setup wireguard and offer services to your wireguard network.
VPS; setup a VPS to act as a reverse proxy for your jellyfin instance.
Each have their own perks. Each have their own caveats.
The VPS would still involve exposing it
You're exposing your jellyfin instance to a single IP, your VPS. That's what a reverse proxy is.
You block all communication from any IP but local, and your VPS IP from jellyfin, and forward web traffic from your VPS to your jellyfin instance. It's not the same as exposing your jellyfin instance directly. Not sure why I have to explain that...but here we are, I guess.
I do. I run it behind a caddy service so it's secured with an SSL. The port is running on a high non standard one. I do keep checking access logs but haven't had a peep apart from the 1 person I shared it with
load more comments
(2 replies)
view more: next ›