Getting started with Docker for web developers

"Works on my machine" is almost always a difference in installed versions, environment variables, or OS-level dependencies that never made it into a README. Docker fixes that by packaging your app together with everything it needs to run.

What a container actually is

A container is not a virtual machine — it doesn't boot its own OS. It's an isolated process that shares your machine's kernel but gets its own filesystem, built from instructions in a file called a Dockerfile. That isolation is what makes "it works in the container" mean the same thing everywhere.

Writing your first Dockerfile

For a small Node.js app, a Dockerfile is usually four sections: a base image, dependency install, copying your code, and a start command.

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

CMD ["node", "server.js"]

FROM picks a starting image — node:20-alpine is a minimal Linux image with Node preinstalled. Copying package*.json before the rest of your code, then installing, means Docker can reuse that layer on rebuilds if your dependencies haven't changed — one of the biggest speedups new Docker users miss.

Building and running it

docker build -t my-app .
docker run -p 3000:3000 my-app

-p 3000:3000 maps port 3000 inside the container to port 3000 on your machine — without it, the container's server is running but unreachable from your browser.

Checking what's running

docker ps
docker logs <container-id>

docker ps lists running containers; docker logs is the first place to look when a container starts but the app inside isn't responding — most "it's not working" issues turn out to be a crashed process, visible immediately in the logs.

Where this goes next

Once a single container runs cleanly, the natural next step is docker-compose for running your app alongside a database container — two services, one command, no local Postgres install required.