7 Docker Compose Patterns Every Devops Engineer Should Know

Docker compose has become one of the most widely used tools for running multi container applications, with a simple YAML file, engineers can spin up multiple containers at once

However, defining the right setup in your compose file is critical to ensure that different containers communicate, how data is persisted, and how the system operates efficiently

This is where docker compose patterns become valuable

In this article, we will explore 7 docker compose patterns that you should know

1. Multi Environment Pattern

In a real world project, development and production environment usually have different requirements

In development, engineers need fast iteration, the ability to rebuild images, and exposed ports for easier access. While production requires stable image, automatic restart and minimal configuration changes.

The Multi Environment Pattern solves this problem by separating common service definitions from environment specific configurations

Instead of maintaining multiple completely different compose files, we create a base docker-compose.yml and extend it with environment specific overrides.

• docker-compose.yml → base
• docker-compose.dev.yml → development
• docker-compose.prod.yml → production

Base Setup

services:
  backend:
    working_dir: /app
    environment:
      NODE_ENV: ${NODE_ENV}
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}

  redis:
    image: redis:8-alpine

This file defines the application architecture without including any environment specific configuration

Development Setup

services:
  backend:
    build: .
    command: npm run dev
    volumes:
      - ./backend:/app
    ports:
      - "3000:3000"

  postgres:
    ports:
      - "5432:5432"

  redis:
    ports:
      - "6379:6379"

In this file we add source code mounting and accessible ports

Production Setup

services:
  backend:
    image: ghcr.io/multienv/backend:latest
    command: npm start
    restart: unless-stopped

  postgres:
    restart: unless-stopped

  redis:
    restart: unless-stopped

Production should use pre-built images and automatic restart

2. Health Check & Dependency Pattern

In a multi container applications, service startup order does not ensure service readiness

For example, if you have appication with backend container and database container, docker may start the backend immediately after starting the database. However, the database might still be initializing and unable to accept connections thus causing startup failure

Health Check & Dependency Pattern solves this problem by allowing containers to verify service availability before starting dependent services

Example

services:
  backend:
    image: node:22-alpine
    working_dir: /app
    volumes:
      - ./backend:/app
    command: node index.js
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
      POSTGRES_DB: app
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "pg_isready -U postgres -d app"
        ]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 20s

The postgres container includes a health check using pg_isready:
pg_isready -U postgres -d app

The backend service uses:

depends_on:
      postgres:
        condition: service_healthy

This tell docker to start the backend only after PostgreSQL reports a healthy status. With this setup we ensure that the right container start at the right time

3. Network Isolation Pattern

For security reasons, not every container should be able to communicate with each other

For example, a database should not be directly accessible from the internet. Only the appropriate services should be allowed to communicate with it

The Network Isolation Pattern improves security by separating containers into different docker networks and controlling container communication

Example

services:
  frontend:
    image: nginx:alpine
    ports:
      - "8080:80"
    networks:
      - frontend-network

  backend:
    image: node:22-alpine
    networks:
      - frontend-network
      - backend-network

  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    networks:
      - backend-network

networks:
  frontend-network:
  backend-network:

This setup creates two isolated networks:

• frontend-network
• backend-network

The frontend container can communicate with the backend because both services share the same network:

frontend:
    networks:
      - frontend-network
backend:
    networks:
      - frontend-network

And the backend container can communicate with the database because both share the same network

backend:
    networks:
      - backend-network

  postgres:
    networks:
      - backend-network

However, the frontend can't be connected to the database because the database container does not include the frontend-network

4. Persistent Volume Pattern

By default containers are not persistent, this means that when a container is removed, all data inside the container filesystem is deleted

This becomes a problem for stateful services such as databases, where data must survive container restarts, updates, or redeployments

The Persistent Volume Pattern solves this problem by storing important data outside the container lifecycle using Docker volumes

Example

services:
  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

The PostgreSQL container stores its database files in:
/var/lib/postgresql/data

Instead of storing this data inside the container, in this setup docker will mount the data in

volumes:
  - postgres-data:/var/lib/postgresql/data

If the container is recreated:
docker compose up -d

Docker attaches the existing volume and postgres can continue using the existing data

5. Resource Limit Pattern

Without proper resource limitation, a single container might consume excessive cpu or memory that can affect other services running on the host

The Resource Limit Pattern prevents this by defining proper limits for containers.

Example

services:
  backend:
    image: node:22-alpine
    working_dir: /app
    volumes:
      - ./backend:/app
    command: node index.js
    mem_limit: 512m
    mem_reservation: 256m
    cpus: 1

In this example we define several config:

• mem_limit: 512m - Defines the maximum memory a container can use
• mem_reservation: 256m - Defines the minimum amount of memory that docker should reserve for the container
• cpus: 1 - Limit the container to use one cpu core

6. Reverse Proxy Gateway Pattern

In production environment, applications are rarely exposed directly to the internet. Instead, traffic is handled by a reverse proxy that acts as a gateway between external users and internal services

The Reverse Proxy Pattern places a proxy server in front of application containers to handle incoming requests, routing, and load balancing

Example

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - backend

  backend:
    image: node:22-alpine
    working_dir: /app
    volumes:
      - ./backend:/app
    command: node index.js

Here we use nginx as our reverse proxy, the nginx container is the only service exposed to the host:

ports:
  - "80:80"

The backend service does not expose any ports because it only needs to communicate internally with nginx.

nginx.conf

events {}

http {
    server {
        listen 80;

        location / {
            proxy_pass http://backend:3000;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

When a user accesses port 80, the request first reaches nginx which forwards the request internally to:
http://backend:3000

7. Secrets Management Pattern

Applications often require sensitive information such as database passwords, API keys, and authentication tokens

A common mistake is storing these credentials directly inside docker-compose.yml:

environment:
  POSTGRES_PASSWORD: password

This creates security risks because secrets can accidentally be exposed through source code repositories, logs, or shared configuration files

The Secrets Management Pattern separates sensitive data from application configuration by using Docker secrets

Example

services:
  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: app
      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
    secrets:
      - postgres_password

secrets:
  postgres_password:
    file: ./postgres_password.txt

Instead of passing the password directly:
POSTGRES_PASSWORD: my-secure-password

Docker mounts the secret as a file inside the container:
/run/secrets/postgres_password

The PostgreSQL image automatically reads the password from this file:
POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password

Docker secrets are useful for small deployments and single-host environments. However, for production systems it is recommended to use a dedicated secret management platform such as hashicorp vault, openbao, or Infisical

Conclusion

Docker compose patterns help devops engineers build container environments that are more secure, reliable, and easier to maintain

By applying these 7 patterns, you can create a more production ready setup

You can find the source code for this article in my github repository:
https://github.com/muhammadyulasfipahrizal/compose-patterns