this post was submitted on 21 Aug 2025
116 points (97.5% liked)

Selfhosted

50716 readers
530 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.

Resources:

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

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
116
Your fav guide/method for securing Jellyfin? (lemmy.world)
submitted 1 day ago by Profligate_parasite@lemmy.world to c/selfhosted@lemmy.world
62 comments fedilink hide all child comments
 

Hello. I have just recently started with self hosting my media with Jellyfin... and I am LOVING it! I had been carrying around media players for decades, with everyone looking at me like an insane crank for not giving up on my hundreds of gigs of media for SAS things like spotify... now they're jealous! We've come full circle!

Annnyway. Obviously, I want to access the server anywhere, and don't want to just raw-dog an open port to the internet- yikes!

There are SO MANY ways and guides and thoughts on this, I'm a bit overwhelmed and looking for your thoughts on the best way to start off... it doesn't have to be 'fort knox' and I am sure I'll adjust and pivot as I learn more... but here are the options I know of (did I miss any?):

  • Tailscale VPN connection

  • Reverse Proxy with Caddy or similar (this is recommended as easy in the jellyfin official guides and thus is my current leading contender!)

  • Docker/VM 'containerized' server with permissions/access control

What are your thoughts on the beginner-friendly-ness and ease of setup/management of these? This is exclusively for use by me and my family, so I don't need something that's easy for anyone to access with credentials... just our handful of devices.

Please don't laugh, but I'm currently hosting on a Raspberry Pi5 with a big-ass harddrive attached (using CasaOS on a headless Ubuntu Server). I know this is JANK as far as self-hosting goes, and plan to upgrade to something like NAS in the future, but I'm still researching and learning, and aside from shitty video transcoding, it's working fine for now... Thank you in advance for your advice, help and thoughts!

top 50 comments
sorted by: hot top controversial new old
[–] abruptly8951@lemmy.world 2 points 2 hours ago

Reverse proxy with mTLS in front might be a simple solution depending on your setup

https://www.youtube.com/watch?v=YhuWay9XJyw

[–] ohshit604@sh.itjust.works 8 points 14 hours ago* (last edited 14 hours ago)

I opted to remove Jellyfins default login form and require Keycloak for SSO, my Jellyfin instance is technically facing the internet but my reverse proxy has Fail2Ban in front of it blocking non-whitelisted IP’s, makes it easier to share with other people this way compared to having to explain VPN’s to non-tech savvy people,

[–] ksyko@lemmy.world 3 points 15 hours ago

I use netbird. I found it easy to setup and they also have an android app. You also get a neat URL for each device. I havent tried any other options apart fromthis and wireguard. Wireguard wasnt easy to setup for me.

[–] glizzyguzzler@piefed.blahaj.zone 15 points 1 day ago* (last edited 1 day ago) (5 children)

Reading jellyfin’s issues it’s clear its web ui and API cannot be allowed to talk to the general internet.

I’d push for a VPN solution first. Tailscale or wireguard. If you’re happy with cloudflare sniffing all traffic and that they make take it away suddenly someday use their tunnel with authentication.

The only other novel solution I’d suggest is putting jellyfin behind an Authentik wall (not OIDC, though you can use OIDC for users after the wall). That puts security on Authentik, and that’s their only job so hopefully that works. I’d use that if VPN (tailscale or wireguard) are problematic for access. The downside is that jellyfin apps will not be able to connect, only web browsers that can log into the Authentik web ui wall.

Flow would go caddy/other reverse proxy -> Authentik wall for jellyfin -> jellyfin

I’d put everything in docker, I’d put caddy and Authentik in a VM for a DMZ (incus + Zabbly repo web ui to manage the VM), I’d set all 3 in the compose to read-only, user:####:####, cap-drop all, no new privileges, limited named networks.

Podman quadlets would be even better security than docker, but there’s less help for that (for now). Do docker and get something working to start, then grow from there

[–] jjlinux@lemmy.zip 14 points 1 day ago

This is absolutely critical. Jellyfin is not made with security as an important factor.

[–] Profligate_parasite@lemmy.world 1 points 16 hours ago (2 children)

Thanks for your comment. There are several things/products/methods you mention that I'm not familiar with and/or don't understand:

Authentik Wall OIDC DMZ Incus Zabbly "in the compose" cap-drop all Podman quadlets

As I mentioned, I'm new here. I could just put each of these in duckduckgo in succession, but do you have a particular guide or link that describes any of this for someone less familiar with the process than yourself?

[–] glizzyguzzler@piefed.blahaj.zone 0 points 6 hours ago

Other user summarized very well.

No I have accrued knowledge of those things over time, no one stop shop that I know of. But knowing these things exist and their general use are half the battle!

I was lazy with the “Authentik wall” because I couldn’t remember what they called it. It is the “proxy” option in their “provider” section https://docs.goauthentik.io/add-secure-apps/providers/proxy/ . There are many guides for Authentik at least, it’s complicated but you only need to do specific things for it to work - and most tell you and the rest are applicable via matching similar looking things.

OIDC is an open login protocol many things support. I think jellyfin can use it with a plugin, but keep in mind that regular user creation still exists so it’s not a security and convenience feature like for most things, it’s just a convenience feature.

DMZ is de militarized zone. I used the acronym to mean a gap between your system and a system that deals directly with the outside Internet. That gap is the VM separation. LXC containers and docker containers do not have that separation, I deploy Internet-facing stuff in a VM as extra insurance in case they get zero-day-hacked; it means the rest of my server will hopefully not get ransomwared.

Incus is an alternative to proxmox, but less needy since it doesn’t require its own Linux kernel. Zabbly is a package source (vs built-in Debian sources) that has the web ui in it. See their documentation for installation, it tells you how to add the Zabbly package; use the “stable” version if you do use incus.

“In the compose” means in the docker-compose.yml file.

‘Cap-drop: all’ is an entry you can make in the docker-compose file. It increases security. All of the ones I listed are entries you can add to the docker-compose file. You’ll likely need a

tmpfs: /tmp

In the compose file you use read only.

Podman is the superior alternative to docker, and Podman quadlets are a way to deploy containers (they have a couple ways, like docker does - you don’t need a docker-compose.yml file to run docker containers). But it’s new and doesn’t have the community knowledge support via searching like docker does.

Hope that helps!

[–] MaggiWuerze@feddit.org 1 points 11 hours ago

The general jist is, do not expose Jellyfin to the internet. Neither via a port nor through a reverse proxy. Its simply not build secure enough for that.

Use docker to make the setup easier, then use tailscale or whatever VPN solution to allow users from outside your network to access it.

All of the additional authentication solutions mentioned break client compatibility. Then you could only watch through a browser.

Install docker, deploy Jellyfin to it, test it. They both have good guides on their respective websites.

load more comments (3 replies)
[–] frongt@lemmy.zip 32 points 1 day ago (3 children)

VPN. Jellyfin is not intended for direct exposure to the Internet.

You should run it in docker anyway for convenience. A reverse proxy is optional, but I use traefik also for convenience (so that I can just use domain names on the same port, and so that it can automatically fetch certs).

[–] interdimensionalmeme@lemmy.ml 2 points 14 hours ago (1 children)

Use the reverse proxy for access control ? Then you don't need to install extra software to access it remotely ?

[–] frongt@lemmy.zip 1 points 14 hours ago

I don't think jellyfin supports that either. I tried it a while back and only saw partial success.

[–] Saik0Shinigami@lemmy.saik0.com 18 points 1 day ago (3 children)

Jellyfin is not intended for direct exposure to the Internet.

https://jellyfin.org/docs/general/post-install/networking/

There are multiple ways of exposing Jellyfin to the outside - the most common ones are:
forwarding its Ports directly to the internet (not recommended!)
forwarding through a Reverse Proxy
using a VPN connection to enter the Network
use a VPS to Reverse Proxy to your home network

Intended... not recommended. The reverse proxy one should also not be recommended until they resolve the unauthed endpoints issue as well really. Security is a weak point on Jellyfin in general.

[–] fmstrat@lemmy.nowsci.com 3 points 17 hours ago (1 children)

I've tested the worst of these endpoints and they were already secured, just the issues haven't been updated.

For instance, from the security split-out issue list: https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825369811

I took the only one that could lead to admin/system infiltration (LDAP config escalation, others are about media access), and found it to have already been secured: https://github.com/jellyfin/jellyfin/issues/13989

[–] Saik0Shinigami@lemmy.saik0.com 0 points 16 hours ago* (last edited 16 hours ago) (1 children)

others are about media access

Yup, and these are the biggest risks IMO. I find the well organized, big media companies with deep pockets and a few basic scripts that we know to work to be the biggest vector of liability.

https://github.com/jellyfin/jellyfin/issues/1501
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2071798575 (and the following comments)
https://github.com/jellyfin/jellyfin/issues/13984

A person's biggest threat running Jellyfin is going to be the media companies themselves. Sony (the company known for installing rootkits on people's computers) can pre-hash a list of their movies with commonly config'd locations/name schemas for their content and enumerate your system for if you have their content. Since you don't have any authentication on the endpoint, they're likely not violating any law through circumvention. The "random UUID" is just the MD5 hash of the path/filename. So it's actually highly guessable... especially for people using default docker configs and *arr stacks and you normalize names using these tools.

Their response was "this attack isn't in the wild"(as if they actually know... running a script and checking a few hundred thousand requests to go through a list of movies isn't all that taxing and users won't even notice it to report it... let alone have enough logging to notice it to begin with) and "it breaks compatability, so we don't want to do it". Which I find laughable. It turned me off from Jellyfin all together.

Edit: And because every time I bring up the issue I get downvoted for "fear mongering"... There are answers to resolve it... you need to use non-standard naming schemes in your files/folder structure and fail2ban. But that expects users to do that... And I could do that... but it's a security risk non-the-less and the developers response to the risk being what it is is what's scary to me.

Edit2: The LDAP one... I should clarify I don't care about that one since well... requires you to additionally config stuff that most users won't. But the media exposure issues are default and universal and require setting things "non-standard" to have any protection from, which users generally WON'T do.

[–] fmstrat@lemmy.nowsci.com 2 points 14 hours ago (1 children)

Well, I wouldn't say the media issues are worse than a full domain access issue, but despite my comment above, I agree with you.

The security split-issue feels reminiscent of when Plex didn't use SSL and wouldn't implement it until a white-hat POC token exploit was produced and provided to them (of which I was the author). If JF was my project, these would be top of my list.

[–] Saik0Shinigami@lemmy.saik0.com 1 points 14 hours ago (1 children)

Well I don't mean to harp on it... Plex in this instance is much better off. When provided proof of the problem they fixed it. Jellyfin has had issues about this going back to 2019... 6 years ago. Still no fix in sight. And the first ticket I linked proved the concept can be abused. With the issues getting hidden because "We're closing this because we're consolidating... oh wait... we're closing it because we're splitting the issues out." I've legit had people tell me that the problems were fixed because they saw the issue closed.

And now I hear that JF is even deprecating SSL and mandating proxy or esoteric custom config to implement SSL themselves again... Seems they're going backwards?

I had Jellyfin setup for just myself because I'd love to get away from the risk of Plex screwing shit up (and to get off their SSO). But the frustration of the dev responses to some of these issues and the fact that I'm literally the only person who's able to deal with the restrictions needed to keep it secure... I just turned it off. I didn't want to deal with managing two systems because my kids/wife/other family couldn't figure out how to use it.

[–] fmstrat@lemmy.nowsci.com 1 points 10 hours ago

All fair. For me, their SSL direction is a good one. Most self-hosters use a central proxy, so why maintain one users just ask to disable.

I do run mine behind a VPN, always will and recommend others do the same.

load more comments (2 replies)
[–] Profligate_parasite@lemmy.world 1 points 16 hours ago (1 children)

Yes, that's the whole reason for the post, as I said above. When you say "docker anyway for convenience" what do you mean? What's the benefit of docker? Do you have any resources that would let someone entirely new to docker understand/guide through it? You mention Traefik as well... never heard of it till this post.... what is it? Why is it convenient?

[–] frongt@lemmy.zip 1 points 15 hours ago

Docker packs the whole application and its dependencies into a container, hence the name. You can run and delete that application as much as you want without affecting the host system. (But you should probably keep your media library and config outside the container, and use a bind mount. The setup documentation covers this.)

[–] bootstrap@slrpnk.net 25 points 1 day ago (2 children)

I have used Tailscale for about a year now. Flawless for a small ecosystem and couple of people and doesnt expose anything.

Bonus of routing all my traffic through pi-hole at home and then through VPN client on router

[–] modular950@lemmy.zip 4 points 1 day ago

tailscale here as well. it's honestly 2ezpz to set up, and that's about it! this also allows you to access other services you may be hosting.

you can also specify an exit node that your traffic will route through if you are connected to your tailnet. for example, if you had a VPN client on your home router, you could set a PC on that network as your exit node and your remote traffic through tailscale would ultimately hit your home network and then out through your PC -> VPN -> Internet setup.

[–] thejml@sh.itjust.works 8 points 1 day ago (1 children)

I second this. Especially for the PiHole access. Its also handy as it covers any of my self-hosted stuffs.

[–] Profligate_parasite@lemmy.world 3 points 1 day ago (1 children)

Do you mind explaining PiHole to me? I've heard it mentioned, not sure what it is.

[–] quokka1@mastodon.au 4 points 1 day ago

@Profligate_parasite @thejml #PiHole sits in your network replacing your existing DNS server you may have configured. By using a specified blocklist(s) it's mostly used to block adverts and malware sites. Can be very effectives. Can take a little tinkering, for example one side-effect for me was it blocking a local TV streaming app.
To start with I put one on a free cloud provider, with a VPN from my router to it and played with it until I was happy.

[–] jjlinux@lemmy.zip 7 points 1 day ago (1 children)

Easy, mine is local only and on it's own VLAN.

[–] non_burglar@lemmy.world 14 points 1 day ago* (last edited 1 day ago)

I think the big deciding factor is how many folks will be watching remotely.

For my case, I use a VPN to tunnel back to my network and watch jellyfin that way. My son also lives away and watches jellyfin, but for him I simply punch a hole in my firewall for only his public ip, which doesn't change much.

This works for me, but if I had to host for any more ppl, I would likely go the caddy route.

[–] possiblylinux127@lemmy.zip 4 points 1 day ago (1 children)

Put Jellyfin behind something else that requires authentication before you can access Jellyfin at all

[–] MaggiWuerze@feddit.org 7 points 18 hours ago (1 children)

Which breaks basically every client, since none of them can deal with basic auth getting in the way

[–] possiblylinux127@lemmy.zip 1 points 12 hours ago (1 children)

Well the other option would be a VPN

[–] MaggiWuerze@feddit.org 1 points 11 hours ago* (last edited 11 hours ago) (1 children)

Yeah and that kills Jellyfin as a drop in replacement for Plex. I would've deployed it years ago with a subdomain and given it to friends if it was as easily shareable as Plex

[–] possiblylinux127@lemmy.zip 1 points 11 hours ago (1 children)

I personally wouldn't expose anything to the internet. You could always setup a computer on a different network that routes traffic over netbird

[–] MaggiWuerze@feddit.org 1 points 11 hours ago (1 children)

That doesn't solve the glaring security issues Jellyfin has. It just changes the computer through which they are accessed

[–] possiblylinux127@lemmy.zip 1 points 3 hours ago* (last edited 2 hours ago)

It does though

Do not expose Jellyfin to the internet. Local network is mostly fine since the real threats are the bots

[–] ctry21@sh.itjust.works 6 points 1 day ago (1 children)

I've tried tailscale and cloudflare tunnels in the past and ended up just using PiVPN to set up a WireGuard VPN on my Pi5. Tailscale for some reason was very slow for me, and cloudflare tunnels have a 100mb limit iirc which isn't ideal for streaming. PiVPN is quite straightforward, it sets everything up for you and all you have to do is forward a UDP port. That was the bit I was most worried about, but, unless I've misunderstood something, because a UDP port will just ignore invalid requests to the outside world it will appear closed so it's not very risky. It then generates a key for each device which you can scan from a QR code onto your VPN client. I have my phone set to auto-connect to the tunnel when I disconnect from my home wifi network and the tunnel is fast enough that I've accidentally turned off my phone's wifi connection before and streamed a TV show through the tunnel over mobile data and not noticed any difference in speed.

[–] bagodogs@sh.itjust.works 3 points 1 day ago

I hadn't thought to automate connecting to Wireguard when not on my home network, that's a good call. I've just set up Tasker on my phone and tablet.

[–] BaroqueInMind@piefed.social 6 points 1 day ago* (last edited 1 day ago) (2 children)

I hide it behind Cloudflare. I assume that since most of the world pays them for domain security, and if Cloudflare goes down so does half the internet, I thought to try them out. Best decision I've made. They blocked substantial DDoS attempts on my IP, a fuck ton of malicious web scrapers that attempt CVEs, and they also allow me to have very specific users access to my domain using complex allow lists, zero-trust, and DNS over HTTPS.

[–] ryokimball@infosec.pub 5 points 1 day ago (3 children)

I heard something about cloudflare not being stream friendly. Guess jellyfin doesn't count?

[–] aislopmukbang@sh.itjust.works 6 points 1 day ago (1 children)

used to be against terms of use for proxy, the forbidding language has been gone for a year or two now

load more comments (1 replies)
[–] AmazingAwesomator@lemmy.world 4 points 1 day ago (1 children)

not the person you replied to, but i have been using cloudflare zero trust for my streaming needs; have not gotten a complaint yet.

just make sure you have the upload bandwidth.

load more comments (1 replies)
load more comments (1 replies)
load more comments (1 replies)
[–] MehBlah@lemmy.world 5 points 1 day ago

Wireguard tunnels with a ssh tunnel as a backup.

[–] Egonallanon@feddit.uk 4 points 1 day ago

Caddy + crowd sec + some kind of auth solution is what I'm aiming for though I haven't got authentik working with it yet so I haven't opened it up yet. I wouldn't want to do jellyfish without the auth solution though as there local stuff isn't so robust.

VPN in and a few local users would be the most secure if you haven't got too many folks connecting.

[–] cupcakezealot@piefed.blahaj.zone 4 points 1 day ago (1 children)

i only use it for my family so like just me, my brother, and my parents so i just spun up a subdomain and configured apache to reverse proxy and use certbot for a lets encrypt certificate so i'm not exposing my port or ip. (the subdomain is just hosted on an ec2 server that i was using anyway)

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