Communication Between Multiple Docker-Compose Projects

Docker Compose is a powerful tool for defining and running multi-container Docker applications. But what happens when you have multiple docker-compose projects and they need to talk to each other?

By default, Docker Compose projects are isolated — containers from one project can’t access containers from another. In this blog post, we’ll explore how to enable communication between separate Docker Compose projects in a secure and maintainable way.

Table of Contents

🚧 Problem: Projects Are Isolated

Let’s say you have two separate projects:

Project A (docker-compose.yml):
- Runs a web app on webapp container
Project B (docker-compose.yml):
- Runs a database on db container

By default, containers in Project A cannot resolve or access services in Project B because each Compose project creates its own Docker network.

✅ Solution: Use a Shared Docker Network

The cleanest and most maintainable solution is to create a custom Docker network that both projects can join.

🔧 Step-by-Step Guide

1. Create a shared external network

docker network create shared-network

This network will be used by both Compose projects.

2. Reference the network in both `docker-compose.yml` files

Project A docker-compose.yml:

version: '3.8'
services:
  webapp:
    image: my-webapp
    networks:
      - shared

networks:
  shared:
    external: true
    name: shared-network

Project B docker-compose.yml:

version: '3.8'
services:
  db:
    image: postgres
    networks:
      - shared

networks:
  shared:
    external: true
    name: shared-network

📌 Important: Both projects use the same external network name.

3. Use container names as hostnames

Inside webapp, you can now access db:5432 directly:

psql -h db -U user -d mydb

Docker handles the DNS resolution automatically since both containers share a network.

🧪 Verifying Connectivity

Run each Compose project independently:

cd project-a && docker-compose up -d
cd project-b && docker-compose up -d

Then docker exec into one container and ping the other:

docker exec -it project-a_webapp_1 ping db

You should see successful pings!

🧠 Alternate: Use Docker’s Default Bridge (Not Recommended)

You can technically run containers with the default bridge network and expose ports to the host, then communicate over localhost:<port>. But this:

Doesn’t scale well
Exposes ports unnecessarily
Bypasses Docker’s internal DNS

✅ Prefer named networks for internal container-to-container communication.

📌 Best Practices

Practice	Why
Use named external networks	Enables clean cross-project communication
Avoid using `localhost` between containers	Doesn’t refer to host or other containers
Use service/container names as hostnames	Docker DNS simplifies connection logic
Scope networks clearly	Avoid naming conflicts between environments

🧭 Summary

To communicate between multiple Docker Compose projects:

Create a shared external network
Configure both Compose files to use that network
Use service names to connect across containers

This approach maintains separation of concerns while allowing controlled communication — great for microservices, modular systems, or complex development setups.