Infrastructure · We run it ourselves
Process isolation with the filesystem and dependencies pinned, so a program runs the same on a laptop and on a server.
The interesting use of a container is not that it deploys tidily. It is that untrusted code can run inside one without reaching the machine around it.
01
It closes the gap between environments. 'It worked locally' stops being a diagnosis when the image is the same object in both places.
02
Isolation is the real reason we reach for it: separate images for a plain execution sandbox and for one with a browser, because code that can drive a browser can reach the network and needs a tighter box than code that cannot.
03
Compose files split by environment rather than one file with conditionals, so the difference between development and production is readable rather than inferred.
An entry that cannot point at something you can open, run or read does not compile. That is a property of the type, not a promise in a paragraph.
Invariant
A container is not a security boundary on its own — it shares a kernel, and an escape is a kernel bug away. Where the threat model is genuinely hostile code rather than untrusted input, the isolation has to go a level down to a virtual machine, and we say so rather than selling the container as more than it is.