fix(api,auth)!: bind loopback by default, and let a container ask for more

Both servers bound `0.0.0.0`. That was harmless while the only deployment was
docker-compose.yml, which publishes these ports on 127.0.0.1 and makes the
container's own bind irrelevant. As ordinary processes on a rented machine
there is no such wrapper, and `0.0.0.0` is a listener on the internet — in
front of an issuer that sets cookies without `Secure` and mints sign-in codes,
because it expects something else to be terminating TLS.

So the default is `127.0.0.1` and `HOST` is there for the deployment that
genuinely needs every interface. compose now sets `HOST: 0.0.0.0` explicitly,
which is not a workaround: inside a container, binding loopback is what would
make the published port unreachable. The right answer differs by deployment,
which is why it is a variable rather than a constant.

Both now log the address they bound, not the one they hoped for.

BREAKING CHANGE: api and auth no longer listen on every interface by default.
A deployment that relied on that must set HOST=0.0.0.0.

apps/api/app/server.ts

@@ -14,9 +14,23 @@ import handler, { type ApiEnv } from './index.js';
 
 const port = Number(process.env.PORT ?? 3000);
 
+// Loopback by default, and that is a security setting rather than a
+// convenience. Under a Cloudflare Tunnel nothing reaches this process except
+// `cloudflared` on the same machine, and this address is half of what makes
+// that true -- the machine's firewall is the other half.
+//
+// It was `0.0.0.0` until 2026-09-16, which was harmless while the only
+// deployment was `docker-compose.yml`, because that publishes these ports on
+// `127.0.0.1` and the container's own bind never mattered. As an ordinary
+// process there is no such wrapper: `0.0.0.0` is a public listener.
+//
+// `HOST` exists for the deployment that genuinely wants one -- a container,
+// where binding loopback would make the port unpublishable.
+const hostname = process.env.HOST ?? '127.0.0.1';
+
 Bun.serve({
 	port,
-	hostname: '0.0.0.0',
+	hostname,
 	// A Worker runtime hands the handler a context whose `waitUntil` keeps the
 	// invocation alive past the response. A process does not need convincing to
 	// stay alive, so the equivalent is to let the promise run — with a catch,
@@ -37,4 +51,4 @@ Bun.serve({
 		)
 });
 
-console.log(`[api] listening on http://0.0.0.0:${port}`);
+console.log(`[api] listening on http://${hostname}:${port}`);

apps/auth/src/server.ts

@@ -16,9 +16,25 @@ import handler from './index.js';
 
 const port = Number(process.env.PORT ?? 1337);
 
+// Loopback by default, and that is a security setting rather than a
+// convenience. Under a Cloudflare Tunnel nothing reaches this process except
+// `cloudflared` on the same machine, and this address is half of what makes
+// that true -- the machine's firewall is the other half.
+//
+// It was `0.0.0.0` until 2026-09-16, which was harmless while the only
+// deployment was `docker-compose.yml`, because that publishes these ports on
+// `127.0.0.1` and the container's own bind never mattered. As an ordinary
+// process there is no such wrapper: `0.0.0.0` is a public listener, and this one
+// issues sign-in codes and sets cookies without `Secure`, because it expects
+// something in front of it to be the thing terminating TLS.
+//
+// `HOST` exists for the deployment that genuinely wants one -- a container,
+// where binding loopback would make the port unpublishable.
+const hostname = process.env.HOST ?? '127.0.0.1';
+
 Bun.serve({
 	port,
-	hostname: '0.0.0.0',
+	hostname,
 	// A Worker runtime hands the handler a context whose `waitUntil` keeps the
 	// invocation alive past the response. A process does not need convincing to
 	// stay alive, so the equivalent is to let the promise run — with a catch,
@@ -39,4 +55,4 @@ Bun.serve({
 		)
 });
 
-console.log(`[auth] listening on http://0.0.0.0:${port}`);
+console.log(`[auth] listening on http://${hostname}:${port}`);