An image runs unchanged after its hosts' container stack was replaced — which two published specifications make that possible?

"Build once, run anywhere" is not a property of images; it is the consequence of two documents that several independent implementations agreed to honour. Knowing which document covers what is how you predict, in advance, what will and will not survive a change of container stack underneath a workload. ## The image specification: what an artifact *is* The first agreement fixes the artifact itself, so that anything which can produce one can be consumed by anything that can run one. It covers: - **Layers**, as an ordered set of filesystem changesets, each identified by a **digest** computed from its own bytes. Content addressing is what makes a layer verifiable and shareable rather than merely named. - **A manifest** listing those layers by digest together with the image's configuration, so an image has one exact identity independent of any tag pointing at it. - **A configuration object** recording what should happen by default when the image runs: the command, the environment, the working directory, the user, and the processor architecture and operating-system family the image was built for. Because this is written down, the tool that built the image, the registry that stored it and the manager that pulled it need nothing in common but the format. ## The runtime specification: what a runtime is *handed* The second agreement fixes the other seam — between the component that prepares a container and the component that starts one. It covers: - **The bundle**: an unpacked root filesystem directory plus a configuration document describing the process to run, the mounts, the per-resource views, the ceilings, the user and the privilege set. - **The lifecycle operations** a runtime must implement on that bundle — create it, start it, query its state, signal it, delete it — so any manager can drive any conforming runtime. This is why a low-level runtime can be replaced on a host without the layer above being rewritten, and why a manager written by one group can drive a runtime written by another. ## What each one does and does not fix | | Image specification | Runtime specification | |---|---|---| | Fixes | What an image is, as bytes and metadata | What a runtime is handed, and what it must do | | Read by | Builders, registries, container managers | Container managers and low-level runtimes | | Identity it defines | A digest naming exact content | A bundle naming one intended container | | Does not cover | How a container is fenced or started | How images are stored or distributed | | Also does not cover | Networking, storage attachment, scheduling | Networking, storage attachment, scheduling | ## What portability still costs you The honest limits are worth saying out loud, because they are where "it runs anywhere" fails in practice: 1. **Architecture.** A single-architecture image runs on that architecture. Running elsewhere requires an image index carrying a build per architecture, or emulation with its performance cost. 2. **Operating-system family.** These containers share the host's kernel. An image built for one kernel family does not run on another, however conforming everything else is. 3. **Everything above the runtime.** How a workload gets a network address, how durable storage is attached, how replicas are placed — none of that is fixed by either specification. Platforms define those with their own interfaces, and that is exactly where moving between stacks stops being free. 4. **What the workload assumes.** An image that expects a host path, a device or a particular kernel tunable is portable as bytes and unportable in practice. ## Why this is the interesting answer in an interview The weak answer is "containers are portable because they bundle their dependencies" — true but shallow, and it does not explain why replacing a host's entire container stack leaves the artifact untouched. The strong answer names the two seams. Dependencies being bundled is what makes an image self-contained; the two specifications are what make a *different vendor's* manager and runtime able to consume that image without anyone renegotiating anything. It also predicts the failure modes correctly: a change of stack is usually uneventful, a change of architecture or kernel family is not, and a change of orchestration platform is a different project entirely, because that layer was never covered.