From Blueprint to Running Process: Inside Container Images

You know what a container is and why it exists. Now let's open the hood. This article walks through what a container image really is — the Dockerfile that describes it, the layers that make it efficient, how those two fit together, and then takes you through building, sharing, and finally dissecting a real-world image piece by piece. By the end you should be able to look at any image and know exactly what it contains.

Image vs. Container — the Core Distinction

The single most important concept in this article is the difference between an image and a container. They are related but they are not the same thing, and confusing them causes endless frustration.

An image is the recipe — a read-only package sitting on disk that contains everything the application needs: an operating system base, the runtime, libraries, your code, and metadata. It never changes after it has been built. A container is what you get when you run that recipe — a live process with its own thin writable layer on top of the image. One image can produce many independent containers running at the same time.

The practical consequence that surprises many beginners: any files you create inside a container disappear when you delete the container. The container's writable layer is temporary. If you need data to survive — for a database, for uploaded files — you need volumes.

The Dockerfile — Your Image's Recipe

A Dockerfile is a plain text file that describes, step by step, how to build a container image. Think of it as a cooking recipe: each line is one instruction, and the order matters. Every image you have ever pulled — PostgreSQL, nginx, Ubuntu, your colleague's app — was built from a Dockerfile written by somebody, somewhere.

Here is a complete, working Dockerfile for a small Python web app. It's only seven lines, but each one matters:

Let's go through what is happening. Each line is an instruction, and there are only about a dozen instructions in the whole Dockerfile language. These seven cover the vast majority of real-world cases:

A few details that trip up beginners on their first Dockerfile:

• Build-time vs. run-time. The instructions FROM, WORKDIR, COPY, and RUN all execute once, when you build the image. CMD is different — it doesn't run during build. It is stored as metadata and only executes when a container is started from the finished image.
• EXPOSE does not actually open a port. Despite the name, it is purely documentation: a note that says "this app listens on port 8080." To make the port reachable from the outside world, you pass -p 8080:8080 when running docker run. We'll see this in action shortly.
• Only the last CMD matters. If you write several CMD lines, Docker silently ignores all but the last one. Use it exactly once, at the bottom of your Dockerfile.
• Order matters a lot — and that's because of layers, which we get to next.

Once your Dockerfile is ready, you turn it into an image with one command, run in the directory that contains it:

The -t my-app:1.0 flag gives your image a name and a version tag. The dot at the end (easy to miss!) tells Docker to look for the Dockerfile in the current directory. Docker then walks through your instructions one by one and produces an image stored on your machine, ready to run.

Layers — What an Image Really Is

Now that you have seen a Dockerfile, here is what Docker is actually doing with it behind the scenes.

Every instruction in your Dockerfile creates a separate layer. A layer is a snapshot of what changed on the filesystem at that step — a tiny "delta" that captures only the differences from the layer below it. An image is not one big file. It is a stack of these layer-deltas, stitched together to look like a single coherent filesystem when a container runs.

Take the Python Dockerfile from the previous section. Docker turns it into roughly these layers, stacked from bottom to top:

• Layer 1: everything in python:3.12-slim (a slim Debian Linux + Python 3.12) — from FROM
• Layer 2: the /app directory exists — from WORKDIR
• Layer 3: requirements.txt sits inside /app — from the first COPY
• Layer 4: Python packages are installed — from RUN pip install
• Layer 5: the rest of the source code is in place — from the second COPY

The single most important property of layers is this: layers are content-addressed and shared. Docker identifies each layer by a SHA256 hash of its contents — a unique fingerprint. If ten different images on your machine all start FROM python:3.12-slim, that base layer is stored exactly once on disk and reused by all ten. When you pull a new image from a registry, Docker only downloads the layers it doesn't already have. This is why a fresh Node.js app image might download in a few seconds: the underlying Node.js and Debian layers were already on your machine from a previous pull.

How Dockerfile and Layers Work Together — Layer Caching

Layers are not just a storage trick. They are also a build-speed trick. This is where the Dockerfile and layers really come together.

When you change something in your project and run docker build again, Docker walks through each instruction in the Dockerfile and asks: did anything change for this step? If nothing has changed, Docker reuses the cached layer from the previous build, skipping the work entirely. If something has changed, Docker re-runs that instruction — and every instruction after it — because those later layers might depend on what changed.

That single rule has a huge practical consequence: the order of instructions in your Dockerfile directly controls how fast your rebuilds are. Put things that change rarely (the base image, dependency installs) before things that change often (your application code).

Multi-stage builds: keeping final images tiny

There is one more layer trick worth knowing. To build certain applications — especially compiled ones in Go, Java, or Rust — you need compilers, build tools, and test frameworks. But none of those need to ship in the final image that runs in production. They add hundreds of megabytes and security vulnerabilities.

Multi-stage builds let you use multiple FROM statements in a single Dockerfile. You build your application in a "heavy" stage that contains the toolchain, then copy only the finished artifact into a tiny final stage. Everything from the heavy stage is thrown away. Here is the pattern for a Go application:

The final image contains only the compiled binary — no Go compiler, no source code, no package manager. Docker's own documentation shows this exact pattern shrinking a Go "hello world" image from 805 MB down to 8 MB — a 99% reduction.

Building and Sharing — A Practical Walkthrough

Knowing how to write a Dockerfile is half the picture. The other half is sharing the image you built, so it can run on other people's machines — your colleagues' laptops, a CI server, a production cluster, anywhere.

For that you need a registry: a server that stores images and lets others download them. The default public registry is Docker Hub at hub.docker.com, and you can sign up for a free account in under a minute. There are other registries — GitHub's GHCR, Amazon's ECR, Google's Artifact Registry, and more — and we'll compare them in a separate article. For this walkthrough, Docker Hub is the easiest place to start.

Here is the whole flow at a glance:

Now the actual commands, in the order you would run them on the day you publish your first image:

That's it. The image is now public on Docker Hub. Anyone in the world can run it with a single command — and they don't even need to pull it first, because docker run downloads any missing pieces automatically:

A few details worth knowing on your first push:

• The image name alice/weather-app:1.0 follows the format <username>/<repository>:<tag>. The username scopes the image to your Docker Hub account.
• By default, images pushed to Docker Hub are public — anyone can pull them. To keep an image private, you need to create a private repository on Docker Hub before pushing to it.
• Notice how docker push only transfers the layers Docker Hub doesn't already have. If you push three versions of the same app over time, the base image and dependency layers are uploaded only once. The same happens in reverse for pulls.
• The example above used the -p 8080:8080 flag at run time. This is what actually publishes the port to the outside world — remember, the EXPOSE in the Dockerfile was only documentation.

This same workflow — build once, push once, pull anywhere — is the foundation of nearly every modern deployment pipeline. We'll explore choosing the right registry, securing them, and automating pushes from CI in a separate article.

Tags and Digests: Naming Your Images

In the example above, we pushed an image called alice/weather-app:1.0. The 1.0 part is the tag — a human-readable label for that specific version of the image. A full image reference looks like registry/repository:tag, for example docker.io/nginx:1.25 or python:3.12-slim.

Tags are convenient, but they come with a hidden danger: tags are mutable. Anyone with push access can re-point a tag to a completely different image at any time. The nginx:latest tag you pulled this morning may not be the same image as the nginx:latest someone else pulls tomorrow afternoon. Production systems that depend on latest can change behaviour silently overnight.

The fix is the digest: a SHA256 hash computed from the image's bytes themselves. You pin to it like this: python:3.12-slim@sha256:06a3f7b1.... If anything inside the image changes — a single byte — the hash changes too. The same digest, anywhere in the world, on any day, refers to exactly the same bits.

For development, tags are fine — they're readable and convenient. For anything that runs in CI or production, you should pin to digests. The maintenance pain (digests are long and unmemorable) is solved by tools like Docker Scout, Renovate, and Dependabot, which automatically track new versions and update the digests in your Dockerfile via pull requests.

Dissecting a Real Image — Inside postgres:16

To finish, let's open up a real, well-known image and see what's actually inside one. The official postgres:16 image — running countless databases in production around the world — is a great case study because it is public, well-engineered, and small enough to grasp at a glance.

When you run docker pull postgres:16, Docker downloads about 425 MB across roughly a dozen Dockerfile-level layers. Those layers can be grouped logically into seven distinct purposes:

Let's read the diagram from the bottom up — the order in which Docker actually builds the image:

L1 · Debian Bookworm slim (~30 MB) — a minimal Debian Linux user space. No Python, no compilers, no documentation — just enough Linux to run programs. This is the FROM of the postgres Dockerfile, the foundation on which everything else is built. Because many other images share this same base, the layer is often already on your machine from a previous pull.

L2 · System user "postgres" (under 1 MB) — a dedicated user account. The PostgreSQL server should never run as root, so the image creates a non-privileged postgres user that the daemon will switch to before starting.

L3 · Locale and timezone setup (under 1 MB) — UTF-8 locale and the C standard library's locale data. Without this, PostgreSQL would struggle with text in non-English languages — accents, non-Latin scripts, sorting rules, and so on.

L4 · gosu utility (~2 MB) — a tiny tool used by the startup script to drop from root to the postgres user when starting the daemon. It is the safer cousin of sudo for use inside containers.

L5 · PostgreSQL apt sources and GPG keys (under 1 MB) — configures the official PostgreSQL Debian repository so that apt can install Postgres straight from the upstream source, rather than the older version shipped with Debian itself.

L6 · PostgreSQL 16 server + tools (~280 MB) — this is the bulk of the image: the actual postgres daemon, the client tools (psql, pg_dump, pg_restore, etc.), and every shared library they depend on. Roughly two-thirds of the image's total size lives in this single logical layer.

L7 · Entrypoint script + defaults (under 1 MB) — a shell script called docker-entrypoint.sh that runs when the container starts. It checks whether a database has already been initialised, creates an empty cluster if not, applies any custom configuration you provided through environment variables, then hands control over to the postgres daemon.

On top of the layers, the image also carries metadata — small pieces of information Docker reads when starting a container from it:

• EXPOSE 5432 — documents the standard PostgreSQL port
• USER postgres — runs the daemon as the postgres user, not root
• VOLUME /var/lib/postgresql/data — declares where the database files live, encouraging you to mount a persistent volume there
• ENTRYPOINT docker-entrypoint.sh — the script that runs when the container starts
• CMD ["postgres"] — the default command passed to the entrypoint

Why does any of this matter? Because once you can read an image's layers, you understand exactly what's running inside your container — no magic. You can predict where data persists (in /var/lib/postgresql/data, which is why you mount a volume there), why port 5432 needs publishing, why the first startup is slightly slower than later ones (the entrypoint initialises the cluster on first run), and which Linux distribution your queries are actually running on top of (Debian Bookworm).

This pattern — minimal base, dedicated user, system setup, application binaries, entrypoint script, metadata — repeats across nearly every well-built image you'll encounter. The official nginx image follows it. The redis image follows it. Once you've written a few images of your own, yours will start to look like this too.