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. A scraper and a browser-driving bridge pull in a surface a web service has no use for, and giving each its own image keeps a dependency added for one of them out of the rest — the alternative is one fat base that every service inherits and nobody dares to trim.
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.