Echoing what others have said, Immich hasn’t had breaking changes in a while. That being said it’s one of the services I keep it on a pinned version and read release notes before updating.

Yeah, even when jumping minor versions they tend to spend a few days/weeks pushing patches, I’ll wait a bit before updating.

Glad you solved it yourself, but I’m still struggling to understand what happened, how did you have them all in a single folder if the filename for docker compose has to be one of a few predetermined things? I mean, you could have them all in a single file, which makes some things easier, but then you wouldn’t have been able to move them into individual folders. Would you mind explaining what happened there so that if someone else in the future has the same issue they might find the solution here?

Also, note that even if someone had given you an example of a working docker file you would still have to configure the service. For future reference, this site is great and has working examples of docker compose files for a lot of services, e.g. https://hub.docker.com/r/linuxserver/radarr

Finally, welcome to the club, sorry you had a bad experience the first time, it’s hard for us to know what’s obvious and what isn’t: https://xkcd.com/2501/

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

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.

That article has lots of issues:

17% of the most popular Rust packages contain code that virtually nobody knows what it does

That’s not true at all, the article where he got that information from says:

Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.

He then lists some ways packages can be maliciously compromised:

1. Steal credentials and impersonate a dev
2. Misleading package names
3. Malicious macros (this one is interesting, had never considered it before)
4. Malicious build script

And his solutions are:

1. Bigger std library (solves none of the above)
2. Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn’t match the source and is detectable)
3. Decentralized packages (which worsens every security concern)
4. Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)

Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.