A single VM is indeed the most pragmatic setup that most apps really need. However I still prefer to have at least two for little redundancy and peace of mind. It’s just less stressful to do any upgrades or changes knowing there is another replica in case of a failure.
And I’m building and happily using Uncloud (https://github.com/psviderski/uncloud) for this (inspired by Kamal). It makes multi-machine setups as simple as a single VM. Creates a zero-config WireGuard overlay network and uses the standard Docker Compose spec to deploy to multiple VMs. There is no orchestrator or control plane complexity. Start with one VM, then add another when needed, can even mix cloud VMs and on-prem.
Wow, that's very similar to my set up. Their diagram even shows off this staging/production pattern which is nearly identical to my own projects!
I use ansible to set up my hosts, and from there each app just brings it's own caddy & compose file. A bit of scripting and SOPS wraps the lint / build / deploy steps. Compared to my past life which was all k8s infra projects in helm... it is SO NICE to use these lightweight files instead.
If you have an app and you want to run a single app yeah silly to look for K8s.
If you have a beefy server or two you want to utilize fully and put as many apps on it without clashing dependencies you want to use K8s or docker or other containers. Where K8s enables you to go further.
I think automatic scaling is useful to utilize server fully - apps that don't need resources automatically scale down, apps that need resources can auto scale up.
I bet you can do it in some other way but that's built in feature of k8s.
There is very little reason to need auto-scaling when you run on pre-purchased VMs/servers. You've paid for all the compute so you can run as many replicas as it can fit and you need to handle the projected amount of traffic.
There are no benefits to scaling down in this case. And scaling up won't help handle more load if you've already allocated all resources to running replicas. You need more machines, not more replicas on the existing machine(s).
It all comes down to simple, boring capacity planning and static resource allocation. Fewer moving parts results in fewer failure modes, hence more robust infra and less ops and maintenance work.
Your response seems like you are talking about a single product / single application.
You have apps A, B and C (you have N teams and N products) each developed by different teams - that you want to run on that one server, when app A doesn't have much traffic apps B and C can use more of compute. Then having deployment management aligned for all teams/products.
Yes but at small scale. Myself and a handful of others from our Discord run it in production. The core build/push/deploy workflows are stable and most of the heavy lifting at runtime is done by battle-tested projects: Docker, Caddy, WireGuard, Corrosion from Fly.io.
Radboud University recently announced they're rolling it out for managing containers across the faculty which is the most "serious install" I know about, but there could be other: https://cncz.science.ru.nl/en/news/2026-04-15_uncloud/
TBF, the documentation says you can download and review the script, then run it. Or use other methods like a homebrew or (unofficial) Debian package, or you can just install the binary where you want it, which is all the install.sh script (107 lines, 407 words) does.
And I’m building and happily using Uncloud (https://github.com/psviderski/uncloud) for this (inspired by Kamal). It makes multi-machine setups as simple as a single VM. Creates a zero-config WireGuard overlay network and uses the standard Docker Compose spec to deploy to multiple VMs. There is no orchestrator or control plane complexity. Start with one VM, then add another when needed, can even mix cloud VMs and on-prem.