docker-compose.yml and docker-compose.prod.yml defaulted API_HOST/LIVE_WS_HOST/
HOSTNAME to 0.0.0.0 and published the dashboard/API/live-WS ports with bare,
unscoped specs, which Docker expands to every interface. Combined with
REQUIRE_API_KEY=false shipping as the .env.example default, this exposed the
anonymous /v1 LLM proxy to the whole LAN/WAN (#12568). The optional cliproxyapi
sidecar had the same unscoped publish spec plus no forwarded auth env var,
exposing a credential-bearing service the same way (#12578); qdrant and bifrost
had the identical gap.
Applies the existing Redis loopback-bind precedent (tests/unit/compose-redis-
loopback-bind.test.ts) to the app's own ports and to cliproxyapi/qdrant/bifrost:
- New APP_BIND_HOST / CLIPROXY_BIND_HOST / QDRANT_BIND_HOST / BIFROST_BIND_HOST
opt-in vars, defaulting to 127.0.0.1, documented in .env.example and
docs/reference/ENVIRONMENT.md.
- API_HOST/LIVE_WS_HOST default to 127.0.0.1 in both compose files; the prod
file no longer hardcodes HOSTNAME=0.0.0.0.
- cliproxyapi now forwards CLIPROXYAPI_MANAGEMENT_KEY as MANAGEMENT_PASSWORD,
the one env var the pinned image actually reads for its management API.
- A new boot-time guard (src/lib/startup/nonLoopbackApiKeyGuard.ts) logs a
warning — never a hard failure — when the API bridge or live-WS server ends
up bound to a non-loopback host while REQUIRE_API_KEY is disabled.
⚠️ base-red inherited: #12732 — unit #12058, integration codex-cache,
package-artifact, tarball-smoke, agent-skills-sync
Closes#12568Closes#12578
