Container ports & host bindings
Publish a port deliberately
Lesson 2 of 20 · 12 min · Module 1: Containers and access
A service listening inside a container is not automatically reachable from the host.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Separate the two port numbers
- Choose who can reach the host binding
The idea
Container operations change instances and their attached configuration. Inspect the resulting state as well as the command sequence.
# Host 9090 forwards to port 3000 in this example.
docker run -d --name demo -p 127.0.0.1:9090:3000 notes:1.0
01Separate the two port numbers
In -p host:container, the left number belongs to the host and the right number is where the application listens inside the container.
02Choose who can reach the host binding
An explicit 127.0.0.1 binding is local to the host. A default 0.0.0.0 binding listens on all IPv4 interfaces and may expose the application more widely.
03Read the mapping back
The lab reports ip, host, and container separately. A mapping of 3000:8080 reverses the requirement, even if both numbers appear in the command.
Your turn
What the checks look for
- API is running
- Loopback 8080 maps to container 3000
Take this with you
A port mapping includes an access boundary as well as two numbers.
Go a little further
Try starting a second container on the same host binding and inspect the conflict.