feat(deploy): derive the API origin from the page, not from a pinned env var

The browser hard-required API_ORIGIN, so every move of the server — tailnet today, the 192.168.1.0 office LAN later, a temporary demo domain in between — meant editing the deploy env and redeploying. Worse, an http:// API origin on a page served over TLS is blocked outright as mixed active content, which is what broke the demo on https://jorgecuadros.freakma.com. The browser now derives the origin from window.location the way a PHP app would: same host on port 3001 over plain HTTP, or the same-origin /api path under https (the reverse proxy strips the prefix). API_ORIGIN survives as an optional override for a deployment that genuinely splits the two hosts, and SSR still reads process.env because a derived origin is browser-only. WEB_ORIGIN becomes a comma-separated list to match: one deployment is now reached under several origins, and a credentialed fetch from an unlisted one gets no CORS headers and fails. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 12:55:32 -07:00
parent 5352d49ecf
commit 14c6183aa2
4 changed files with 44 additions and 18 deletions
@@ -132,8 +132,12 @@ services:
    dns_search:
      - ${TAILNET_SUFFIX:-tail01aa2.ts.net}
    environment:
-      # Public API URL the browser calls (injected at runtime, see layout.tsx).
-      API_ORIGIN: ${API_ORIGIN:?API_ORIGIN must be set}
+      # OPTIONAL override of the API URL the browser calls (injected at runtime,
+      # see layout.tsx). Leave it unset: the browser then derives the origin
+      # from the page it loaded — same host on port 3001 over plain HTTP, or
+      # /api behind a TLS-terminating proxy. Set it only when the API really
+      # lives on a different host than the web app.
+      API_ORIGIN: ${API_ORIGIN:-}
    ports:
      - "${WEB_PORT:-3000}:3000"
    depends_on: