That's... actually clever. The flatpak runtime is still chunky but it's shared. And you avoid the SteamCMD-in-Docker permission dance entirely.
Downside: now you have flatpak. Pick your poison.
I run my CS2 server on an AWS Lightsail instance in Tokyo. 4GB image, 40GB disk plan. The real cost is outbound data transfer, not storage. Docker's convenience is worth the bloat when you're billing by the hour and don't want to spend Saturday fixing dependencies.
OVHcloud is cheaper for storage-heavy but their Tokyo region doesn't exist. Had to go AWS.
Correct. OVHcloud's Asia presence is Singapore and Sydney only. Their Vint Hill and Hillsboro US West locations have decent latency to Tokyo though, if you don't mind the extra hop.
AWS Lightsail's pricing is fine until you need more than two outbound TB. Then you learn why they call it "lightsail" and not "heavyfreight."
Member
Mumbai to Singapore latency is 65ms stable. I use OVHcloud Singapore for a small CS1.6 community. The 4GB SteamCMD image fits fine on their 80GB VPS plan. Workshop downloads go to a mounted block storage volume, not the boot disk.
Block storage is the real trick. Pay for 200GB attached storage, keep your boot image small. I used https://www.ovhcloud.com/en/vps/ for the VPS plan.
OVHcloud's additional volumes max out at fairly low IOPS though. Fine for game files, terrible if your server does heavy logging or map downloads. I've seen Valheim world saves stutter on their standard block storage during peak.
Also CS1.6, respect. Some of us never left.
This thread went from "my container is too fat" to "run flatpak on the host" to "CS1.6 forever" in twenty posts. I love forums.
Has anyone actually benchmarked startup time between fat image + thin volume vs thin image + fat volume? My gut says the latter wins but I never measured.
I did, informally. Thin image + fat volume wins by 30-60 seconds on first start because you're not extracting layers. But if Docker has the image cached, fat image is faster because volume mounts need chown/permission fixes that SteamCMD loves to demand.
The real benchmark is "how fast can I restore after docker system prune destroys my wedding photos." Infinity, in my case.
Following. My Terraria server is at 9GB and growing. Tried Alpine, glibc compatibility was a nightmare. Might try the flatpak decoupling idea.
Gcompat and ld-musl-x86_64.so.1 will get you most of the way but SteamCMD specifically checks for glibc version and bails. Valve's fault, not Alpine's.
Thread summary for anyone arriving late:
- Fat images are bad, SteamCMD makes them inevitable
- Bind mounts help but pathing is inconsistent
- OVHcloud Singapore, Contabo Singapore, AWS Lightsail Tokyo all work, pick by your latency and transfer needs
- Flatpak host + thin container is the most promising weird idea
- LinuxGSM exists, Pterodactyl exists, neither solves the bloat
- I lost wedding photos to docker system prune
Someone update the wiki.
