Docker Fundamentals

Docker packages an application and its runtime dependencies into an image. A container is a running instance of that image.

FROM node:22-alpine
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
COPY . .
RUN pnpm build
CMD ["pnpm", "preview", "--host", "0.0.0.0"]

Further Learning

• “Docker image vs container” — core model
• “Dockerfile best practices Node” — image hygiene
• “docker build run logs” — basic commands

Docker Fundamentals

“Works on my machine” is a classic problem — your app runs fine locally but breaks somewhere else because of a subtle environment difference. Docker solves this by packaging your app and everything it needs (runtime, dependencies, settings) into one portable unit.

Two words to know

• Image — the packaged blueprint (app + everything it needs to run).
• Container — a running instance of that image.

Think of an image like a recipe, and a container like an actual dish made from it. You can make many containers from one image.

Writing the recipe (a Dockerfile)

FROM node:22-alpine       # start from a base with Node installed
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build
CMD ["npm", "run", "start"]

Each line builds on the last, creating a self-contained image with your app baked in — the exact same image runs identically anywhere Docker is installed.

Don’t copy junk into the image

In one sentence

Docker packages your app and its dependencies into a portable image, and a running copy of that image is called a container — this solves “works on my machine” by making the environment identical everywhere.

Want to go deeper?

Switch to Expert mode above for Dockerfile best practices and keeping images small.