What is Docker? A Beginner's Guide to Containers and Images in 2026

A decade ago, getting a new project running on your laptop usually involved an afternoon of installing the right Postgres version, the right Node version, the right Python, the right system libraries, and praying nothing on your machine clashed with anything else. Today you run one command and a fully configured environment is just there. The piece of software that made that the new normal is Docker, and in 2026 it is the foundational tool of modern backend, DevOps, and cloud development.

This guide explains what Docker is, the difference between an image and a container, why developers and teams adopted it so fast, and how to run your first container today. By the end you will be comfortable enough to read any project's README that says "just run docker compose up" and actually know what is happening.

What Docker Actually Is

Docker is a tool for packaging an application together with everything it needs to run — its code, runtime, system libraries, environment variables, configuration — into a single, portable unit called a container. That container runs identically on your laptop, on a teammate's laptop, on a CI server, and in production.

Two clarifications. Docker is not a virtual machine — VMs virtualise an entire operating system and take gigabytes of RAM. Containers share the host kernel and feel more like lightweight processes (they boot in milliseconds, use a fraction of the memory). And Docker is not the only container runtime — containerd, podman, and others speak the same OCI standard. Docker is just the most popular and beginner-friendly entry point.

In 2026, the standard local toolchain is Docker Desktop (or the open-source OrbStack on macOS, which most developers prefer for speed). Both ship with the Docker CLI, Compose, and a built-in Kubernetes for when you outgrow single containers — full intro in What is Kubernetes?.

Images vs Containers (The One Distinction That Matters)

This is the single most important concept to internalise:

• An image is a blueprint — a read-only, layered snapshot of a filesystem plus the command to run. Like a class in OOP.
• A container is a running instance of an image. Like an object created from that class. You can have many containers from one image.

You build an image once (docker build), push it to a registry like Docker Hub or GitHub Container Registry, and then anyone can pull and run it (docker run). The image never changes; the container is the live thing with state, network, and a process.

If you remember nothing else, remember: images are static, containers are running.

Why Developers Adopted It So Fast

Five reasons Docker went from cool toy to universal infrastructure in under five years:

1. "Works on my machine" is solved. The container is the environment. No more version drift between dev and prod.
2. Onboarding is one command. New teammate? git clone + docker compose up and they are running the full stack in two minutes.
3. Microservices became practical. Running a Postgres + Redis + API + worker locally without containers is misery; with Docker Compose it is a YAML file.
4. CI/CD got dramatically faster and more reliable. Build the image once in CI, run the same image in staging and production.
5. Cloud platforms standardised on it. AWS ECS/Fargate, Google Cloud Run, Azure Container Apps, Fly.io, Railway — they all run containers natively.

Your First Real Docker Session

Let us pull the official Postgres image and run a database in 10 seconds.

bash

$ docker run -d --name pg \
    -e POSTGRES_PASSWORD=secret \
    -p 5432:5432 \
    postgres:17
 
$ docker ps                   # see it running
$ docker logs pg              # see startup logs
$ docker exec -it pg psql -U postgres   # open a shell inside
$ docker stop pg && docker rm pg        # clean up

What just happened: Docker downloaded the postgres:17 image (cached after the first run), started a container in detached mode, mapped your machine's port 5432 to the container's, set an env var, and gave the container a friendly name. The whole thing is one command, repeatable on any machine.

Building Your Own Image

You build images with a Dockerfile — a small text file describing how to assemble your app's environment. A minimal Node.js example:

dockerfile

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

Build it with docker build -t myapp:1.0 . and run it with docker run -p 3000:3000 myapp:1.0. Six lines, fully portable web service. Full breakdown of every Dockerfile instruction in Dockerfile Explained: How to Build Your First Container Image.

Docker Compose: Multi-Container Apps Made Easy

Real apps are rarely one container. You usually want your app + database + cache + maybe a worker. Docker Compose lets you describe the whole stack in a compose.yaml and start it all with one command:

yaml

services:
  app:
    build: .
    ports: ["3000:3000"]
    depends_on: [db]
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: secret
    volumes: [pgdata:/var/lib/postgresql/data]
volumes:
  pgdata:

docker compose up starts everything; docker compose down stops and cleans up. This is what most modern repos use for local development.

Common Mistakes Beginners Make

• Confusing images and containers. They are different things. docker images lists images; docker ps lists running containers; docker ps -a lists all containers including stopped.
• Shipping a 2 GB image because you used node instead of node:22-alpine. Always pin a slim base image.
• Storing data only inside the container. Containers are ephemeral. Use volumes (-v or volumes: in Compose) for any data you want to keep.
• Running as root. The default. Bad for security. Add USER node (or similar) at the end of your Dockerfile.
• docker system prune without thinking. Free disk space — yes, but it deletes stopped containers, unused images, and dangling volumes. Make sure those are actually unused.

Quick Reference

• Run a container: docker run -d --name <name> -p <host>:<container> <image>
• List running: docker ps. List all: docker ps -a. List images: docker images.
• Logs: docker logs -f <name>. Shell inside: docker exec -it <name> sh.
• Build: docker build -t <name>:<tag> .. Tag for registry: docker tag <name> ghcr.io/me/<name>:1.0.
• Stop and remove: docker rm -f <name>. Remove image: docker rmi <name>.
• Compose: docker compose up -d, docker compose logs -f, docker compose down.
• Persistent data: named volumes (-v mydata:/var/lib/...), not bind mounts for production.