infra: bind development services to loopback

[Karniej]

What changed

Bind the development Compose stack's published PostgreSQL, Redis, Adminer, Keycloak, MinIO, and Prometheus ports to 127.0.0.1.

Why

Docker publishes a host port on every interface when no host address is specified. Running the development stack on a remote workstation or VPS therefore exposes its infrastructure services to that machine's public networks. Loopback bindings retain host-local development access and Docker's internal buzz-net connectivity without making those services Internet-reachable.

Impact

Local workflows continue using the same ports. Deliberate remote administration now requires an SSH tunnel or another trusted private-network path.

Validation

• docker compose -f docker-compose.yml config --quiet
• Recreated the six affected services with their existing named volumes and Docker network
• PostgreSQL remained healthy and retained all 54 application tables
• Redis, MinIO, and Prometheus health checks passed
• All affected ports were closed on the host's public IPv4 and IPv6 addresses while remaining available on loopback

Origin: buzz://message?channel=199eb7bc-3feb-484f-ae0e-4995123721ea&id=1c5bc387e86e21bb31677f56e1c862d4d9a17943bce91f8d93e825d029ce7f72

[Chessing234]

loopback bind for compose/dev services is the right default. worth a one-liner in the compose README so people who were hitting the old 0.0.0.0 ports from another machine know to publish explicitly.

[wesbillman]

Reviewed on Wes's behalf at head 3fdebd66a5bf70a07017f05f281f811f74ecc0b6.

No blocking findings. This is a desirable, low-risk hardening change rather than a production networking redesign:

• The root docker-compose.yml is explicitly documented as the day-to-day development stack; the single-node/VPS deployment is separately maintained under deploy/compose/ (README.md:178).
• The current short port syntax publishes PostgreSQL, Redis, Adminer, Keycloak, MinIO, and Prometheus on all host interfaces despite development/default credentials. Binding those host publications to loopback removes a real exposure on remote workstations, cloud VMs, and shared networks.
• Container-to-container traffic remains on buzz-net, and repository CI/application workflows address these services through Docker DNS or localhost, so the normal local-development path is preserved.
• The intended compatibility break is limited to clients on another machine reaching the development infrastructure ports directly. Those users will need an SSH tunnel or an explicit Compose override; that is the safer default.

I searched the repository documentation and workflows for a documented remote-development/LAN workflow that depends on direct access to these root-Compose ports and found none. I also found no GitHub issue specifically requesting the change, so demonstrated demand is limited rather than broad: the security footgun itself, this PR's Buzz-origin link, contributor support, and a maintainer approval. That is sufficient for a secure-by-default development configuration, but a short documentation note about explicit remote overrides would be useful and should not block the fix.

The head is mergeable and current checks are green or intentionally path-skipped. Recommendation: merge.

[wesbillman]

Approved on Wes's behalf at head 3fdebd66a5bf70a07017f05f281f811f74ecc0b6.

The root development stack hardening is correct and should not be delayed to expand scope. docker-compose.harness.yml has the same default-credential/all-interface exposure on ports 5471, 6471, 9471, and 9472; that isolated harness documents and consumes only localhost, so it should receive equivalent loopback bindings in a separate follow-up. The production/VPS and benchmark Compose overlays have different intended exposure and should be evaluated independently rather than swept into this PR.