Stop publishing a host port

`docker compose up` failed with "port is already allocated": 3000 was
taken by an unrelated project on the same machine. Publishing it was
never needed — in production the only thing that has to reach this
service is the reverse proxy, which does so over the compose network as
`landing:3000`.

`expose` replaces `ports`, and a commented `ports` block stays for the
cases that do want a host binding. LANDING_PORT is kept but re-labelled
as only mattering then.

Verified: the container binds nothing on the host, answers 200 with the
full page from another container on the network, and stays healthy —
its health check was always internal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.env.example

@@ -5,8 +5,10 @@
 # the browser never talks to the API directly.
 PIREON_API_URL=https://landing-api.pireon.dev/api
 
-# Host port the container is published on. Change it if something else already
-# holds 3000 on the machine — the container always listens on 3000 internally.
+# Only used if you uncomment `ports` in docker-compose.yml. By default the
+# container is not published on the host at all: the reverse proxy reaches it
+# over the compose network as `landing:3000`, and publishing a host port only
+# invites a collision with whatever else is on that number.
 LANDING_PORT=3000
 
 # Needed only to *build* the image: `@pi/ui` comes from the private Nexus.

README.md

@@ -71,15 +71,20 @@ API were in maintenance. `core/api.ts` gives each call an 8-second budget, which
 is what stands between a slow upstream and a hung render.
 
 The container runs with a read-only filesystem and `no-new-privileges`, with a
-tmpfs at `/tmp` for Nitro's scratch space. Put a reverse proxy in front for TLS
-and let it pass response headers through untouched: the app answers 503 with
+tmpfs at `/tmp` for Nitro's scratch space. The container publishes no host port: the reverse proxy reaches it over the
+compose network as `landing:3000`, and binding a host port only invites a
+collision with whatever else is on that number. `docker-compose.yml` carries a
+commented `ports` block for when you do want one.
+
+Put that proxy in front for TLS and let it pass response headers through
+untouched: the app answers 503 with
 `Retry-After` during maintenance and 404 for addresses it does not serve, and
 both matter to crawlers and CDNs.
 
 | Variable | Where | Default |
 | --- | --- | --- |
 | `PIREON_API_URL` | runtime | `https://landing-api.pireon.dev/api` |
-| `LANDING_PORT` | runtime, host side | `3000` |
+| `LANDING_PORT` | only if you publish a host port | `3000` |
 | `NEXUS_TOKEN` | **build only** | — |
 
 Copy `.env.example` to `.env`; compose reads it.

docker-compose.yml

@@ -24,8 +24,20 @@ services:
         - nexus_token
     image: pireon/landing:latest
     restart: unless-stopped
-    ports:
-      - '${LANDING_PORT:-3000}:3000'
+    # No `ports`. Publishing on the host collides with whatever else is using
+    # that number on the machine, and in production the only thing that needs
+    # to reach this is the reverse proxy — which does so over the compose
+    # network, by service name, on the port below.
+    #
+    #   proxy_pass http://landing:3000;
+    #
+    # To reach it from the host anyway (a quick check, or a deployment with no
+    # proxy in front), uncomment this and set LANDING_PORT to a free port:
+    #
+    # ports:
+    #   - '${LANDING_PORT:-3000}:3000'
+    expose:
+      - '3000'
     environment:
       # Where the public API lives. The only setting the app actually reads.
       PIREON_API_URL: ${PIREON_API_URL:-https://landing-api.pireon.dev/api}