fix: bind Next.js standalone server to all interfaces for multi-network Docker setups

[octo-patch]

Fixes #1102

Problem

When a container is attached to multiple Docker networks, the Next.js standalone server (server.js) defaults to binding on localhost (127.0.0.1) if HOSTNAME is not explicitly set. This causes the server to be unreachable when the container has multiple network interfaces, since incoming traffic routed through additional networks cannot reach localhost.

This explains why the workaround of joining the extra network post-launch works — the container starts normally on a single network (with Docker's port proxy forwarding to 127.0.0.1:3000), and the extra network attach doesn't interfere with an already-established port binding.

Solution

Add ENV HOSTNAME=0.0.0.0 to both Dockerfile and Dockerfile.slim. This sets the HOSTNAME environment variable that the Next.js standalone server.js reads at startup:

const hostname = process.env.HOSTNAME || 'localhost'

With HOSTNAME=0.0.0.0, the server listens on all network interfaces, making it reachable regardless of how many Docker networks the container is attached to.

Testing

• Start a container with a single Docker network → should work as before
• Start a container with multiple Docker networks → server now reachable on all networks

---

Summary by cubic

Bind the Next.js standalone server to 0.0.0.0 so containers attached to multiple Docker networks are reachable. Fixes #1102 by setting HOSTNAME=0.0.0.0 in Dockerfile and Dockerfile.slim, so server.js listens on all interfaces instead of localhost.

^{Written for commit 0a17400. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

[DevJPM]

If this acts like adding a manual / default environment variable HOSTNAME=0.0.0.0, then yes, this does fix #1102 as I use a manual environment variable as a workaround until this lands :)