Lesson 2 of 6 ·12 min read

The localhost trap

Suppose you have three containers running: a Flask API, PostgreSQL, and Redis. How does Flask talk to PostgreSQL? The natural first guess:

Flask → localhost:5432   ✗

It fails, and the reason teaches you the core idea. Inside the Flask container, localhost means this Flask container. Not your machine, and not the PostgreSQL container. Each container has its own isolated network view, exactly like each has its own filesystem.

Networks and built-in DNS

Docker's answer is the network: put containers on a shared network and Docker runs a small DNS service inside it, resolving container names to the right container.

           Docker network
  ┌─────────────────────────────┐
  │   ┌────────┐                │
  │   │ Flask  │                │
  │   └───┬────┘                │
  │       │  postgres:5432      │
  │       ▼                     │
  │   ┌────────────┐            │
  │   │ PostgreSQL │            │
  │   └────────────┘            │
  │   ┌────────┐                │
  │   │ Redis  │                │
  │   └────────┘                │
  └─────────────────────────────┘

Instead of an IP address, the connection string simply names the service:

postgresql://user:password@postgres:5432/mydatabase

This matters because containers are disposable: recreate one and its internal IP changes, but its name does not. Hardcoded IPs break on every restart; names keep working.

Compose: the stack in one file

You could create the network and start each container by hand, in the right order, with the right flags, every time. Compose replaces that ritual with a file:

services:
  api:
    build: .
    ports:
      - "8000:5000"
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/mydatabase
    depends_on:
      - db

  db:
    image: postgres:17
    volumes:
      - dbdata:/var/lib/postgresql/data

  redis:
    image: redis

volumes:
  dbdata:

docker compose up
docker compose down

Compose creates the network automatically, and each service is reachable at its service name: the API connects to db:5432 because the service is called db. Notice the pieces from Lesson 1 reappearing with their jobs unchanged: a port mapping for the one service the outside world should reach, an environment variable delivering configuration, a named volume protecting the database's data.

depends_on controls start order, with a catch worth knowing now: it waits for the database container to start, not for the database inside it to be ready to accept connections. Real setups add a health check or retry logic in the app. Filing that distinction away early will save you a confusing morning later.

What Compose is, and is not, for

Compose is the standard way to run a multi-service app in development: one file in the repo, docker compose up, and every teammate has the whole stack. It can also be a perfectly reasonable way to run a small production system on a single server.

What it does not do is turn one machine into many. If that server fails, everything on it fails together. Backups, OS updates, HTTPS, and failover all remain your job. When those limits start to bite, you are ready for the second half of this course; when they do not, one server running Compose is a legitimate production architecture, not a temporary embarrassment.