Docker for Developers Who've Never Touched It

What a container actually is

A container packages your app together with everything it needs to run - the runtime, system libraries, dependencies - into one isolated unit. It behaves the same on your laptop, a teammate's machine, and a production server, because it's carrying its own environment along with it instead of relying on whatever happens to be installed on the host.

A minimal Dockerfile for a Node.js app

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install --production

COPY . .

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

Why the COPY order above matters

Copying package.json and running npm install before copying the rest of the code means Docker can reuse the cached install step whenever only your application code changes, instead of reinstalling every dependency on every single build.

Building and running the image

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

docker-compose for anything with a database

The moment your app needs MongoDB or Postgres alongside it, running two separate docker run commands gets old fast. A compose file describes both services and how they talk to each other in one place.

services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: mongo:7
    ports:
      - "27017:27017"

The payoff

Once this is set up, onboarding a new developer stops being a checklist of "install this specific Node version, install this specific Mongo version" - it becomes docker compose up and waiting a minute.