By now you know a container is a sealed box that carries your app and everything it needs to run. But where does that box come from? Nobody builds a running container by hand each time. Instead, you build a container image once — a frozen, read-only blueprint — and then stamp out as many identical containers from it as you like. The image is the thing you build, store, and share; the container is the live copy that runs.
This one distinction trips up a lot of newcomers, and getting it straight makes the rest of the container world fall into place. So let’s pull an image apart and see exactly what it is, what’s inside it, and why it’s the unit everyone passes around.
What a container image actually is
A container image is a read-only template that contains everything needed to create a container: your application’s files, the libraries it depends on, a minimal slice of an operating system, and a small set of instructions describing how the container should start. It’s a single, self-contained artifact — a package you can copy, store, and hand to anyone, knowing it carries the full recipe for running your app.
The cleanest way to hold it in your head is the relationship between a class and an object, or a recipe and a cooked meal:
- The image is the blueprint. It never changes once built. It’s frozen, read-only, and identical for everyone who has a copy.
- A container is a running instance created from that image. You can start ten containers from the same image, and each one is its own live process — but they all began from the same frozen template.
IMAGE (read-only template)
┌──────────────────────────┐
│ app + libraries + OS │
│ + startup instructions │
└────────────┬─────────────┘
│ "run it"
┌───────────┼───────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│container│ │container│ │container│ ← live, writable copies
└─────────┘ └─────────┘ └─────────┘So when someone says “ship the image,” they mean: hand over that frozen blueprint, and anyone, anywhere, can spin up a running copy that behaves exactly the same. The image is portable; the containers are disposable. You can throw a container away and create a fresh one from the image in a second, because the image still holds the full truth of what your app needs.
Image is the noun, container is the verb
A useful shorthand: the image is what you have (a file you build and store), and the container is what you do with it (start it, and it runs). You don’t edit a running container to make changes permanent — you change the recipe and build a new image. This is why containers are often called immutable infrastructure: the source of truth is always the image, never a container you’ve poked at by hand.
What’s actually inside an image
Crack an image open and it isn’t one solid blob. It’s built up from a stack of layers, plus a little bit of metadata that ties everything together. Understanding layers is the single most useful thing you can learn about images, because it explains why they build fast, ship fast, and don’t waste disk space.
Here’s the rough anatomy:
- A base layer — usually a stripped-down operating system filesystem (just enough Linux to run programs, not a full desktop). This is where most images start.
- One or more layers on top — each one a set of changes: install a language runtime here, copy your app’s files there, add a configuration step. Every meaningful step in building the image adds a new layer.
- Metadata — a small manifest describing which command to run when the container starts, which network port the app listens on, environment variables, and so on. This is the “startup instructions” part of the recipe.
IMAGE = a stack of read-only layers
┌──────────────────────────────┐
│ layer 4: your app's code │ ← top, most specific
├──────────────────────────────┤
│ layer 3: app dependencies │
├──────────────────────────────┤
│ layer 2: language runtime │
├──────────────────────────────┤
│ layer 1: base OS filesystem │ ← bottom, most general
└──────────────────────────────┘
+ metadata (start command, ports, env)Each layer is read-only and represents a frozen step. Stack them up and the result is a complete filesystem your app sees as a normal directory tree.
Why layers are clever, not just an implementation detail
Layers aren’t just how images happen to be stored — they’re a genuinely smart design with real payoffs:
- Caching makes rebuilds fast. When you rebuild an image after changing one line of your code, only the layer that actually changed (and the layers above it) need rebuilding. The base OS layer and the dependency layer haven’t changed, so they’re reused instantly from cache. A rebuild that would otherwise take minutes can finish in seconds.
- Sharing saves space and bandwidth. Layers are content-addressed, which means two images that share the same base layer literally share the same stored copy of it. If you have five images all built on the same minimal Linux base, that base is stored once, not five times. The same applies when downloading: if you already have a layer locally, it isn’t fetched again.
- It encourages a sensible order. Because changed layers invalidate everything above them, you learn to put the things that rarely change (the base, the dependencies) at the bottom, and the thing that changes constantly (your app code) at the top. Get the order right and your day-to-day rebuilds touch only the cheap top layer.
This layered, shared design is a big part of why containers feel so light to move around, a point that connects directly to why teams reach for containers in the first place.
How an image gets built
You don’t assemble layers by hand. You write a short text recipe — a build file — that lists the steps, and a build tool reads it top to bottom, executing each instruction and freezing the result as a new layer. The exact syntax varies between tools, but the shape is universal and looks something like this:
# start from a small base image
FROM minimal-os:latest
# install the language runtime
RUN install-runtime
# copy your application's files into the image
COPY ./app /app
# install your app's dependencies
RUN install-dependencies
# tell the container what to run on startup
START run-my-appRead that as a sequence: start from a base, layer on a runtime, copy in your code, install what it needs, and record the command to run. Each line that changes the filesystem produces a layer. The final line is metadata — it doesn’t add a layer, it just records what should happen when a container is created from this image.
The order matters for the caching reasons above. Copying your fast-changing app code last, after the slow-changing dependency install, means a code change only invalidates the final layer. Flip those two and every code change forces a full reinstall of dependencies — slow, and entirely avoidable.
Keep base images small
The base layer you start from sets the floor for your image’s size and its security exposure. A full general-purpose OS base can be hundreds of megabytes and ship a pile of programs your app will never use — each one a potential vulnerability to patch. Minimal base images (often labelled “slim”, “alpine”, or “distroless”) strip that down to the bare essentials. Smaller images pull faster, start faster, and give an attacker less to work with. When in doubt, start smaller and add only what you actually need.
Tags: how you name and version an image
An image needs a name so you can refer to it, and a way to say which version you mean. That’s what a tag is for. The full reference to an image usually looks like this:
registry/namespace/name:tag
│ │ │ │
│ │ │ └─ version label, e.g. 1.4.0, or "latest"
│ │ └────── the image's name, e.g. my-api
│ └──────────────── owner / account, e.g. acypartner
└───────────────────────── where it's stored (often omitted for defaults)A concrete example might be acypartner/my-api:1.4.0. The part after the colon — 1.4.0 — is the tag. It’s just a human-friendly label pointing at one specific build of the image. You might have my-api:1.4.0, my-api:1.5.0, and my-api:latest all sitting side by side, each pointing at a different frozen build.
A few things worth knowing about tags:
- A tag is a movable label, not a permanent identity. You can re-tag a different build as
latesttomorrow. So “latest” doesn’t mean “newest forever” — it means “whatever build someone last pointed that label at.” Relying onlatestin production is a classic footgun: the image underneath can change without your version number changing. - The real identity is a digest. Underneath the friendly tag, every image build has a unique digest — a long content hash like
sha256:9b2c.... The digest is computed from the image’s actual contents, so it never lies and never moves. If you need to be certain you’re running the exact same bits every time, you pin to the digest, not the tag. - Pin versions in production. For anything serious, reference a specific version tag (or a digest) rather than
latest. It makes your deployments reproducible: the image you tested is provably the image that ships.
my-api:latest → (today) points to build A
my-api:latest → (tomorrow) points to build B ← label moved!
my-api@sha256:9b2c... → always the same exact bytes ← never movesWhere images live and how they travel
Once you’ve built an image, it sits on your machine — but the whole point is to share it. Images are pushed to and pulled from a container registry, a storage service built specifically for them. You push an image to a registry to publish it, and others (or your production servers) pull it back down to run it.
your machine registry production server
┌──────────┐ push image ┌──────────┐ pull ┌──────────────┐
│ build it │ ─────────────► │ stores │ ─────────► │ run container │
└──────────┘ │ images │ └──────────────┘
└──────────┘Because images are layered and content-addressed, this transfer is efficient: only the layers the other side doesn’t already have get moved across the wire. Registries are a topic of their own — they’re where naming, access control, and distribution all come together — and they’re the natural next step after this article. For now, the thing to hold onto is the flow: build an image → push it to a registry → pull and run it anywhere.
How images and containers relate, one more time
It’s worth nailing this down because everything else depends on it. The lifecycle goes:
- You write a recipe and build an image — a frozen, layered, read-only blueprint.
- You store and share that image (locally, or via a registry).
- You run the image, which creates a container — a live instance with a thin writable layer on top of the read-only image, so the running app can create temporary files without changing the image itself.
- You can run as many containers from one image as you want. Stop them, delete them, start fresh ones — the image is untouched and always ready to stamp out more.
IMAGE (read-only, shared, permanent)
│
│ add a thin writable layer per run
▼
CONTAINER (live, writable, disposable)That thin writable layer is why a container can run and scribble temporary data while the image underneath stays pristine. When the container is deleted, that writable layer goes with it — which is exactly why anything you want to keep needs to live outside the container, not inside it. But that’s a storage topic for another day. The takeaway here is the clean separation: the image is the durable source of truth, the container is the throwaway running copy.
Why this matters
The image is the single most important artifact in the whole container workflow. It’s what your build process produces, what your tests run against, what gets stored, what gets shipped, and what gets run in production — the same frozen bytes at every stage. That sameness is the entire promise of containers: the image you built and tested on a laptop is provably the image that runs on the server, layer for layer.
It also reshapes how you think about changes. You don’t fix a misbehaving container by logging in and tweaking it. You change the recipe, build a new image, and roll it out — leaving a clean trail of versioned, reproducible artifacts behind you. Once that mindset clicks, deployments stop being scary one-off events and become routine, repeatable swaps of one known-good image for another.
If you want the broader picture of how this fits with the rest of the container world, it builds directly on what a container is and pairs well with understanding how containers differ from virtual machines, since the lightweight, layered nature of images is a big reason containers start so much faster than VMs.
Wrapping up
Here’s the whole idea in one place:
- A container image is a read-only, self-contained blueprint — your app, its dependencies, a minimal OS slice, and startup instructions — frozen into one shareable artifact.
- An image is the template; a container is a running instance created from it. One image, many containers; the image never changes when you run it.
- Images are built from layers, each a frozen step. Layers enable fast cached rebuilds and shared, space-saving storage, which is why you order steps from least-changing (base) to most-changing (your code).
- A tag (the part after the colon, like
:1.4.0or:latest) is a movable, human-friendly label. The real, permanent identity is the digest — pin versions or digests in production, notlatest. - You build an image, push it to a registry, then pull and run it anywhere — and only the layers a machine doesn’t already have travel across the network.
The obvious next question is where all these images get stored and shared once you’ve built them — the registries that name them, version them, and hand them out. That’s exactly the piece this article has been pointing at, and it’s the natural place to head next.
