Other distros have been competing forever. SteamOS is built on top of Arch, which updates multiple times per day. Valve pushes a lot of updates tied to the Steam experience, some of them are also shared with normal Linux desktops, so that makes it somewhat of a moot argument. I run normal Linux (Fedora Workstation) and play games with Steam, and they run the same as my Deck, even day 1 releases.

Like, I get the appeal of a Valve-blessed Linux flavor, but as far as their stack goes, the Linux side of SteamOS is somewhat conservative (not many updates) and limited (due to read-only OS images) compared to normal Linux distros and the gaming side also gets pushed to all Linux distros. As a Steam Deck owner, I personally think Bazzite is more interesting for a real world gaming desktop usage than SteamOS, where you can’t even print documents because it lacks the required stack!

To show how conservative it is, I call recall a few examples:

• The desktop side, which runs the KDE Plasma desktop, was stuck on version 5.27 for ages and just got recently updated to 6.2. Meanwhile, Arch and Fedora/Bazzite are rocking Plasma 6.3 and should receive Plasma 6.4 in a month or so, pretty much day one.
• The Linux kernel (although patched and tweaked) in SteamOS was still on 6.5 until a few days ago. It was bumped to 6.11 with SteamOS 3.7. Meanwhile, Arch and Fedora have been on 6.14 for weeks now, with new hardware support, performance fixes for existing hardware and some new features.

Not really, in theory all you need is that environment flag to set the socket up. I would guess it would work with NPM if it respects it. I ended up with a custom built image originally to fix nameserver detection with named networks in Podman, and then expanded it with some sane defaults.

I do enjoy administering my containers through systemd but it’s indeed an inconvenience if you want a more straightforward solution. Arguably using rootless Podman is already a major inconvenience, since you always hit some quirk or need to patch something up because images assume rootful Docker, so I don’t mind going an extra mile to have everything set up as quadlets. I do consider using LXC every now and then for certain things just to make it easier in the long run, as matter of fact, I’m still pondering if I shouldn’t just create an unprivileged LXC container for the reverse proxy instead of dealing with this (although it has been working mostly great so far).

I’ve solved this on my side with socket activation, which besides giving out the real IP, also has native network performance since it fully skips slirp4netns. You could even set nginx’s network to none, but since I also use named networks for internal container DNS, so I kept network set.

I’ve built my own Nginx image and I’m using Quadlets instead of Compose, so my config is as easy as it gets, the socket file is something like this:

[Unit]
Description=container-nginx

[Socket]
BindIPv6Only=both
ListenStream=443

[Install]
WantedBy=sockets.target

And the quadlet file for NGINX goes like this for me:

[Unit]
Description=Web serving, reverse proxying, caching, load balancing, media streaming, and more.
Requires=nginx.socket
After=nginx.socket

[Container]
Image=localhost/nginx:latest
AutoUpdate=local
Volume=/data/containers/nginx/conf.d:/etc/nginx/conf.d:Z
Volume=/data/containers/nginx/certs:/certs:Z
Network=services.network
# Socket for systemd
Environment="NGINX=3;"

[Service]
Restart=always

If you check the socket activation link, there are a few other examples, but IMO that’s the easiest setup out of the 5 examples. You could move NGINX out of the compose setup for easiness or adapt examples 3 to 6 (which invoke podman manually). That said, I wanted to use Caddy for easier certificate management, but it doesn’t support socket activation, so this setup kinda hardlocked me to NGINX.