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.
In THEORY they’re bad because the script could do malicious things and you shouldn’t blindly trust random people on the internet telling you what to execute.
In practice it’s mostly fearmongering because you’re likely trying to install a binary that could do malicious things anyways. “Mostly” because it is a bit less safe as one could MITM the script more easily or something, but not really by that much.
You shouldn’t run
curl | shscripts some random person sends you, but running an official script prom an official source is no more dangerous than running a .Deb file from that same source.