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

Start notes:1.0 as api. Publish container port 3000 on host port 8080, bound to 127.0.0.1 only. Run detached.

What the checks look for

  • API is running
  • Loopback 8080 maps to container 3000
Try it in the editor →

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.

Learn Docker & Containers for free

20 short lessons with real code and instant checks.

See the whole course →