Docker Compose Connection Inspector
Paste Compose YAML to derive connection addresses from the source, destination, networks, and port mappings.
Docker Compose Connection Inspector
Paste Compose YAML to derive connection addresses from the source, destination, networks, and port mappings.
Read Compose connections from their configuration
Choose the connection origin before choosing a port
A connection from the local Docker host uses the published host port; a connection from another container on a shared network uses the service name and container target port. In the built-in example with different host and container ports, database declares ports: 15432:5432 with no host binding, and api and database share the default network. From api, the candidate is database:5432; from the local Docker host, it is localhost:15432. These addresses follow this example's configuration and are not tested connections.
Check shared networks and the YAML evidence
For connections between different services, the inspector offers a service-name candidate only when both services share a supported network. Inside a container, localhost refers to that container itself. Each result lists configuration paths, such as services.database.ports[0] and the source and destination networks; a manually entered listening port is identified as manual. If the declared networks do not overlap, the result says there is no shared declared network. It does not rule out every other route or test the actual Docker network.
Static inspection with explicit limits
The tool analyzes one Compose YAML document in your browser. It does not start Docker, run curl or test live connections. Input is limited to 1 MiB (1,048,576 UTF-8 bytes), 100 services and 500 combined ports/expose entries. Unresolved variables, port ranges, external networks, network_mode, include and other unsupported configuration produce unsupported or unknown results rather than guesses. The analysis does not establish whether an application is running or listening.
FAQ
Common questions and answers about this topic.
With 15432:5432, should I use 15432 or 5432?
It depends on where the connection starts. In the built-in example, database declares 15432:5432 without a host binding, and api and database share the default network. From the local Docker host, the candidate is localhost:15432 using the published port. From api, it is database:5432 using the service name and container target port. Different bindings or networks can change this result; neither candidate proves connectivity.
Why does localhost fail when I connect to another container?
Inside a container, localhost refers to that container itself, not another service or the Docker host. It can be appropriate when the source and destination are the same container. To reach a different service on a shared supported network, use its service name and container target port, such as database:5432 in the built-in example. The tool identifies this configuration mismatch without testing whether the application accepts a connection.
Does expose publish a host port, and is it required between containers?
expose alone does not publish a port on the host. A ports entry with a fixed published value lets the inspector derive a fixed host candidate. Without that value, the YAML does not establish a fixed host port; Docker may assign one dynamically at runtime, which you can look up with docker compose port. Services on a shared network do not need expose to connect. If no port is declared, enter the TCP listening port you have verified; the tool does not infer it from the image.
What does “No shared declared network” mean?
For the supported configuration model, the source and destination services have no declared network in common, so the inspector cannot offer a direct service-name candidate between them. When services omit networks or use an empty networks collection, Compose uses the default network. A separate result does not prove that every possible route is blocked, and it is not a complete connectivity test. Check the listed network paths and any other explicitly configured route.
Does a matching candidate mean the service is reachable?
No. A match only means that the hostname and port you entered match the candidate derived from the configuration. The tool does not check application startup, listening interfaces or ports, protocol handling, firewalls or authentication. It does not start Docker or make a network request to the service. Confirm those runtime conditions separately before treating the service as reachable.
Why are variables, external networks or include marked unknown or unsupported?
The inspector works with one parsed Compose YAML document and a limited set of ordinary bridge-network and port settings, not every Compose feature. It does not resolve variables, port ranges, include, external networks, profiles or network_mode. Where those settings affect the selected route, it reports unknown or unsupported instead of inventing an address. You can run docker compose config first to resolve variables and consolidate files, then paste the resulting YAML. Runtime dependencies and any remaining unsupported semantics still require separate checks.