"It works on my machine so we ship my machine" certainly works but it's not the only solution and not even always the best one. You can develop software for Ubu

"It works on my machine so we ship my machine" certainly works but it's not the only solution and not even always the best one. You can develop software for Ubuntu servers just fine when running Ubuntu desktop as long as you stick to the same major version. Or, if you deploy on Windows, you don't even need containers to validate basic system functionality. The whole glibc mess is one of the biggest selling points of Windows Server to me, and I don't like Windows Server at all. Containers don't even give you guarantees about your production environment. I've seen more than a few cases where a local deployment failed in production because of a missing instruction set on the production machine. Containers also don't solve your firewall's nftables rules being different from prod's, and they don't solve for eBPF programs running on your system either. If you go down to troubleshooting at the glibc level, containers aren't enough anymore to guarantee the things you want to guarantee, because you share things like a kernel; you can maybe get away with a VM, assuming your dev machine has a superset of CPU features to cover the CPU features your production machines have, unless you limit yourself to a very restrictive subset if you don't know what CPUs your code will run on. And god forbid you need access to special hardware, your only remaining option then is to mess with PCI forwarding or to take a production server and run your tests on that. Usually, portable software doesn't really need that kind of verification. What works for me in practice is "statically compile for the oldest glibc you want to support and hope for the best" or "develop for the distro you're running on your desktop and don't run anything newer than the oldest distro you still need to support". Alternatively, you can just switch to a language like C# or Java or Python or PHP or whatever other language deals with the glibc mess for you. It's not always an option, but avoiding native code when you can sure makes testing and deployment a whole lot easier.