When deploying to a VM you don't need to build a new image. If setup right you can just copy the updated files over and then trigger a reload or restart of the service. Different team's services are in different directories and don't conflict.

▲

twunde 3 days ago | parent | next [-]

This is much more viable than it was in the past with the advent and adoption of nvm, pyenv etc but the limiting factor becomes system dependencies. The typical example from yesteryear was upgrading openssl but inevitably you'll find that some dependency auto updates a system dependency silently or requires a newer version that requires upgrading the OS.

▲

DiabloD3 3 days ago | parent [-]

So why are you using a Linux that forces that on you?

Sane people use Debian, Debian packages are compatible with the Debian release they are from. I do not have to worry about accidentally installing an incompatible deb; even if I try to, apt won't allow me to install a package whose deps cannot be satisfied because they're too new (and thus, not in my release's package repo).

I know other distros have problems with release management, but this is why I've used Debian for the past 20 years and will continue to use Debian

▲

curt15 2 days ago | parent [-]

>Debian packages are compatible with the Debian release they are from.

That won't save you if an application requires newer tooling or libraries than whatever is in Debian stable. Once that happens the application needs to bundle its dependencies. But that is precisely why people use containers.

	▲	DiabloD3 2 days ago \| parent [-]
		You say container, but if you're at AWS, for example, and you're using any API of theirs, either the original deprecated EC2 API, or the Docker API, or the Kubernetes API... its all a real honest to god VM underneath, provided by Firecracker. In other words, the technology I have used non-stop since it was mainlined in 2008 is the technology all of you use today. I can deploy a VM, you can deploy a VM, the difference is the API we use to do it, but they're all VMs. And yes, my VMs are not required to be Debian Stable, and I can deploy any version as needed. That is why we have VMs, so we do not need to dedicate entire machines to a single application with unusual dependencies. Something big companies like Amazon and Google and Microsoft realized is the true wisdom that sysadmins like me have always known: even the damned kernel is a dep that should be tracked, and sometimes this does matter, and the only way you can deploy kernels on a per-application basis is with VMs. Something container jockeys will never understand: containers that are offered through the OCI facility in the kernel has multiple discrete userlands, but one kernel. You do not have a hypervisor with its own kernel. Docker, real namebrand Docker, is an OCI consumer. Using something that implements a compatible API is not Docker, but merely a compatibility shim.

▲

jiggawatts 3 days ago | parent | prev [-]

Let's say you have image "ProdWebAppFoo-2025-08-01" and you used this to deploy three VMs in a scale set or whatever.

Then a developer deploys their "loose files" on top a couple of times, so now you have the image plus god-knows-what.

The VM scale set scales out.

What version of the app is running on which instance?

Answer: Mixed versions.

▲

charcircuit 3 days ago | parent [-]

>so now you have the image plus god-knows-what.

Rsync is smart enought to figure out how to get parity.

>What version of the app is running on which instance?

There is always going to be a time during a rollout where there are mixed versions running.

	▲	jiggawatts 3 days ago \| parent [-]
		Sure, rolling forward you expect mixed versions. Nobody expects a month old version to occasionally turn up and then mysteriously disappear when some rsync job catches up.