Docker and Compose
Docker Compose networking explained
Use service-name DNS, intentional published ports and separate networks to connect Compose services safely.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Inside a Compose network, call the dependency by service name and container port. Publish a host port only when traffic must enter from outside Docker; localhost inside a container refers to that same container, not its neighbour or the host.
What this means in plain English
Compose normally creates a private network where services can find each other by service name. A web container can call db on the database’s internal port. Inside a container, localhost means that same container—it does not mean another service or the host computer.
Publish a port only when something outside Docker must reach it. A public website may publish the reverse proxy’s web ports, while its database and cache stay private. Fewer published ports means fewer services exposed by mistake.
Which address should one service call?
| Container-to-container | service-name:container-port |
|---|---|
| Host-to-container | published-host-port |
| Isolation | Attach services only to networks they need |
A simple example
The app connects to mysql:3306 inside the Compose network. The database does not publish 3306 to the internet. A reverse proxy publishes ports 80 and 443 and sends web requests to app:8080. Each address describes the path that actually needs to exist.
What to do, step by step
1. Draw each required traffic path.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on container-to-container: service-name:container-port. Write the result down so you can compare it later.
2. Remove published database/cache ports unless externally needed.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Use service names in application configuration.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test name resolution and firewall exposure.
Finish by checking the result against isolation: attach services only to networks they need. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Never save a container’s current IP address in configuration. Docker can give it a different address after replacement; the service name is designed to remain useful.
Common mistakes and how to avoid them
Using localhost for another service.
This gives a misleading or unsafe result because it leaves out container-to-container. A better approach is to draw each required traffic path, then check the result before making the change permanent.
Publishing every container port.
This gives a misleading or unsafe result because it leaves out host-to-container. A better approach is to remove published database/cache ports unless externally needed, then check the result before making the change permanent.
Hard-coding container IP addresses.
This gives a misleading or unsafe result because it leaves out isolation. A better approach is to use service names in application configuration, then check the result before making the change permanent.
Words explained
- container
- A packaged, isolated way to run an application with the files and software it needs.
- Compose
- Docker Compose is a file-based way to describe several containers, their settings, storage and networks as one application.
Quick checklist
- Draw each required traffic path.
- Remove published database/cache ports unless externally needed.
- Use service names in application configuration.
- Test name resolution and firewall exposure.
Common questions
What is the simple answer?
Inside a Compose network, call the dependency by service name and container port. Publish a host port only when traffic must enter from outside Docker; localhost inside a container refers to that same container, not its neighbour or the host.
What should I check first?
Start with container-to-container: service-name:container-port. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Draw each required traffic path. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Using localhost for another service. Avoiding that one mistake makes the rest of the comparison much more trustworthy.