What Is Docker? A Beginner's Explanation

"It works on my machine" is one of the oldest jokes in software. An app runs perfectly on one computer and fails on another, because the other computer has a different version of Node, a missing library, or a different operating system.

Docker was built to end that problem. It packages an app together with everything it needs to run, so it behaves the same everywhere.

The shipping container idea

Before shipping containers, cargo was loaded piece by piece — barrels, sacks, crates of every shape — and every port handled it differently. Then came the standard steel container: pack anything inside, and every ship, crane, and truck in the world knows how to move it.

Docker does the same for software. You pack your app — code, runtime, libraries, settings — into a standard container. Any computer with Docker can run it, and it runs the same way.

Images and containers

Two words you'll see constantly:

An image is the packed box — a read-only template containing your app and everything it needs. Like a recipe, or a class blueprint.
A container is a running copy of an image. You can start many containers from one image, stop them, delete them, and start fresh ones.

Images are built from a Dockerfile — a short text file listing the steps: start from a base (say, an official Node.js image), copy in the code, install dependencies, and specify how to start the app.

FROM node:24
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["npm", "start"]

You don't need to understand every line — but you can see it's just a recipe. (Writing a Production Dockerfile covers doing it properly.)

Containers vs virtual machines

A virtual machine (VM) pretends to be an entire computer, including its own operating system. It's heavy: gigabytes in size, minutes to start.

A container shares the host computer's operating system core and only packages the app and its dependencies. It's light: often megabytes, starts in seconds, and you can run dozens on one machine.

The trade-off: because containers share the host's core, they're less isolated than VMs by default. For running your own apps, that's usually fine. For running untrusted code, it matters — see Firecracker vs gVisor vs Containers.

Why Docker is everywhere

Consistency — the same image runs on your laptop, a teammate's, and the server.
Hosting — many hosts simply ask for a Docker image and run it. Build it once, run it anywhere.
Easy databases for development — one command starts a Postgres database on your computer, no installation:
```
docker run -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:17
```
Isolation — each container has its own filesystem and limited view of the machine, so apps don't interfere with each other. Platforms use this to keep different users' projects apart. (Docker vs Linux Users for Multi-Tenant Isolation)
Dev containers — whole development environments defined in a file, so everyone gets the same setup. (What Is a Dev Container?)

The one thing that surprises everyone

Containers are disposable. When a container is deleted and replaced — which happens every time you update the app — anything written inside it is gone.

That's great for code and terrible for data. If your database stores its files inside a container, your data disappears the next time the container is recreated. Data that must survive lives outside the container, in volumes. (Docker Volumes vs Bind Mounts explains the options.)

Docker Compose: several containers together

Real apps often need more than one piece: the app, a database, maybe Redis. Docker Compose lets you describe them all in one file (docker-compose.yml) and start them together with docker compose up. It's the easiest way to run a full app stack on your computer.

Do you need to learn Docker?

It depends on how you build:

Using an AI builder's hosting (Lovable, Bolt, v0, Replit)? No — they handle it.
Using an app platform or managed platform? Probably not; many build containers for you from your code.
Running your own server, or developing locally with a database? A little Docker is very useful.
Working as a developer? Yes, eventually. It's a standard tool.

A good beginner goal: understand images, containers, volumes, and Compose well enough to follow what your AI tool is doing — and to know that your data must live in a volume or a managed database, not inside a container.

The summary

Docker packages an app with everything it needs, so it runs the same anywhere.
Image = the packed template. Container = a running copy.
Containers are lighter than virtual machines, and less isolated by default.
Containers are disposable — keep data in volumes or a managed database.
Compose runs several containers together.

EasySpawn runs every workspace as its own Docker container with persistent storage mounted in — so the container can be replaced any time, and your code, dependencies, and data stay put. See how it works or join the waitlist.