Milestone 9 originally planned Caddy as the reverse proxy handling
both static serving and TLS. That's changed: the user has their own
external nginx that will handle SSL/certs and route to this app once
it's exposed beyond the LAN — so this compose stack only needs to
serve the frontend over plain HTTP for now, no TLS layer of its own.
Rewrote frontend/Dockerfile from the old scratch/dist-only build
(meant to hand its output to Caddy) into a self-contained nginx image:
builds the Vite app, then serves it from nginx on port 80. Added
frontend/nginx.conf, which also reverse-proxies /api, /auth, /users,
/ws, and /health to the backend container — necessary because
api/client.ts calls relative paths, so the SPA and API need to appear
as one origin to the browser (same pattern the Vite dev-server proxy
already used, now the production equivalent). The /ws location sets
the Upgrade/Connection headers for the WebSocket handshake and a long
proxy_read_timeout, since DM turns can take well over nginx's 60s
default before the connection sees more traffic.
docker-compose.yml gets a frontend service, port 8080:80.
Verified: docker compose up -d --build frontend; confirmed the built
SPA loads, /api and /health proxy through to the backend (401/200,
not 502), and — the part most likely to break — a real WebSocket
opened successfully through the proxy and a full message round-trip
(send -> persist -> broadcast -> typing -> DM turn) worked end to end
against the containerized stack, not just the Vite dev server.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Thorsten
b75cfb1437