The console's `/paas` BFF forwarded to `platform.hanzo.ai/v1/paas/*`. That host
has no such route: the platform Next app's own surface is /v1/apps, /v1/runner,
/v1/git-webhook … and it answers 401 uniformly for EVERY /v1/* path, nonsense
included — so the failure was invisible and the PaaS board could never load.
The PaaS control plane is `/v1/paas/*` on the unified backend:
api.hanzo.ai/v1/paas/health 200 {"crd":true,"k8s":true,"service":"paas"}
api.hanzo.ai/v1/paas/apps 403 (auth required)
api.hanzo.ai/v1/paas/zzz 404 <- a real routing table
platform.hanzo.ai/v1/paas/health 401
platform.hanzo.ai/v1/zzz-nonsense 401 <- auth-first catch-all
So the proxy now reads `CLOUD_API_URL` — the SAME server-side base every other
console BFF route already uses (in-cluster in prod, api.hanzo.ai everywhere
else). It no longer reads PLATFORM_URL, so the stale deploy-time override
pointing at platform.hanzo.ai is inert rather than silently authoritative.
Also repointed the remaining per-service API hosts to the ONE endpoint:
- resource `provisionSnippet` emitted `curl -X POST cloud.hanzo.ai/v1/<kind>`;
a copied snippet now targets api.hanzo.ai (verified routed: /v1/kv → 403
"X-Org-Id required").
- SearchModule's SSR origin fallback, .env.example, README, and the api/train/
tenants/platform-apps doc comments (`api.cloud.hanzo.ai`, `platform.hanzo.ai/v1/*`).
NEXT_PUBLIC_PLATFORM_URL stays: it is a FRONTEND deep-link host, not an API base.
Verified: pnpm typecheck clean; vitest 242 files / 3013 tests pass.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
