this post was submitted on 26 Jun 2025
145 points (98.7% liked)

Selfhosted

46676 readers
652 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
 

What’s your go too (secure) method for casting over the internet with a Jellyfin server.

I’m wondering what to use and I’m pretty beginner at this

top 50 comments
sorted by: hot top controversial new old
[–] Decipher0771@lemmy.ca 2 points 36 minutes ago

Jellyfin through a traefik proxy, with a WAF as middleware and brute force login protected by fail2ban

[–] xnx@slrpnk.net 6 points 1 hour ago
[–] ArsonButCute@lemmy.dbzer0.com 3 points 1 hour ago

I use a cloudflare tunnel, ISP won't give me a static IP and I wanna keep my firewall locked down tight.

[–] Evil_Shrubbery@lemm.ee 20 points 3 hours ago (2 children)
[–] WhyJiffie@sh.itjust.works 1 points 17 minutes ago* (last edited 17 minutes ago)

and a local reverse proxy that can route through wireguard when you want to watch on a smart tv.

its not as complicated as it sounds, it's just a wireguard client, and a reverse proxy like on the main server.

it can even be your laptop, without hdmi cables

[–] greylinux@lemm.ee 6 points 3 hours ago (1 children)
[–] Evil_Shrubbery@lemm.ee 3 points 2 hours ago (1 children)
[–] 0ops@lemm.ee 2 points 8 minutes ago
[–] bmcgonag@lemmy.world 2 points 1 hour ago

Cheap VPS with Pangolin for Wireguard and reverse proving through the tunnel.

[–] r00ty@kbin.life 9 points 3 hours ago (1 children)

Wireguard vpn into my home router. Works on android so fire sticks etc can run the client.

load more comments (1 replies)
[–] JRaccoon@discuss.tchncs.de 13 points 4 hours ago* (last edited 4 hours ago) (11 children)

I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don't see a realistic risk in exposing Jellyfin directly to the internet. It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore.

In my setup, which I've been running for some time, I've port-forwarded only Jellyfin's HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I've also changed the Jellyfin's default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.

Anyone wanna yell at me for being an idiot and doing everything wrong? I'm genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I'm not entirely sure why.

[–] Novi@sh.itjust.works 1 points 45 minutes ago

I don't disagree, and I am one of the VPN advocates you mention. Generally there is no issue with exposing jellyfin via proxy to the internet.

The original question seemed to imply an over-secure solution so a lot of over-secure solutions exist. There is good cause to operate services, like jellyfin, via some permanent VPN.

[–] Ptsf@lemmy.world 7 points 1 hour ago

It's difficult to say exactly what all a reverse proxy adds to the security conversation for a handful of reasons, so I won't touch on that, but the realistic risk of exposing your jellyfin instance to the internet is about the same as handing your jellyfin api over to every stranger globally without giving them your user account or password and letting them do whatever they'd like for as long as they'd like. This means any undiscovered or unintentional vulnerability in the api implementation could easily allow for security bypass or full rce (remote code execution, real examples of this can be found by looking at the history of WordPress), but by siloing it behind a vpn you're far far far more secure because the internet at large cannot access the apis even if there is a known vulnerability. I'm not saying exposing jellyfin to the raw web is so risky it shouldn't be done, but don't buy into the misconception that it's even nearly as secure as running a vpn. They're entirely different classes of security posture and it should be acknowledged that if you don't have actual use for internet level access to jellyfin (external users, etc, etc) a vpn like tailscale or zero tier is 100% best practice.

[–] douglasg14b@lemmy.world 1 points 28 minutes ago* (last edited 27 minutes ago)

Jellyfin has a whole host of unresolved and unmitigated security vulnerabilities that make exposing it to the internet. A pretty poor choice.

https://github.com/jellyfin/jellyfin/issues/5415

[–] catloaf@lemm.ee 3 points 1 hour ago

The issue is not encryption, it's the unauthenticated API. People can interact with your server without an account.

[–] domi@lemmy.secnd.me 8 points 2 hours ago

Anyone wanna yell at me for being an idiot and doing everything wrong?

Not yell, but: Jellyfin is dropping HTTPS support with a future update so you might want to read up on reverse proxies before then.

Additionally, you might want to check if Shodan has your Jellyfin instance listed: https://www.shodan.io/

[–] makeitwonderful@lemmy.sdf.org 12 points 3 hours ago (1 children)

It feels like everything is a tradeoff and I think a setup like this reduces the complexity for people you share with.

If you added fail2ban along with alert email/notifications you could have a chance to react if you were ever targeted for a brute force attempt. Jellyfin docs talk about setting this up for anyone interested.

Blocking IP segments based on geography of countries you don't expect connections from adds the cost of a VPN for malicious actors in those areas.

Giving Jellyfin its own VLAN on your network could help limit exposure to your other services and devices if you experience a 0day or are otherwise compromised.

[–] douglasg14b@lemmy.world 1 points 26 minutes ago

Fail2ban isn't going to help you when jellyfin has vulnerable endpoints that need no authentication at all.

[–] frezik@lemmy.blahaj.zone 8 points 3 hours ago

Nah, setting non-standard ports is sound advice in security circles.

People misunderstand the "no security through obscurity" phrase. If you build security as a chain, where the chain is only as good as the weakest link, then it's bad. But if you build security in layers, like a castle, then it can only help. It's OK for a layer to be weak when there are other layers behind it.

Even better, non-standard ports will make 99% of threats go away. They automate scans that are just looking for anything they can break. If they don't see the open ports, they move on. Won't stop a determined attacker, of course, but that's what other layers are for.

As long as there's real security otherwise (TLS, good passwords, etc), it's fine.

If anyone says "that's a false sense of security", ignore them. They've replaced thinking with a cliche.

load more comments (4 replies)
[–] thenose@lemmy.world 1 points 2 hours ago

I just use tailscale. I am thinking about external share options but for me and my closests just plain simple tailscale

[–] oong3Eepa1ae1tahJozoosuu@lemmy.world 27 points 5 hours ago (11 children)

Nginx in front of it, open ports for https (and ssh), nothing more. Let's encrypt certificate and you're good to go.

[–] SapphironZA@sh.itjust.works 1 points 1 hour ago (1 children)

Why would you need to expose SSH for everyday use? Or does Jellyfin require it to function?

Maybe leave that behind some VPN access.

[–] WhyJiffie@sh.itjust.works 1 points 11 minutes ago

I agree, but SSH is more secure than Jellyfin. it shouldn't be exposed like that, others in the comments already pointed out why

[–] Novi@sh.itjust.works 24 points 5 hours ago (6 children)

I would not publicly expose ssh. Your home IP will get scanned all the time and external machines will try to connect to your ssh port.

Sorry, misunderstanding here, I'd never open SSH to the internet, I meant it as "don't block it via your server's firewall."

[–] 30p87@feddit.org 28 points 5 hours ago

fail2ban with endlessh and abuseipdb as actions

Anything that's not specifically my username or git gets instantly blocked. Same with correct users but trying to use passwords or failing authentication in any way.

[–] drkt@scribe.disroot.org 9 points 4 hours ago (1 children)

They can try all they like, man. They're not gonna guess a username, key and password.

[–] Ptsf@lemmy.world 6 points 1 hour ago (1 children)

Doesn't take that to leverage an unknown vulnerability in ssh like:

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

That's why it's common best practice to never expose ssh to raw internet if you can help it; but yes it's not the most risky thing ever either.

[–] drkt@scribe.disroot.org 3 points 1 hour ago (2 children)

If you're going to open something, SSH is far, far more battle-tested than much other software, even popular software. Pragmatically, If someone is sitting on a 0-day for SSH, do you genuinely think they're gonna waste that on you and me? Either they're gonna sell it to cash out as fast as possible, or they'll sit on it while plotting an attack against someone who has real money. It is an unhealthy level of paranoia to suggest that SSH is not secure, or that it's less secure than the hundreds of other solutions to this problem.

Here is my IP address, make me eat my words.
2a05:f6c7:8321::164 | 89.160.150.164

[–] pm_me_your_puppies@infosec.pub 1 points 12 minutes ago

You got balls to post you public addresses like that... I mean I agree with you wholeheartedly and I also have SSH port forwarded on my firewall, but posting your public IP is next-level confidence.

Respect.

[–] Ptsf@lemmy.world 3 points 1 hour ago

I linked a relevant vulnerability, but even ignoring that, pragmatically, you feel they'd be targeting specific targets instead of just what they currently do? (That, by the way, is automating the compromise of vulnerable clients in mass scale to power botnets). Any service you open on your device to the internet is inherently risky. Ssh best practices are, and have been since the early days, not to expose it to the internet directly.

load more comments (3 replies)
load more comments (9 replies)
[–] JiveTurkey@lemmy.world 2 points 3 hours ago

I'm using jf on unraid. I'm allowing remote https only access with Nginx Proxy Manager in a docker container.

load more comments
view more: next ›