How to Expose Docker Containers to the Internet

What ports: actually does

When you write ports: "8080:80", Docker asks the host's kernel to forward traffic arriving on host port 8080 to port 80 inside the container. The service becomes reachable at the host's own address: localhost:8080 on the machine itself, and something like 192.168.1.50:8080 from a laptop on the same network.

That is the whole extent of it. A published port reaches the host, and through the host it reaches your local network. It does not reach past your router, and no compose setting changes that, because the obstacle is not inside Docker.

Private addresses, and the translation that hides them

Look at the address your machine holds on your network. If it begins 192.168., 10., or 172.16. through 172.31., it is a private address: a range set aside for internal use, which no router on the public internet will carry. Every device on your network has one, and so does every container.

Your router holds the single public address your ISP gave you and lends it to everything behind it, using network address translation, or NAT. When your laptop connects outwards, the router rewrites the packet's source address to its own, notes what it did, and rewrites the replies so they reach the machine that asked.

That works in one direction only. An outbound connection creates its own entry in the router's table as it leaves; an inbound connection from a stranger arrives with no matching entry and nowhere to be sent, so it is discarded. Port forwarding is how you create one of those entries by hand, in advance.

If you are unsure what your connection gives you, the guide to how to get a public IP address covers how to check.

CGNAT, where port forwarding stops being an option

There is a second wall behind the first, and a growing number of people are behind it.

Many ISPs have run out of IPv4 addresses, so they perform the same translation a second time, one level up. Your router's WAN address is then private as well, usually in the 100.64.0.0/10 range, and the real public address is shared between you and many other customers. This is carrier-grade NAT, or CGNAT.

A forwarding rule on your own router now points at traffic that never arrives, because where an inbound connection goes is decided upstream, on equipment you have no access to. You can confirm which situation you are in, and see which ISPs do this, in the guide to self-hosting behind carrier-grade NAT.

Four approaches are worth considering for a compose stack, and everything that survives CGNAT does so for one reason: it is built on a connection your machine makes outwards.

The four compared

The first two columns decide most cases. With a real public address and an unblocked port, forwarding is free and hard to beat; if everything you run speaks HTTP, Cloudflare's tunnel is free and very good at that job. A longer treatment is in GetPublicIP vs Cloudflare Tunnel vs Tailscale.

The four in detail

Which one fits what you are running

A web application and nothing else. Cloudflare Tunnel, unless you would like some privacy and have proper end-to-end encryption.

Only your own devices need access. Tailscale. Nothing public needs to exist at all.

Anything that is not HTTP, or CGNAT plus more than web traffic. Port forwarding if your connection allows it, a dedicated public IP otherwise.

If your stack is not in Docker, the same four apply and are covered in how to expose a home server to the internet.

What this looks like in a compose file

Copyservices:
  web:
    image: nginx:alpine
    restart: unless-stopped

  getpublicip:
    image: ghcr.io/getpublicip/getpublicip:latest
    restart: unless-stopped
    environment:
      GETPUBLICIP_API_KEY: "${GETPUBLICIP_API_KEY}"
      GETPUBLICIP_MAPPINGS: "80/tcp->web:80; 443/tcp->web:443"
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      net.ipv4.ip_forward: 1
      net.ipv4.conf.all.src_valid_mark: 1
      net.ipv6.conf.all.forwarding: 1

Why there are no ports: entries

Look again at web in that file. It publishes nothing. For a guide about exposing containers, that is the part worth slowing down for.

Traffic for your public address arrives inside the agent container, on the tunnel interface. The agent then applies a destination NAT rule: the same class of rule your router applies when you forward a port, running inside the container rather than at the edge of your network. It rewrites the packet's destination from the public address to the container's address on the compose network, and passes it along.

Nothing on that path involves a published host port. The port is open on your public IPv4 address, not on your host and not on your router, so there is nothing new listening for a scan of your home connection to find. Adding a ports: entry to web would only publish it to your local network as well, usually the opposite of what you were arranging.

Destinations are written as service names rather than addresses, because Compose assigns container addresses as it sees fit. The agent re-checks those names every 30 seconds by default, so a container that restarts on a different address keeps working.

What the container needs, and what it does not

Three things, all visible above: the NET_ADMIN capability, so it can configure the tunnel interface and the forwarding rules; the /dev/net/tun device, which is the tunnel itself; and the forwarding sysctls, so traffic arriving on the tunnel can be passed to another container.

It does not need privileged: true. If you find a setup asking for it, something is being worked around rather than configured. It needs no WireGuard kernel module either: the image uses one when the kernel offers it and otherwise falls back to the bundled userspace wireguard-go.

What you get that the tunnels do not

Any protocol, not only HTTP. Forwarding happens at the packet level, so what travels over it is your business. A Minecraft server on UDP, a mail server on 25 and 587, SSH: each is the same kind of mapping as a web server.

An address that is yours. Not a hostname on shared infrastructure. It stays yours if you move the stack to another machine, ISP or country, so DNS records pointing at it survive the move.

Reverse DNS. Because the address is allocated to you, a PTR record can be set for it. Mail deliverability depends on that absolutely, which is what puts mail servers out of reach of the other approaches.

Your TLS stays yours. GetPublicIP forwards packets and never terminates TLS, so no certificates or keys are held on our side. The session is negotiated between your visitor and whichever of your containers terminates it, and is decrypted for the first time there. That service needs a valid certificate of its own, as on any public host.

The things that catch people out

Frequently Asked Questions

Where to go next

If a dedicated public IP suits what you are running, the Docker setup documentation has the complete reference: the full mapping syntax, a working example, IPv6, forwarding to a service on the Docker host, and the per-platform notes.