DEV Community

Cover image for How to Bridge Networks in Docker Compose (`docker-compose.yml`)
Athreya aka Maneshwar
Athreya aka Maneshwar

Posted on • Edited on

How to Bridge Networks in Docker Compose (`docker-compose.yml`)

#devops #webdev #programming

Hello, I'm Maneshwar. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

I'm working on FreeDevTools online currently building **one place for all dev tools, cheat codes, and TLDRs* — a free, open-source hub where developers can quickly find and use tools without any hassle of searching all over the internet.

When running multiple containers in Docker Compos
e, bridging them via a shared network allows them to talk to each other by service name. Here's how to do it right.

What’s a Bridge Network?

A bridge network is the default network driver in Docker. It allows containers to communicate with each other by name.

When you define a custom bridge network in Docker Compose, it:

  • Keeps your containers isolated
  • Lets you define aliases and connect external services
  • Avoids using localhost, which doesn’t work across containers

Setup: A Minimal Example

Let’s say you have a backend (Node.js) and a database (PostgreSQL) and you want them to communicate.

1. docker-compose.yml 

version: '3.9'

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb
    networks:
      - backend

  app:
    build: .
    environment:
      DB_HOST: db
    depends_on:
      - db
    networks:
      - backend

networks:
  backend:
    driver: bridge
Enter fullscreen mode Exit fullscreen mode

Here’s what’s happening:

  • db and app are both connected to the backend bridge network.
  • app can access the database at db:5432.

Connect to External Networks

Want to connect your service to an external Docker network (maybe created outside Compose)? Do this:

networks:
  backend:
    external: true
    name: my-shared-network
Enter fullscreen mode Exit fullscreen mode

Make sure the external network exists:

docker network create --driver bridge my-shared-network
Enter fullscreen mode Exit fullscreen mode

Use Multiple Networks

You can attach services to more than one network:

services:
  app:
    image: my-app
    networks:
      - backend
      - logging
Enter fullscreen mode Exit fullscreen mode

Then define:

networks:
  backend:
    driver: bridge
  logging:
    driver: bridge
Enter fullscreen mode Exit fullscreen mode

Now app can talk to services in both networks.

Useful Commands

  • List networks: docker network ls
  • Inspect a network: docker network inspect <network-name>
  • Remove a network: docker network rm <network-name>

Testing Connectivity

Use Alpine to test:

docker run -it --network=<network-name> alpine sh
apk add curl
curl http://<service-name>:<port>
Enter fullscreen mode Exit fullscreen mode

Gotchas

  • Don’t use localhost to connect to other containers. Use the service name.
  • If two containers aren’t on the same network, they can’t talk.
  • Compose automatically creates a default network if you don’t define one — but it’s best to be explicit.

Conclusion

Docker Compose + custom bridge networks = clean, isolated, and connected environments.

Define your networks clearly in docker-compose.yml, and your services will behave nicely in any environment.

A collection of UI/UX-focused tools crafted to simplify workflows, save time, and reduce friction in searching tools/materials.

Any feedback or contributors are welcome!

It’s online, open-source, and ready for anyone to use.

⭐ Star it on GitHub: freedevtools

Let’s make it even better together.

git-lrc
*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

GitHub logo HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc logo

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit


git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

  • 🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
  • 🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
  • 🔁 Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
  • 🔗 Why git? Git is universal. Every editor, every IDE, every AI…


View on GitHub


Top comments (2)

Collapse
 
dotallio profile image
Dotallio •

Super practical guide! The reminder to avoid localhost and use service names is something I've messed up more times than I want to admit. Do you have any favorite tricks for debugging network issues between containers?

Collapse
 
nathan_tarbert profile image
Nathan Tarbert •

This is extremely impressive. I always end up referencing guides like this when my containers refuse to talk to each other