Local development
Preview URLs, agent addressing, and catalog-backed auth when hacking on Zectre locally.
How the proxy picks a backend (Host → deployment)
zectre-proxy resolves an incoming host in this order (see zectre-proxy cold_start):
deployments.preview_url— canonical match on the first host label; staleroutes.deployment_idmust not override it.- Pinned route — a
routesrow for this domain withdeployment_idset. - Latest route — a
routesrow for this domain withdeployment_idNULL (points at the current app/env). - Legacy app subdomain —
applications.subdomainfallback.
Deploy and API handlers maintain routes and deployment metadata so the proxy’s view stays consistent as rollouts happen.
Agent address_override
The proxy connects to tasks at {node.address}:{task.port}. If the agent advertises an address your proxy cannot reach (common in Docker or multi-NIC setups), set address_override in agent config.
| Setup | Symptom | Fix |
|---|---|---|
| All services on one machine | Proxy tries LAN IP, connection refused | address_override = "127.0.0.1" |
| Proxy in Docker, agent on host | 127.0.0.1 inside container is wrong | host.docker.internal or host LAN IP |
| Agent on VM | Host cannot reach guest IP | Override to an IP reachable from the proxy |
Without a correct override you may see 502 responses, X-Error-Detail mentioning connection failures, or failed health checks.
Catalog + cluster JWT (recap)
- Create DB for catalog; set GitHub OAuth env vars.
- Run catalog migrations (often at startup).
- In platform config
[auth], setcatalog_jwks_url,jwt_expected_iss, andjwt_expected_audto match the catalog and API. - Dashboard: follow
zectre-platform/dashboard/.env.example— catalog mode changes which API base the UI uses (see Dashboard). - CLI:
ZECTRE_CATALOG_URLthenzectre login.
See Auth & catalog for the conceptual map.