Docker databasesDocker ComposeRedis

Article & Tutorial

Docker Compose Multi-Container App Example: App, Database, Cache and Admin Tool

Build a practical application stack with web service, database, Redis cache, admin console, private networks, environment variables, and persistent volumes.

Docker Compose application with database cache and admin services
Docker Compose application with database cache and admin services
Contents

Docker Compose Multi-Container App Example

This practical guide shows how to run an app, database, cache, and admin tool together using Docker Compose. It explains services, networks, volumes, environment variables, health checks, and common troubleshooting steps.

Example architecture

  • app: Web application container.
  • db: PostgreSQL database.
  • redis: Cache service.
  • adminer: Database admin UI for local development.

compose.yaml example

services: app: build: . ports: - "3000:3000" environment: DATABASE_URL: postgres://appuser:example@db:5432/appdb REDIS_URL: redis://redis:6379 depends_on: - db - redis db: image: postgres:16 environment: POSTGRES_DB: appdb POSTGRES_USER: appuser POSTGRES_PASSWORD: example volumes: - postgres_data:/var/lib/postgresql/data redis: image: redis:7-alpine adminer: image: adminer ports: - "8080:8080" depends_on: - db volumes: postgres_data:

Run the full stack

docker compose up -d docker compose ps docker compose logs -f app

Open services

  • Application:
  • Adminer:

Execute commands inside services

docker compose exec app sh docker compose exec db psql -U appuser -d appdb docker compose exec redis redis-cli ping

Stop and clean up

docker compose down # Remove volumes too, only if you want to delete database data docker compose down -v

Health check idea

healthcheck: test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"] interval: 10s timeout: 5s retries: 5

Common mistakes

  • Using localhost inside containers instead of service names.
  • Not using volumes for database data.
  • Exposing database ports publicly when not needed.
  • Putting production secrets directly in compose files.
  • Assuming startup order means service readiness.

Best practices

  • Use service names for internal communication.
  • Use named volumes for stateful services.
  • Keep development and production Compose files separate.
  • Use health checks for critical dependencies.
  • Document environment variables clearly.

Related Melochip guides

  • Docker Learning Path
  • Docker Compose Beginner Guide
  • Docker Volumes Explained

Official references

  • Docker Compose documentation

Did this help?

Yes No

Join the discussion

0 Comments

Ask questions, add context, or share what worked.

Sign in to join the discussion

No comments yet. Start the discussion.

More from Melochip Editorial

Related articles

Stay in the loop. Get new Melochip articles

Receive Melochip article updates when new articles are available. Explicit opt-in only.

No pre-checked boxes. Unsubscribe support is part of the subscriber foundation.