Pros

I get to own my system. I get to do what I want, if something is not to my liking there’s likely a way to make it work like how I want.

Cons

I have to own my system. If something breaks I have to fix it, if something doesn’t work I need to figure it out.

and what if any do you miss from windows?

Expect things to work. Linux is a minority of users, any manufacturer or dev HAS to make their products work for Windows, so much so that Windows users don’t even consider the possibility that something is not made for Windows.

Plex server doesn’t need to be “portable”

Strongly disagree, I’ve switched my media server several times in the past decade for a multitude of reasons, having things in docker has allowed me to do this seamlessly.

Also you’re ignoring all of the other benefits of running in docker, from isolation to automation.

and running it in docker definitely doesn’t make it easier.

Plex is the only self-hosted service that is purposefully trying to block you from being ran in docker. All other things are just much easier to run in docker, that’s part of the appeal, reproducible builds eliminate the “it works on my machine” errors.

There absolutely are programs that make sense to run in docker, but Plex server isn’t one of them.

Why do you think it doesn’t make sense? Does Jellyfin make sense to you to run in docker? Why are they different?

Also, Plex only supports Ubuntu and CentOS, none of which I run on my server, so the only OFFICIAL way to run Plex is Docker.

There’s zero need to run anything in docker, it just makes things easier and portable.

What Plex does is closer to having an embedded tailscale client, you can access Jellyfin remotely with tailscale for free, but OP specifically asked for no VPN.

That being said, I’m not opposed to Plex charging for that service, even a tailscale like server costs something to maintain. My gripe with Plex is that it purposefully shoots itself in the foot to force you into their paid service, i.e. it actively tries to isolate itself so you can’t access it remotely, which means that it can’t run inside a docker container unless you give it network host access, otherwise it only considers other docker containers locals and doesn’t let you watch your own content from another machine in the same network.

Because clients would probably fail if there’s an authentication layer on front that they’re not expecting.

https://github.com/jellyfin/jellyfin/issues/5415 nothing too serious, but here you go

IIRC Envy clients can connect to Jellyfin, it’s part of the reason why they don’t change the API despite security issues.

Except most people have almost the same structure because of media organizers like radarr/sonarr. At the very least they should hide that behind a setting to not require auth (since the header should be there for most clients) so only people running an old client would be affected. They could also add an extra salt to that hash or something similar.

I agree, it’s not critical, but it shouldn’t be hand waved either. And like I said, security is relative, I would argue for most people this is fine, but I still think this should be taken more seriously.

Secure is relative, you should be aware that jellyfin itself has security issues https://github.com/jellyfin/jellyfin/issues/5415 most of which are harmless, but at least one is fairly serious and allows people to watch your media without authentication, and adding an extra layer of authentication on the proxy would likely cause issues with clients.

That being said, if you’re okay with those security issues what I would do is have a cheap VPS, connect both machines to tailscale, and have something like Caddy on the VPS to do the forwarding.

So? Jellyfin only needs 8096, the other two are https and lan discovery, you can also add 1900 for DNLA. On the other hand Plex has 8 additional configurable ports for other stuff, but that’s besides the point because it requires network_mode: host otherwise it pretends it can’t be seen.

1. Copy the compose.yaml from https://docs.linuxserver.io/images/docker-jellyfin/#user-group-identifiers and adjust, e.g.:

services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Madrid
    volumes:
      - ./config:/config
      - ./media:/media
    ports:
      - 8096:8096
      - 8920:8920
      - 7359:7359/udp
    restart: unless-stopped

2. Run docker compose up -d

3. Navigate to http://<IP>:8096

4. Follow the wizard to create a user and libraries.

5. Profit

Steps for Plex:

1. Copy the compose.yaml from https://docs.linuxserver.io/images/docker-plex/?h=plex#umask-for-running-applications and adjust, e.g:

---
services:
  plex:
    image: lscr.io/linuxserver/plex:latest
    container_name: plex
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - VERSION=docker
    volumes:
      - ./config:/config
      - ./media:/media
    ports:
      - 32400:32400
    restart: unless-stopped

2. Run docker compose up -d

3. Navigate to http://<IP>:32400

4. Create an account with Plex, give them your email and create a password with the specific requirements they impose. Agree with their use policy and confirm the pop-ups about ads and such.

5. You can now watch Plex media. Clicking your media will only have a link to https://www.plex.tv/media-server-downloads/

6. Look everywhere to figure out where to add your local media and give up.

7. Look in Google and no one has this issue.

8. Spend a few hours trying and give up.

BTW, the issue there that took me months to figure out is that while Plex documentation says that you only need to expose that port, it only works in network host mode, so unless you give it full control of your network it just refuses to work.

I have set up both. Honestly Jellyfin was MUCH more easy to setup because Plex requires a very specific way to setup the network otherwise it craps its pants and refuses to work on LAN.

But after figuring out those pain points, both are set and forget. The main differences are privacy concerns vs wide access outside of LAN and on more devices.

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.

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.

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.

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

Maintenance is a breeze, setup is a bitch. I switched from Arch a short while back, getting the initial thing up to the same level as what I had before took me a few weeks, and a few months to get to the current iteration. But then to setup my other system to the same level was a couple minutes and I had the exact same system on both machines.

Honestly I can’t see myself going back, the assurances when I do a change/update that I’ll be able to rollback if anything goes wrong it’s just too valuable to me. If you’re willing to pay the price of the initial setup it’s absolutely worth it, but that price is high and the learning curve is steep, so it’s not for everyone. If you’re interested I strongly recommend you check out https://youtube.com/@vimjoyer and maybe setup a VM or an old machine and get your feet wet and learn the basics.

When I first started using Linux I used Kate, I know, I know, not command line, but I didn’t needed a command line editor for my own computer. Eventually I started using nano for quick edits and that became my default CLI editor for a while. I don’t remember what I used as an IDE back then, but maybe it was Eclipse, although I think it was mostly just Kate.

Eventually I decided to learn either VI or Emacs, and a friend who used Emacs pushed me to that side. I ended up switching everything to emacs, CLI, IDE, I even learnt org-mode and had tables and presentations in it.

Eventually my pinky started to hurt too much, so I switched to Pycharm for python, and kept emacs for C++, text edits and org-mode. I ended up slowly switching emacs everywhere and reverted to nano.

Some years back I decided to properly learn vim. I have been using nvim for a few years, and while it’s not the everything tool that emacs was for me, it’s still pretty darn useful. I also haven’t become a movement ninja and oftentimes I go wwwwww to get where I want to be. But still, there are some very nice shortcuts that I use a lot like Change Inside/Around or Delete X lines. Macros are cool, and sometimes feel magical, but other times they don’t work like I expected and I can’t figure out why. I don’t see myself changing to something else, the ubiquity of vim shortcuts in other programs makes it very convenient when I have to use something else.

Everyone who said proxmox didn’t read your post to the end. Proxmox is great for people who want a machine to just self-host things and don’t care about how things work. You don’t seem like that sort of person, and you also mentioned Moonlight which will be annoying to do on proxmox as it’s not intended for that use case.

Every system capable of being used as a Moonlight client can run self-hosted services, but the other way around is not true. So it’s better to start with the Moonlight part.

So, with that in mind I imagine you want this machine to be plugged to a TV in the living room or something similar, so it needs to have a GUI, and the GUI probably needs to be something you can navigate with a controller (although the new Steam controller probably increases that definition dramatically).

You will already have one system with a GUI, so it’s easier to use the same thing. Really, don’t overthink this, if it’s good for general use it’s good for self-hosting, and you don’t want to have to learn how to solve the same problem in multiple ways because of different distros. In the future considering different distros makes sense, but when you’re just getting started nailing the basics is easier with consistency across systems. Think about it this way, if you were learning how to write mixing cursive and print at the same time would be harder than choosing one and then learning the other.

But why proxmox is great? It’s because it makes it easy and gives you a GUI to add services. How hard is it to do the same on Linux using docker? Ssh into the server, edit a small text file and run a single command, all of which should be easy for you since you’ve probably done this in the past, but for most people that is very hard and that is where proxmox shines.

Don’t believe me? You said Jellyfin, this is the whole Jellyfin file with comments:

# Services that this file creates
services:
  # Name of the service, it can be whatever you want
  jellyfin:
    # Image this server runs, this is what tells what the service is
    image: lscr.io/linuxserver/jellyfin:latest
    # Volumes to mount. In the format <local>:<inside the image>
    # So this will mount the ./jellyfin folder inside /config for the image
    # some services require specific folders inside of them, e.g. /config to store jellyfin's configs, otherwise the folder would get lost with every restart of the service 
    volumes:
      - ./jellyfin:/config
    # Rarely needed, but this gives hardware access to the image. Specifically access to the /dev/dri device
    # Jellyfin specifically benefits from this for transcoding 
    devices:
      - /dev/dri:/dev/dri
    # This shows what ports you want to expose, again in the format <local>:<inside the image>
    # So if you want Jellyfin on port 8080 on your machine you don't need to change settings, just do 8080:8096
    ports:
      - 8096:8096
      - 8920:8920
      - 7359:7359/udp
    # This tells docker to restart the service if it crashes, unless you've stopped it
    restart: unless-stopped

That’s it, and this is one of the most complicated ones out there, here’s a simple one:

services:
  radarr:
      image: lscr.io/linuxserver/radarr:latest
      volumes:
        - ./radarr:/config

Of course there’s more to those files, and lots of extra configurations to be used, but the core is very simple and the rest is just needed for special cases.

I don’t get how that output showcases anything, unless he had run that against a known instance of forgejo so the owners of that instance could confirm that he actually executed code. But he’s only showing a text file, that’s like saying look I hacked super_secure_self_hosted_service:

python hack_it.py localhost:3000

Hacked!

For all we know chain_alpha.py is just a bunch of prints.

Also, even if it is real (which I don’t really doubt, but I have seen no proof) holding the information instead of properly disclosing it is just childish. It’s not a carrot methodology, it’s a stick one, and one without a carrot. This is the sort of thing you do to big companies with no morals, doing it to a small open source project is just wrong, they don’t have the manpower or money to redo the investigation you already did. Release a CVE, talk to the devs, and/or push a PR, but saying “I found a vulnerability but I won’t tell you about it” is just dumb.