this post was submitted on 26 Jun 2025
344 points (98.6% liked)

Selfhosted

46671 readers
1662 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

you are viewing a single comment's thread
view the rest of the comments
[–] JRaccoon@discuss.tchncs.de 21 points 21 hours ago* (last edited 11 hours ago) (17 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 21 hours ago (2 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 8 points 17 hours ago (1 children)

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

[–] makeitwonderful@lemmy.sdf.org 4 points 15 hours ago

Your comment got me looking through the jellyfin github issues. Are the bugs listed for unauthenticated endpoints what you're referencing? It looks like the 7 open mention being able to view information about the jellyfin instance or view the media itself. But this is just what was commented as possible, there could be more possibilities especially if combined with other vulnerabilities.

Now realizing there are parts of Jellyfin that are known to be accessible without authentication, I'm thinking Fail2ban is going to do less but unless there are ways to do injection with the known bugs/a new 0day they will still need to brute force a password to be able to make changes. I'm curious if there is anything I'm overlooking.

load more comments (14 replies)