Docker: a complete overview

What Docker is: eight key terms, when it helps and when it does not, pros and cons, three files for a real project, mistakes and rules for production.

Stack and technologies Updated Oct 2, 2026

In short

Docker packs an application together with everything it needs — the language version, libraries, settings — into an image, and runs it as an isolated container. The same image works on a developer’s laptop, on a test server and in production, so “it works on my machine” stops being a problem. Docker Compose describes several containers — the application, the database, the queue — in one file and starts them with one command. Docker is useful when a project has several services, a team or regular deployments; for a simple site on shared hosting it adds more than it gives.

Docker at a glance

The main facts in one table — what Docker is, what it consists of and what it costs.

What it is: A platform for packing applications into images and running them as containers
History: Released in 2013 by the dotCloud company, later renamed Docker
Parts: Docker Engine, Docker Compose, Docker Hub, Docker Desktop
Licence: The engine is open source; Docker Desktop is paid for larger companies
Standard: Images follow the OCI format and also run in Podman and Kubernetes
Isolation: Containers share the kernel of the host — lighter than virtual machines
Where it runs: Linux natively; on macOS and Windows through a small virtual machine

Docker in eight words

The terms that appear in any conversation about Docker.

Term	What it is	An everyday comparison
Image	a frozen package: system, language, code	a recipe with all the ingredients
Container	a running copy of an image	a dish cooked from the recipe
Dockerfile	instructions for building an image	the recipe itself
Layer	the result of one instruction, cached	a step that need not be repeated
Volume	storage that outlives the container	a fridge next to the kitchen
Network	how containers see each other	an internal phone line
Registry	a store of images: Docker Hub, GitHub	a library of recipes
Compose	several containers in one file	the menu of a whole dinner

When Docker helps and when it does not

Ten typical situations with a recommendation.

Situation	Docker	Why
Several services: app, database, queue	yes	one file describes the whole system
A team of developers	yes	everyone has the same environment
Different language versions on one server	yes	each project in its own container
Automatic deployment	yes	the tested image goes to production as is
Tests with a real database	yes	a clean database for each run
Moving to another server	yes	the same images start anywhere
A simple site on shared hosting	no	hosting usually does not allow it, and it is not needed
One small PHP site on a VPS	optional	a plain server setup is simpler
Heavy work with graphics cards	with care	possible, but needs extra setup
Managed platforms	often inside	many platforms build an image from the code themselves

Pros and cons of Docker

Docker trades a little simplicity for a lot of repeatability.

Pros · 5

The same everywhere

The image that passed the tests is exactly the one that runs in production.
Projects do not interfere

Different versions of languages and libraries live on one server.
A system in one file

Compose describes all the services and how they are connected.
Fast rollback

The previous version is the previous image — one command back.
Ready services

PostgreSQL, Redis or a search engine start from an official image in a minute.

Cons · 4

Another layer to understand

Networks, volumes and images add their own kinds of failures.
Data needs care

Without a volume, the data disappears with the container.
Updates do not happen by themselves

Images must be rebuilt to get security fixes of the system inside.
Firewall surprises

Published ports bypass ordinary firewall rules on Linux.

What Docker looks like: 3 files

An image for a Node.js application, the application together with its database, and the list of what must not get into the image.

An image in two stages

Building tools stay in the first stage; the final image has only what is needed to run, and works without root rights.

Dockerfile

# Stage 1: install dependencies and build
FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: only what is needed to run — a small, clean image
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

The application and its database

The application waits until the database is ready, the password is a secret file, the port is open only to this machine.

compose.yaml

# The application and its database start with one command: docker compose up -d
services:
  app:
    build: .
    ports:
      - "127.0.0.1:3000:3000"   # only for the web server on this machine
    env_file: .env
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets: [db_password]
    volumes:
      - db-data:/var/lib/postgresql/data   # the data outlives the container
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10
    restart: unless-stopped

volumes:
  db-data:

secrets:
  db_password:
    file: ./secrets/db_password.txt

What stays outside

Without this file, keys and the whole history of the project can end up inside the image.

.dockerignore

# Never sent into the image: secrets, dependencies and history
.env
secrets/
.git
node_modules
dist
*.log

Common mistakes with Docker

Ports open to the whole internet

3000:3000 publishes the port on every address and bypasses the firewall; 127.0.0.1:3000:3000 does not.
Data inside the container

A database without a volume loses everything on the first re-creation.
Secrets in the image

A key copied into an image stays in its layers even if it is deleted later.
The latest tag

Tomorrow it is a different version — builds stop being repeatable.
Running as root

A vulnerability in the application gives more rights than it should.
No limits

One container can take all the memory and stop everything else on the server.

7 rules for Docker in production

01

Pinned versions

node:22-alpine, postgres:17 — never latest.
02

Two-stage builds

A small final image is faster to deploy and has fewer vulnerabilities.
03

Not root

The USER instruction in every image of the application.
04

Ports only where needed

Services talk inside the Compose network; outside — only through the web server.
05

Volumes and backups

Every database is on a volume, and the volume is in the backup plan.
06

Memory and processor limits

mem_limit and cpus for every service next to others.
07

Regular rebuilds

Images are rebuilt on a schedule to pick up security fixes.

Questions about Docker

What is Docker in simple words?

A way to pack an application with everything it needs and run it the same way on any server.

How is a container different from a virtual machine?

A container shares the kernel of the host and starts in seconds; a virtual machine carries a whole system.

Is Docker free?

The engine on a server is free; Docker Desktop is paid for companies above a certain size.

Does a website need Docker?

A simple site does not; a project with several services, a team and regular deployments does.

Docker or Kubernetes?

Docker with Compose is enough for one or a few servers; Kubernetes manages containers on many.

Can a database run in Docker?

Yes, with a volume, backups and memory limits; many prefer a managed database for production.

What is Podman?

An alternative to Docker that runs the same images and works without a background service and root rights.

Online form

Launch
without surprises

I hand over a finished project deployed to your hosting, and decide with you whether it needs Docker or an ordinary server setup is enough. Tell me about the project — I answer within one working day.

In short

Pros · 5

The same everywhere

Projects do not interfere

A system in one file

Fast rollback

Ready services

Cons · 4

Another layer to understand

Data needs care

Updates do not happen by themselves

Firewall surprises

An image in two stages

The application and its database

What stays outside

Ports open to the whole internet

Data inside the container

Secrets in the image

The latest tag

Running as root

No limits

Pinned versions

Two-stage builds

Not root

Ports only where needed

Volumes and backups

Memory and processor limits

Regular rebuilds