a container image
A running container is processes plus isolation; a container image is the frozen, shippable package those processes start from. Think of it as a complete, ready-to-run snapshot of a filesystem - the application, its libraries, its config, everything it needs except the kernel - bundled so that the exact same bytes run identically on your laptop, a colleague's machine, and a server in the cloud. The image is the 'build once, run anywhere' artifact; the container is what you get when you start an image.
The clever part is how images are built and stored: as a stack of layers. Each layer is a tar archive of filesystem changes - the first layer might be a minimal Linux userland, the next adds your language runtime, the next copies in your application. Layers are stacked using a union or overlay filesystem so they appear as one merged filesystem, and crucially they are content-addressed: each layer is named by a cryptographic hash of its contents. This gives two big wins. First, deduplication and caching - if ten images share the same base layer, it is stored and downloaded once. Second, immutability and integrity - the hash both names the layer and verifies it has not been tampered with. An accompanying manifest lists the layers and points to a config describing how to run the image (entrypoint, environment, and so on). When a container starts, a thin writable layer is added on top so the running container can make changes without altering the read-only image.
Why it matters: container images solved 'it works on my machine' by packaging the entire dependency tree, not just the app, into a reproducible, verifiable, cacheable unit - the foundation of modern software delivery and CI/CD. The honest clarifications: an image contains a userland filesystem but NOT a kernel - it borrows the host's kernel at runtime, which is why a Linux container needs a Linux kernel to run. And an image is a passive package of data; it does nothing until a runtime unpacks it and starts a container from it. The standard, vendor-neutral format for these images is defined by the OCI image specification.
A Dockerfile that starts 'FROM debian:12' then copies in a binary produces an image of two layers: the shared Debian base (cached and reused across many images) plus a tiny top layer with your binary. Pull it anywhere and the same hashes guarantee the same bytes.
Images are content-addressed layers - shared bases are stored once; the hash names and verifies each layer.
A container image ships a userland filesystem but NOT a kernel - it borrows the host kernel at runtime, so a Linux image needs a Linux host. The image is inert data; it does nothing until a runtime starts a container from it.