Docker Port Security: Keep Internal Services Off the Public Internet

Draw the intended connection path

This guide assumes a Linux Docker host and an application reached through a reverse proxy on that same host. Draw which clients should reach the proxy, application and database before editing Compose. If the proxy is in another container, plan an appropriate private container network instead; its localhost is not the host’s localhost. Save the working configuration and identify a restart window for the affected service.

Inventory published ports

Docker’s port-publishing guide explains that a mapping without a host address normally publishes on all host interfaces. Inspect the real mappings and listening ports:

docker ps --format 'table {{.Names}}\t{{.Ports}}'
sudo ss -lntup

Distinguish a container-only service from one mapped to the host. Record IPv4 and IPv6 exposure. Audit old Engine installations against the documented networking caveats, including localhost-publishing behavior in releases older than 28.0.0.

Bind a same-host backend deliberately

In the existing service definition, a ports entry such as this limits the published address to IPv4 loopback:

ports:
  - "127.0.0.1:8080:80"

This is a fragment, not a complete Compose file. Keep the application’s image, volumes, environment and networks intact. Point the same-host proxy at that backend. A database used only on an internal container network generally does not need a published host port. Check its consumers before removing any mapping.

Validate and test both sides

docker compose config --quiet

After configuration validation, recreate the intended service during the agreed window; published-port changes are not a mere application reload. Test proxy-to-application access and, from a separate external machine, verify the backend port is unavailable. Test the public website normally. Docker creates its own firewall rules, so host UFW policy alone is not proof of container isolation.

Record the boundary and rollback

If the proxy fails, restore the saved service mapping and recreate that service while investigating. Keep database backups and persistent volumes untouched during a networking change. Rootless Docker is another control to evaluate for suitable workloads, not a replacement for deliberate network exposure. Use our host firewall guide and secrets guide to review the surrounding deployment.