Containers in Production

Build the mental model

A container packages an app, its runtime, and every dependency into one portable unit that runs the same way everywhere — that portability is the whole point.

Container vs VM

A VM virtualizes a whole operating system. A container shares the host's kernel and only isolates the application layer — which is why containers start in milliseconds while VMs take seconds or minutes.

Image — a built, frozen, versioned snapshot of the app plus dependencies.
Container — a running instance of that image; one image can run as many containers.
Flow: build image -> push to registry -> deployment server pulls it -> runs as container(s).

Shipping a new version means building a new image and replacing the running container — never patching files inside a live server. This is what makes deployment immutable.

For Dockerfile syntax and Docker Compose mechanics, see this site's Docker tutorial. For orchestrating many containers across many machines, see the Kubernetes tutorial.

text

IMAGE TO RUNNING CONTAINER
--------------------------
IMAGE TO RUNNING CONTAINER
----------------------------

[ source code ]
      |
      | docker build
      v
[   IMAGE   ]  (frozen, versioned snapshot)
      |
      | docker push
      v
[  REGISTRY  ]
      |
      | deployment server: docker pull
      v
[ DEPLOY SERVER ]
      |
      | docker run  (can start many)
      v
[CONTAINER 1] [CONTAINER 2] [CONTAINER 3]
   (running instances of the same image)

Connect it to a real scenario

This is an illustrative snippet only — short on purpose, not meant to be run or copied into a real project.

Base image

Start from a base runtime image (e.g. a Node.js runtime).

Copy + install

Copy dependency manifests in, then install dependencies.

Copy app code

Copy the rest of the application source into the image.

Declare start command

Declare the command that starts the app when a container runs.

For real syntax and Docker Compose, use the dedicated Docker tutorial — it teaches the mechanics this lesson deliberately skips.

An image is a frozen, versioned snapshot; a container is a running instance of that image.
Production containers follow build -> push to registry -> pull -> run, and shipping a new version means a new image, not a patched server.
This lesson is orientation-level — go to the Docker tutorial for Dockerfile syntax and the Kubernetes tutorial for orchestration.

Try the working example

bash

FROM node:20-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["node", "server.js"]

Not runnable here

This code/config is illustrative and can't run directly in this site's browser playground -- it needs a real cloud platform or a real DNS/hosting setup. The dedicated Docker, Terraform, and AWS tutorials on this site let you practice the real mechanics hands-on.

You should see

This is illustrative only, not runnable here. Each line adds a build-time layer; running docker build produces an image, and only docker run starts a container from it. See the Docker tutorial for real build output.

5-minute try-it

Write down, in your own words, what would happen if you edited a file directly inside a running production container instead of rebuilding the image. Why does that change disappear the next time the container restarts?

One important caution

SSHing into a running production container to hand-edit a file, then losing that fix the next time the container restarts or redeploys.

Assuming a container is a lightweight VM rather than an isolated process sharing the host kernel — leading to wrong assumptions about isolation and startup time.

Docker docs — What is a container? — Cloud & Deployment