this post was submitted on 26 Jun 2025
258 points (98.9% liked)

Selfhosted

46671 readers
1080 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
[–] oong3Eepa1ae1tahJozoosuu@lemmy.world 44 points 13 hours ago (12 children)

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

[–] Novi@sh.itjust.works 41 points 13 hours ago (8 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.

[–] 30p87@feddit.org 38 points 13 hours ago (1 children)

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.

[–] mosiacmango@lemm.ee 12 points 6 hours ago* (last edited 6 hours ago)

Youve minimized login risk, but not any 0 days or newly discovered vulnerabilites in your ssh server software. Its still best to not directly expose any ports you dont need to regularly interact with to the internet.

Also, Look into crowdsec as a fail2ban replacement. Its uses automatically crowdsourced info to pre block IPs. A bit more proactive compared to abuseipdb manual reporting.

[–] drkt@scribe.disroot.org 11 points 12 hours ago (2 children)

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

[–] Ptsf@lemmy.world 11 points 9 hours 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 12 points 9 hours ago (4 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

[–] Ptsf@lemmy.world 5 points 9 hours 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 (1 replies)

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

[–] troed@fedia.io 5 points 12 hours ago

So? Pubkey login only and fail2ban to take care of resource abuse.

load more comments (4 replies)
load more comments (11 replies)
[–] Evil_Shrubbery@lemm.ee 35 points 11 hours ago (2 children)
[–] greylinux@lemm.ee 7 points 11 hours ago (2 children)
load more comments (2 replies)
[–] WhyJiffie@sh.itjust.works 7 points 8 hours ago* (last edited 8 hours ago) (1 children)

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

load more comments (1 replies)
[–] Vanilla_PuddinFudge@infosec.pub 18 points 6 hours ago* (last edited 6 hours ago) (1 children)

Jellyfin isn't secure and is full of holes.

That said, here's how to host it anyway.

  1. Wireguard tunnel, be it tailscale, netbird, innernet, whatever
  2. A vps with a proxy on it, I like Caddy
  3. A PC at home with Jellyfin running on a port, sure, 8096

If you aren't using Tailscale, make your VPS your main hub for whatever you choose, pihole, wg-easy, etc. Connect the proxy to Jellyfin through your chosen tunnel, with ssl, Caddy makes it easy.

Since Jellyfin isn't exactly secure, secure it. Give it its own user and make sure your media isn't writable by the user. Inconvenient for deleting movies in the app, but better for security.

more...

Use fail2ban to stop intruders after failed login attempts, you can force fail2ban to listen in on jellyfin's host for failures and block ips automatically.

More!

Use Anubis and yes, I can confirm Anubis doesn't intrude Jellyfin connectivity and just works, connect it to fail2ban and you can cook your own ddos protection.

MORE!

SELinux. Lock Jellyfin down. Lock the system down. It's work but it's worth it.

I SAID MORE!

There's a GeoIP blocking plugin for Caddy that you can use to limit Jellyfin's access to your city, state, hemisphere, etc. You can also look into whitelisting in Caddy if everyone's IP is static. If not, ddns-server and a script to update Caddy every round? It can get deep.

Again, don't do any of this and just use Jellyfin over wireguard like everyone else does(they don't).

[–] oyzmo@lemmy.world 6 points 4 hours ago (1 children)

Wow, a "for dummies" guide for doing all this would be great 😊 know of any?

load more comments (1 replies)
[–] JRaccoon@discuss.tchncs.de 18 points 12 hours ago* (last edited 2 hours ago) (10 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.~~ (See Edit 2)

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.

Edit: Thank you everyone for your responses. While I don't agree with everything, the new insight is appreciated.

Edit 2: I've been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:

Deprecation Notice: Jellyfin’s internal handling of TLS/SSL certificates and configuration in the web server will be removed in a future version. No changes to the current system have been made in 10.11, however future versions will remove the current system and instead will provide advanced instructions to configure the Kestrel webserver directly for this relatively niche usecase. We strongly advise anyone using the current TLS options to use a Reverse Proxy for TLS termination instead if at all possible, as this provides a number of benefits

[–] makeitwonderful@lemmy.sdf.org 16 points 11 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 7 points 8 hours ago (1 children)

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

load more comments (1 replies)
[–] domi@lemmy.secnd.me 13 points 10 hours ago (3 children)

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/

load more comments (3 replies)
[–] Ptsf@lemmy.world 11 points 9 hours 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.

[–] frezik@lemmy.blahaj.zone 9 points 11 hours ago (1 children)

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 (1 replies)
[–] catloaf@lemm.ee 9 points 9 hours ago

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

[–] douglasg14b@lemmy.world 8 points 8 hours ago* (last edited 8 hours 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

[–] anonion@lemmy.anonion.social 6 points 11 hours ago

I think the reason why its generally suggested to use a VPN is because it reduces the risk of intrusion to almost zero. Folks that are not network/sys admin savy would feel safer with the lowest risk solution. Using the port forward method, there could be configuration mistakes made which would unintentionally expose a different service or parts of their home network they don't want exposed. And then there's the possibility of application vulnerabilities which is less of an issue when only VPN users can access the application. That being said, I do expose some services via port forwarding but that's only because I'm comfortable with ensuring its secure.

Reverse proxy is really useful when you have more than one service to expose to the internet because you only have to expose one port. It also automates the certificate creation & simplifies firewall rules inside the home network

load more comments (3 replies)
[–] xnx@slrpnk.net 15 points 9 hours ago
[–] r00ty@kbin.life 12 points 11 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)
[–] hietsu@sopuli.xyz 12 points 13 hours ago (5 children)

Use a reverse proxy (caddy or nginx proxy manager) with a subdomain, like myservice.mydomain.com (maybe even configure a subdir too, so …domain.com/guessthis/). Don’t put anything on the main domain / root dir / the IP address.

If you’re still unsure setup Knockd to whitelist only IP addresses that touch certain one or two random ports first.

So security through obscurity :) But good luck for the bots to figure all that out.

VPN is of course the actually secure option, I’d vote for Tailscale.

load more comments (5 replies)
[–] gravitywell@sh.itjust.works 12 points 12 hours ago (7 children)

I rent a cheap $5/mo VPS and use it to run a wireguard server with wgeasy and nginx proxy manager. Everything else runs on my home server connected by wireguard.

load more comments (7 replies)
[–] FrostyCaveman@lemm.ee 10 points 2 hours ago* (last edited 2 hours ago)

I think my approach is probably the most insane one, reading this thread…

So the only thing I expose to the public internet is a homemade reverse proxy application which supports both form based and basic authentication. The only thing anonymous users have access to is the form login page. I’m on top of security updates with its dependencies and thus far I haven’t had any issues, ever. It runs in a docker container, on a VM, on Proxmox. My Jellyfin instance is in k8s.

My mum wanted to watch some stuff on my Jellyfin instance on her Chromecast With Google TV, plugged into her ancient Dumb TV. There is a Jellyfin Android TV app. I couldn’t think of a nice way to run a VPN on Android TV or on any of her (non-existent) network infra.

So instead I forked the Jellyfin Android TV app codebase. I found all the places where the API calls are made to the backend (there are multiple). I slapped in basic auth credentials. Recompiled the app. Deployed it to her Chromecast via developer mode.

Solid af so far. I haven’t updated Jellyfin since then (6 months), but when I need to, I’ll update the fork and redeploy it on her Chromecast.

[–] Merlin@discuss.tchncs.de 7 points 7 hours ago

I just install tailscale at family houses. The limit is 100 machines.

[–] Novi@sh.itjust.works 7 points 13 hours ago

Over the top for security would be to setup a personal VPN and only watch it over the VPN. If you are enabling other users and you don't want them on your network; using a proxy like nginx is the way.

Being new to this I would look into how to set these things up in docker using docker-compose.

[–] bl_r@lemmy.dbzer0.com 7 points 13 hours ago (1 children)

Tailscale, with nginx for https.

Very easy, very simple, just works, and i can share my jellyfin server with my friends

load more comments (1 replies)
[–] chug-capture-ahoy@piefed.social 6 points 11 hours ago

Tailscale - funnel

Just that

[–] thenose@lemmy.world 6 points 10 hours ago

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

[–] hellequin67@lemmy.zip 6 points 13 hours ago (4 children)

Personally I use twingate, free for 5 users and relatively straightforward to set up.

load more comments (4 replies)

If it’s just so you personally can access it away from home, use tailscale. Less risky than running a publicly exposed server.

[–] Darkassassin07@lemmy.ca 6 points 13 hours ago* (last edited 13 hours ago) (1 children)

An $11/yr domain pointed at my IP. Port 443 is open to nginx, which proxies to the desired service depending on subdomain. (and explicitly drops any connection that uses my raw ip or an unrecognized name to connect, without responding at all)

ACME.sh automatically refreshes my free ssl certificate every ~2months via DNS-01 verification and letsencrypt.

And finally, I've got a dynamic IP, so DDClient keeps my domain pointed at the correct IP when/if it changes.


There's also pihole on the local network, replacing the WAN IP from external DNS, with the servers local IP, for LAN devices to use. But that's very much optional, especially if your router performs NAT Hairpinning.

This setup covers all ~24 of the services/web applications I host, though most other services have some additional configuration to make them only accessible from LAN/VPN despite using the same ports and nginx service. I can go into that if there's interest.

Only Emby/Jellyfin, Ombi, and Filebrowser are made accessible from WAN; so I can easily share those with friends/family without having to guide them through/restrict them to a vpn connection.

load more comments (1 replies)
[–] ArsonButCute@lemmy.dbzer0.com 6 points 9 hours ago (1 children)

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

load more comments (1 replies)
[–] swearengen@sopuli.xyz 6 points 7 hours ago

I'm just using caddy and a cheap $2 a year .top domain with a $4 a month VPS. Works for my users, I only have 3 users on my server.

[–] bmcgonag@lemmy.world 5 points 10 hours ago

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

[–] cupcakezealot@piefed.blahaj.zone 5 points 13 hours ago* (last edited 13 hours ago) (5 children)

for me i just needed a basic system so my family could share so I have it on my pc, then I registered a subdomain and pointed it to my existing ec2 server with apache using a proxy which points to my local ip and port then I opened the jellyfin port on my router

and I have certbot for my domain on ec2 :)

load more comments (5 replies)
[–] NuXCOM_90Percent@lemmy.zip 5 points 12 hours ago (2 children)

I don't use jellyfin but my general approach is either:

  1. Expose it over a VPN only. I usually use Tailscale for this so that I can expose individual machines but you do you
  2. Cloudflare tunnel that exposes a single port on a single internal machine to a subdomain I own

There are obviously ways to do this all on your own but... if you are asking this question you probably want to use one of those to roll it. Because you can leave yourself ridiculously vulnerable if you do it yourself.

load more comments (2 replies)
[–] This2ShallPass@lemmy.world 5 points 7 hours ago (1 children)

I don't host my media outside my local network but, if I did, I would use my go to method of SWAG with Authentik. This is what I have done for my other self-hosted items.

[–] Decipher0771@lemmy.ca 5 points 8 hours ago

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

load more comments
view more: next ›