Docker in Development

After this lesson, you will be able to: Use Docker as your development environment: replace local installs of databases and services with containers, and use VS Code Dev Containers so the whole team codes in an identical, reproducible setup.

Most people meet Docker as a deployment tool, but it is just as valuable in development. Instead of installing Postgres, Redis, and three CLI tools on your laptop (each a different version from your teammate's), you run them as containers. Dev Containers take this further: the editor itself runs inside a container, so 'works on my machine' stops being a sentence anyone says.

Prerequisites:Docker Compose

Stop installing services on your laptop

You need Postgres for a project. The old way: install it, manage the version, fight it when another project needs a different version, and hope your teammate has the same setup. The Docker way: run it as a container, scoped to the project, deleted when you are done. No global install, no version conflicts, identical for everyone. The same applies to Redis, MongoDB, RabbitMQ, MinIO (S3-compatible), and most backing services. Your laptop stays clean; each project declares exactly what it needs.

A throwaway Postgres in one command (and the Compose version)

Two ways: a one-off container, or a project-scoped service in Compose.

tsx

# One-off: a Postgres you can blow away anytime
docker run --name devpg -e POSTGRES_PASSWORD=dev \
  -p 5432:5432 -d postgres:16
# connect at postgres://postgres:dev@localhost:5432
docker rm -f devpg     # gone, no trace on your host

# Project-scoped: docker-compose.yml in the repo, same for every dev
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: dev
    ports: ["5432:5432"]
    volumes: ["pgdata:/var/lib/postgresql/data"]
  redis:
    image: redis:7
    ports: ["6379:6379"]
volumes:
  pgdata:
# `docker compose up -d` and the whole team has identical services.

A minimal devcontainer.json

Commit this in .devcontainer/ and the whole team gets the same environment.

json

// .devcontainer/devcontainer.json
{
  "name": "My App",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "forwardPorts": [3000, 5432],
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode"
      ]
    }
  }
}
// 'Reopen in Container' -> identical Node 20 + ESLint + Prettier for everyone.

Common mistakes only experienced engineers catch

Running a dev database without a named volume, then losing all your data on `docker compose down`. Mount a volume for anything you want to keep. Hardcoding host-installed tool versions in docs instead of pinning them in Compose / the Dev Container, so 'works on my machine' returns. Binding a dev service to 0.0.0.0 on a shared network, exposing your dev database to the LAN. Bind to localhost in dev. Putting node_modules on a bind mount across host and container with mismatched OS/arch, causing native-module breakage. Use a named volume for node_modules in Dev Containers. Treating the Dev Container as production. It is for development; the production image is the optimized multi-stage build from the next lessons.

Quick Check

Why run your project's Postgres as a container instead of installing it on your laptop?

Pick the strongest reason.

←Docker Volumes

Back to Docker and Containerization

Docker Hub and Image Registries→