How to Set Up a Dedicated Docker Network for Reverse-Proxy Backends

Attach the reverse proxy and each HTTP backend to one shared user-defined network; keep databases on private app networks.

Publishing every backend port to the NAS host is unnecessary when the proxy can resolve Compose service names on a user-defined bridge. A two-network pattern gives the proxy a controlled path to web backends while databases remain reachable only by their applications. Define network ownership, avoid ambiguous aliases, decide which services require outbound access, and verify that host ports stay closed.

Draw the Intended Reachability Matrix

List every connection: client to proxy, proxy to backend, backend to database, backend to external APIs, and administrator to maintenance endpoints. Mark protocol, port, DNS name, and whether the path crosses the host.

Only the reverse proxy should normally publish ports 80 and 443. Backends expose their application port to the Docker network without a host ports mapping. Databases join only the app-private network unless an explicit administration path is required.

Choose stable, unique service names or network aliases. Docker DNS resolves services on shared user-defined networks, but generic aliases such as web can collide when many Compose projects attach to the same proxy network.

Create a Shared Proxy Network and Private App Network

Create the proxy network once, mark it external in each application project, and attach the proxy plus the intended backend. This keeps network identity stable when an individual Compose project is recreated.

Define a separate default or named private network for each app and attach its backend and database. The backend becomes the controlled bridge between proxy traffic and private state; the proxy should not join the database network.

The Compose network definitions documents external networks and service attachment in Compose. Treat an external network as lifecycle-owned outside the app stack: deployment must check that it exists instead of assuming Compose will create or delete it.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Remove Unnecessary Host Ports and Review Egress

After the proxy route works, remove backend host-port publications. The expose declaration can document the container port but is not a firewall; network membership determines which containers can connect.

Consider internal: true only for networks whose members genuinely need no external route. Backends that call identity providers, webhooks, package services, or remote APIs may fail on an internal-only network. Use a second egress-capable network when the application design requires it.

Protect the Docker socket used for automatic proxy discovery. A read-only bind mount reduces accidental writes but does not make the socket harmless; a constrained socket proxy or static configuration provides a narrower control surface.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verify Service DNS, Port Exposure, and Isolation

From the proxy container, resolve the backend service name and request its health endpoint on the container port. From an unrelated container, confirm the name or connection is unavailable unless that container is intentionally on the proxy network.

Scan the NAS host from another LAN device and confirm only the proxy ports are open. Then test TLS, forwarded headers, WebSocket upgrades, large uploads, and application redirects through the public hostname. The home server service map should record the proxy network as part of the home server's service map.

Rollback by restoring the previous port mapping only for diagnosis, not as a permanent hidden dependency. Stop if the proxy needs direct database access, aliases route to the wrong project, or removing a host port breaks an undocumented integration.

FAQ 

Is an external Docker network automatically more secure?

No. External describes lifecycle ownership, not security. Every attached container can generally communicate according to the network driver and host firewall behavior.

Should backend services still declare expose?

It is optional for connectivity on a user-defined network, but it can document the intended container port. It does not publish the port to the host.

Can the proxy network be marked internal?

Only if the proxy and routing design still have the required inbound and outbound paths. An internal network blocks normal external connectivity for attached containers and may break certificate or identity flows.

Why use service names instead of container IP addresses?

Container addresses can change after recreation. Docker's service discovery provides a stable name within the shared network, which makes proxy configuration more durable.

restore the saved baseline, apply the approved configuration once, repeat the original production-like workload, verify the promised success signal, and then exercise the documented rollback. Do not close the change until logs, timing, permissions, capacity, and recovered output all match the acceptance criteria.