Selfhosted
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.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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!
view the rest of the comments
Just out of interest as someone who has recently set up a Jellyfin server - what's the main "value add" of using Plex compared to Jellyfin?
It seems to do everything I want, so I'm not sure why people would pay for Plex over the FOSS version.
Realistically the only advantage of Plex is being able to watch it over the internet without a VPN. Which means it makes it easier to get friends and family access to your server or to access it yourself from random smart tvs outside your house.
If you only watch at home or have a fire stick that you take with you to watch abroad or your friends/family members have one and can setup a VPN on it it's not needed.
For me, the killer app for Plex is Plexamp, the music client. It's superb, and AFAIK Jellyfin doesn't really have an equivalent (there are 3P options, but they're lacking).
For me (Android) I have used these:
And Symfonium can do many sources and is the moat powerful.
Finamp is neat but couldnt do casting to my soundbar via google cast
Symfonium with Jellyfin all the way!
I didn't try any of them because I additionally set up Navidrome to handle my music collection. But Fintunes, Jamfish and Finamp all look like great music players.
I have a navidrome server. Nothing, really nothing comes close to Plexamp and its features … sadly … but they all ain’t bad and got the basic stuff right
What features do you like? Not trying to convince you, I'm just curious.
Sonic Analysis and the amount of radios like style or mood radio for example.
I quote Plex here just because I’m lazy:
“Your Plex Media Server can perform a “sonic analysis” of your local music files to catalog detailed characteristics about the actual music itself. That data can then be used in a variety of ways, allowing you to see sonically similar artists/albums/tracks, play a Track Radio, or even suggest specific mixes for you, based on what you’ve already listened to.
It’s a powerful tool, allowing you to explore your music library in Plex like never before!”
It works quite impressive for my library.
Not the same person, but Plexamp uses plexs data / algorithms and had a way to create playlists and selected good songs. Hard to beat when not collecting data.
Are you accessing your media from outside of your network?
I have heard that you need to set up a VPN for Jellyfin to securely use your media library remotely. Plex handles all of that for me so that I don't need to deal with it.
I have a jellyfin server set up that you access like this:
https://my.servername/jellyfin
Username and password is all you need aside from that. Apps for most platforms or access in a web browser.
The sad reality is that Jellyfin’s authentication system is insecure, and there are “anyone can view your content without a valid login” exploits that are not going to be patched. The only way to stop someone would be to include a secondary username+password on your reverse proxy, to prevent attackers from even reaching your Jellyfin login page. Because if you can reach Jellyfin’s login page, you can exploit it without logging in. But that would break basically everything except for web browsers, because none of the various apps have support for more than Jellyfin’s authentication.
I mean, that's not great, but it's also not very concerning to me. Like the risk of someone doing that, and the potential harm resulting seems minimal to me.
The problem is that every single person uses the Trash Guide to set up their system. And the guide includes instructions on how to set up your file names.
You’re correct that in isolation the risk is minimal. But nearly every setup is using the trash guide’s suggested naming scheme, which makes guessing it dead simple.
I'm not familiar with the trash guide. I set mine up with swizzin community edition.
Edit: either way though, what is the real risk? Someone streams your media without your permission?
I am outraged that someone would commit piracy on my pirated content!
Honestly, if someone is going through all that trouble then they've earned it... and it saves me the effort of needing to create them an account.
You do know that there are security issues with that, right? For example, if someone can guess your media files they can watch them https://github.com/jellyfin/jellyfin/issues/5415
Some of those aren't great, but I don't consider any of them critical in terms of risk. I understand that others may feel differently.
Agree, I don't consider most of them a risk, but I do like to bring this to the attention of people who are exposing Jellyfin to the web so they can make an informed decision.
Thanks for this. There is a lot of apologia in the FOSS community, and Jellyfin fans are some of the worst. I have 100% seen comments along the lines of “lol I’ve had my Jellyfin port forwarded for years and I’ve been fine” as if it’s a valid security audit. The unfortunate fact is that Jellyfin is not secure, and the devs have openly stated that they have no intention of ever fixing these vulnerabilities. Because fixing them would require completely divesting from the Emby fork that the entire project was originally built on.
Jellyfin should never be available externally. And that means anything incapable of running a VPN will be incapable of connecting.
Yup, but all that being said I still run Jellyfin and have no intention of switching to Plex. And while I would like to see them fix these issues, I understand (in part) why they won't and I'm okay with my tail scale setup. Also the vast majority of issues are very minor, but the ability to watch any media without login is so major that I think it's worth bringing up every time someone mentions exposing Jellyfin online.
You should not expose a Jellyfin server to the open internet.
~~You should not expose a Jellyfin server to the open internet.~~
You should not expose a Jellyfin server to the open internet if you don't know what you're doing.
FTFY
Please tell me, oh wise one, how do you fix the glaring security issues that are the reason even Jellyfin Stans admit that you should use a VPN?
Port forward, filter ips, take reasonable precautions on the trust of networks.
It's not rocket science, as you mentioned in your other vitriol.
I think you don't understand the nature of the exploit.
Anybody who can see the Jellyfin login page can use the Jellyfin server's permissions to play media directly from your media library.
Port forwarding doesn't matter. Jellyfin hosts on port 80/443 which you have to allow for the service to function. Most clients are on dynamic IPs or CGNATs so unless you're going to manually change the IP filter for every single user every few days, IP filters are not a reasonable solution.
'Take reasonable precautions on the trust of networks' doesn't even make sense. Your Jellyfin server is either available to the Internet or not available to the Internet. If you choose not to trust the Internet (the actual mitigation) then you obtain access to your Jellyfin server through a VPN.
No, I understand the nature of the unencrypted transport. I understand that the credentials are exchanged unencrypted (although the passwd isnt in plaintext, even on jellyfin). I also understand what is on the trusted network, my kid's subnet.
The mitigations are the following:
Correct, that's the idea and that's why the IP is filtered. When my kid's IP changes, his PC posts a notice to me about it, and I change the the fw rule. This happens once a year on average.
Also correct, it is available to the internet, which from jellyfin's point of view is one single /32.
There is a body of suggested action to take in the interest of security that is repeated here and in other self-hosted spaces, and what you're saying is valid and sound advice. I want to acknowledge that I don't take your comment as wrong, it's very prudent for someone just getting into managing their own stuff.
However, security is my job, and I do take it seriously. And there are more ways than one to get it done.
I keep my data back ends on encrypted channels, backups on another, and I control very tightly what has access to everything else. The model I use is something like "zero trust", where I assume the clients even on my own network are malicious. In that context, extending my lan to a single remote lan on a single port isn't really much different than allowing an iot device I don't trust on my actual lan; it sees no other hosts but a gateway and whatever my acls allow it to.
So in the end, what can a device do at large on the internet to my jellyfin "network"? Nothing. What can a pwned device do on my kid's network with jellyfin? It can watch TV and movies, because the api calls from jellyfin clients to jellyfin front end are nondestructive.
I work in security as well.
If you only have a single user that accesses via a single static IP then it isn't much of an issue to manually maintain an IP whitelist.
Allowing access to multiple users across many different networks, means that you're going to have to deal with their IP changing frequently often multiple times per day. You'd have to be available full-time to update your whitelist if done manually.
If you're going to run software on those machines to check for their public IP and report it to you (or a script you run) in order to update your firewall's whitelist then you could just as easily (or, I'd argue, more easily) run a Tailscale client on their machine and only give them access to Jellyfin via Tailscale's ACL.
I just mean that you can't simply put Jellyfin behind a reverse proxy and alter some port forwarding rules to protect against the argument injection vulnerability, since it executes the ffmpeg command as the Jellyfin's service account so it would have access to any file that that account could access (which should be limited to the container, but some people run it bare metal still).
Using a VPN is just easier to deal with, to me, than trying to allow any access from Internet IPs. The firewall can simply block everything from the Internet that isn't VPN traffic. This is especially true if you control all of the devices that will be connecting to your network.
All of my traffic, even LAN traffic, is on one VPN or another. Everything is done 'locally' on the VPNs regardless of where the device is located.
I think we're arguing two sides of the same coin.
What? How is port forwarding adding anything to security? How does blocking IP ranges help prevent attacks on the unsecured backend?
I do not, and don't plan to. Probably wouldn't be that hard to set up though as someone familiar with nginx.
I guess Plex uses their own VPN under the hood then to make it more convenient?
Yep, and it generally has fewer sharp corners. Like last time I checked, in order to set up quick sync, you have to manually check each codec you want to offload to hardware. And if you select one that isn't supported by your hardware, you find out when you try to play that. So it means carefully cross-referencing with the Wikipedia page for your quick sync version. Plex just has an enable hardware transcoding check box and it figures it out for you.
There's also some features like smart playlists that I remember needing to set up plugins for whereas Plex supports it out of the box.
Of course ther are other things where jellyfin comes out ahead, like surround to stereo down mixing - I could never get the center channel (dialog) to be at a good volume when down mixed to stereo on my TV, but it just works and produces the correct volume in jellyfin.
But ultimately I think what causes all my users to prefer Plex is that the official app is polished and consistent across all platforms. The official jellyfin one looks like a programmer put it together with bootstrap components, and my favorite alternatives (like findroid) are in active development (I do donate on a reoccurring basis though in hopes that it reaches a level of polish matching Plex)
I don't think transcoding is that difficult if you've already set up your own server. Like, that's only a thing the admin would have to figure out and it's a quick lookup.
I do agree with the client UI issue tho, and would like to add that the lack of a per-user watchlist is a pretty baffling decision given that it's been widely requested for years and years and it would make it enormously more comfortable.
Wait, Jellyfin doesn't have per user watch lists? Forget making it externally available to other people, this is something I need within my own household. I haven't installed Jellyfin yet, but I had not anticipated this feature being absent. How do you work around it?
Roku app has a watchlist, but mostly I don't bother to get around it or put it in a collection which is clunky as shit
It's not, and I didn't say it was hard. Just that it's a sharp corner that jellyfin should fix if they want to make it as one click as Plex is. It's another part of the setup where you have to pay attention and get every check box right or it'll not work as intended. I found it annoying to have to look it up and I've been in software for 15 years. I don't doubt that any newb would find it frustrating. I remember seeing that it was planned to have hardware transcoding codec support auto detected but IDK if that has happened yet.
It's especially annoying because jellyfin doesn't just copy the support matrix into their docs, and the one on Wikipedia is by processor generation codename, so you have to look up your processor and get the codename, then reference the Wikipedia table and go down each codec and not make a mistake. Even though it's "not hard" I still go back to that section because I second guess that I checked everything right thinking that I've caused some issues with a mistake. It's additional cognitive load that isn't worth defending if you want jellyfin to be good.
HDR, hardware transcoding, remote access.
My Jellyfin has all of these things.
Mine too. And I appreciates that.
Plexamp is just far superior for music. It doesn’t even come close sadly … since I only use it for my music collection I simply prefer Plex … but only because I got lifetime a long time ago for 60 bucks or something …
Ease of use, and actual secure and usable external access.
Friends/family make an account and tell you their account name or email address, you invite them to your library and that’s it, they can watch/listen to your media on pretty much any device they have. No vpn needed.
Jellyfin is not meant to be exposed to the internet for remote viewing. It also doesn’t have a client on most devices people use to watch tv/movies.
Huge disagree on the last part. Jellyfin has a bunch of Android, Roku, Google tv and PC clients. I struggle to think of a device me or my friends use that has a Plex client but not a Jellyfin one.
I've got a bunch of friends accessing my jellyfin server. It has clients for most devices now.
I didn’t say it’s not possible, I said it’s not secure and/or easy.
It's definitely easy, and the secure part is debatable.
Doing it insecurely is easy.
The secure part isn’t debatable. Even the devs will tell you it’s not secure.
Secure isn't a binary. Depending on your threat model, using Plex is impossible to use securely!
I was Osama bin Laden and I can confirm that this is true.