Docker Explained for Beginners 2026 - Containers, Images & Docker vs VMs

Docker turned "it works on my machine" into a solved problem. It packages an application with everything it needs to run into a single portable unit called a container.

This page covers building and running containers. Running many of them across a fleet of machines is a different job - see Kubernetes explained simply for that half.

What is Docker?

Docker packages applications with all their dependencies - libraries, runtime and config - into containers that run identically on any machine, from your laptop to a production cloud server.

Why Docker matters

It eliminates environment mismatches, makes deployments repeatable, starts in seconds, and is the foundation that CI/CD pipelines and Kubernetes build on.

Key concepts

• Image: a read-only template (your app plus dependencies).
• Container: a running instance of an image.
• Dockerfile: the recipe that defines how an image is built.
• Registry: where images are stored and shared (e.g. Docker Hub).

The relationship worth fixing in your head early: a Dockerfile builds an image, an image runs as a container. Editing a running container changes nothing about the image, which is why "I fixed it inside the container" is never a fix.

A real Dockerfile

This is a production-shaped Dockerfile for a Node service. It is a multi-stage build, which is the single biggest difference between a beginner image and a professional one.

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

Three things there are doing real work:

• Copying package*.json before the rest of the source. Docker caches each instruction as a layer and reuses it while its inputs are unchanged. Dependencies change far less often than your code, so this ordering means a one-line code edit does not reinstall every package. Get this wrong and every build reinstalls from scratch.
• Two FROM stages. Build tools, dev dependencies and source code stay in the first stage. Only the compiled output is copied into the final image, which is typically several times smaller and has a much smaller attack surface.
• USER node. Containers run as root by default. There is rarely a reason for that, and a container escape from a root process is considerably worse than from an unprivileged one.

The .dockerignore file nobody writes

Without one, COPY . . ships your node_modules, your .git directory and any local .env file into the image. That makes builds slow and can leak secrets into a layer that anyone who pulls the image can read. A minimal one:

node_modules
.git
.env
*.log
dist

The commands you will actually use

Command	What it does
docker build -t myapp:1.2.0 .	Build an image from the Dockerfile in this directory and tag it.
docker run -p 3000:3000 myapp:1.2.0	Run it, mapping host port 3000 to container port 3000.
docker ps / docker ps -a	List running containers, or all of them including stopped ones.
docker logs -f <id>	Follow a container's output. First stop when something will not start.
docker exec -it <id> sh	Get a shell inside a running container to look around.
docker system prune -a	Reclaim disk. Images and layers accumulate quickly and fill drives.

Docker vs virtual machines

A virtual machine virtualises an entire operating system - it is heavy (gigabytes) and slow to boot. A container shares the host OS kernel and only packages the app and its dependencies - it is lightweight (megabytes) and starts in seconds. You can run far more containers than VMs on the same hardware, which is why containers won for modern app deployment. VMs still matter when you need strong isolation or a different operating system.

That shared kernel is also the security trade-off, and it is worth being able to say so in an interview: containers isolate processes, not kernels. Two VMs on one host are separated far more strongly than two containers are.

Mistakes that show up in every first Dockerfile

• Tagging everything latest. You then cannot tell which build is running in production, and rollback becomes guesswork. Tag with a version or the commit SHA.
• Passing secrets as build arguments. Build args are visible in the image history. Inject secrets at run time as environment variables, or use a secrets manager.
• Installing debug tools "just in case". Every extra package is more to patch and more for a scanner to flag.
• Running as root because the tutorial did.
• Treating a container as a small server - SSHing in, editing files, restarting things by hand. Containers are meant to be replaced, not repaired.

How DevOps uses Docker

Docker images are built in CI/CD pipelines, pushed to a registry, and deployed - usually orchestrated by Kubernetes - to run reliably at scale.

In a normal pipeline the image is built once, tagged with the commit that produced it, scanned for vulnerabilities, pushed to a registry, and then that exact tag is deployed to staging and later to production. Building separately for each environment defeats the point: the artifact you tested must be the artifact you ship.