I expose jellyfin to the internet, and some precautions I have taken that I don’t see mentioned in these answers are: 1) run jellyfin as a rootless container, and 2) use read-only storage where ever possible. If you have other tools managing things like subtitles and metadata files before jellyfin there’s no reason for jellyfin to have write access to the media it hosts. While this doesn’t directly address the documented security flaws with jellyfin, you may as well treat it like a diseased plague rat if you’re going to expose it. To me, that means worst case scenario is the thing is breached and the only thing for an attacker to do is exfiltrate things limited to jellyfin.
I do this on the minimal Debian release which is essentially coming from the same place, you’re left to get things configured with a root user or maybe a privileged user after install. There’s a few things to tweak for rootless podman and it will vary based on the distro. The gist for me and Debian is:
net.ipv4.ip_unprivileged_port_start=<start of lower range of ports rootless containers will use>podman run --name jenkins --user jenkins --userns=keep-id:uid=1000,gid=1000 ...Again, that’s just Debian, never tried MicroOS, but if MicroOS isn’t doing anything special to accommodate rootless podman I imagine these steps are somewhat applicable. One issue I ran into was with an older version of Podman, whatever comes with Ubuntu 22: That version of podman requires you to set the namespace mappings; Debian 12’s version does not and the --userns=keep… flag just works.