🔌 Networking and Volumes

The Two Invisible Systems

You've already used both networking and volumes in earlier lessons — services reached each other by name, and a database kept its data across restarts. Now we look under the hood so you can shape these systems deliberately rather than relying on the defaults.

The Default Network & DNS

When you run docker compose up, Compose does something helpful automatically: it creates a single bridge network named after your project and connects every service to it. On that network, each service is reachable by its service name, because Compose runs an embedded DNS server that resolves those names to the right container.

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"     # published to the host

  api:
    build: ./api
    ports:
      - "3000:3000"   # published to the host

  db:
    image: postgres:16
    # No ports: — not reachable from the host, only from other services

With just that file, here's what's true — and worth reading carefully, because these four facts explain most of Compose networking:

• web can reach api at http://api:3000
• api can reach db at db:5432
• The host (your laptop) can reach web at localhost:8080 and api at localhost:3000, because those ports are published
• The host cannot reach db directly, because it publishes no ports — which is exactly what you want for a database

Custom Networks for Isolation

The single default network is fine for small apps, but sometimes you want stronger boundaries — for example, ensuring the web tier physically cannot reach the database, only the API can. You get that by defining your own networks and attaching each service only to the ones it needs.

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      - frontend        # only on the frontend network

  api:
    build: ./api
    networks:
      - frontend        # talks to web…
      - backend         # …and to the database

  db:
    image: postgres:16
    networks:
      - backend         # only on the backend network

networks:
  frontend:
  backend:
    internal: true      # no route to the outside world at all

Because web lives only on frontend and db lives only on backend, they have no shared network and literally cannot reach each other. The api bridges both. Marking backend as internal: true goes further: containers on it get no outbound route to the internet, tightening the blast radius if the database were ever compromised.

A couple of useful network options

networks:
  backend:
    driver: bridge
    internal: true        # no external connectivity

  shared_net:
    external: true        # attach to a network created outside this project

services:
  db:
    image: postgres:16
    networks:
      backend:
        aliases:
          - database
          - primary-db

Why Volumes Exist

A container's own filesystem is ephemeral. Anything written inside it lives in a throwaway writable layer that is destroyed when the container is removed. Run a database, docker compose down, then up again with no volume, and every row is gone. Volumes are the mechanism for keeping data that must survive the container.

Named Volumes vs. Bind Mounts

Compose gives you three ways to attach storage. The first two are the ones you'll use daily; the third is a niche tool.

Named volumes — for data that must persist

Docker creates and manages the storage; you refer to it by a name. This is the correct choice for databases and any application data you can't afford to lose.

services:
  db:
    image: postgres:16
    volumes:
      - db_data:/var/lib/postgresql/data   # named volume → survives down/up

volumes:
  db_data:      # declared at the top level so Docker manages it

Bind mounts — for live code and config in development

A bind mount maps a folder on your host straight into the container. Edit a file on your machine and the container sees the change instantly — the foundation of hot-reloading dev setups. It's also how you inject config files.

services:
  api:
    build: ./api
    volumes:
      - ./api:/app                 # your source, live-editable inside the container
      - /app/node_modules          # anonymous volume shields container's deps
  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro   # config, read-only

Read-only and tmpfs

Append :ro to make any mount read-only — ideal for config a container should never modify. For sensitive or purely temporary data that should never touch disk, mount a tmpfs (RAM-backed) volume:

services:
  app:
    image: myapp
    volumes:
      - ./config:/app/config:ro    # read-only
    tmpfs:
      - /tmp                        # in-memory scratch space, wiped on stop

Putting It Together

Here's a stack that uses everything above: an isolated internal backend network, a named volume for Postgres data, a read-only bind mount for the reverse proxy's config, and a bind mount for uploads.

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro   # read-only config
      - ./web/dist:/usr/share/nginx/html:ro              # static build
    networks:
      - frontend
    depends_on:
      - api

  api:
    build: ./api
    expose:
      - "3000"                         # internal only, not published
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/appdb
    volumes:
      - ./uploads:/app/uploads         # bind mount for user uploads
    networks:
      - frontend
      - backend
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - db_data:/var/lib/postgresql/data           # named volume: persistence
      - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql:ro   # seed, read-only
    networks:
      - backend
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d appdb"]
      interval: 5s
      timeout: 5s
      retries: 5

networks:
  frontend:
  backend:
    internal: true          # database is unreachable from outside

volumes:
  db_data:

Troubleshooting

When something can't connect or data goes missing, these commands and checks resolve the vast majority of cases.

# Inspect networks
docker network ls
docker compose exec api getent hosts db     # does "db" resolve?
docker compose exec api ping -c1 db

# Inspect volumes
docker volume ls
docker volume inspect <project>_db_data

# What's mounted into a container?
docker inspect <container> --format '{{ json .Mounts }}'

# Follow logs to see connection errors
docker compose logs -f api

Practice & Quiz

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      - frontend

  api:
    build: ./api
    networks:
      - frontend
      - backend

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - backend

networks:
  frontend:
  backend:
    internal: true

volumes:
  db_data:

Best Practices & Pitfalls

✅ Do

• Let services find each other by service name over the default network
• Use separate networks to isolate tiers; mark backend networks internal: true
• Publish only the ports the host truly needs — omit them on databases
• Use named volumes for any data you can't lose
• Mount config and code read-only (:ro) when the container shouldn't change them
• Back up important volumes; document what each one holds

❌ Don't

• Publish a database port to the host unless you specifically need external access
• Rely on bind mounts for production data — they're host-dependent
• Run docker compose down -v casually — it deletes your named volumes
• Bind-mount your host node_modules over the container's — shield it with an anonymous volume
• Assume publishing a port is required for container-to-container traffic — it isn't

Summary

📚 Additional Resources

• Docker Docs — Networking in Compose
• Docker Docs — Volumes
• Docker Docs — Bind mounts
• Docker Docs — Compose networks reference

🚀 What's Next?

You can now design the connections and storage of a Compose stack with intent. Next we turn Compose into a smooth day-to-day tool: development workflows with Docker — hot reloading, debugging inside containers, and override files that keep dev and production configurations clean.