Site lifecycle
A site is the unit of isolation for the static product: one frontend origin set, one rate limit, one knowledge namespace, one site token, and one Relay URL. Operators manage sites through admin API routes authenticated with ARCFLOW_ADMIN_API_KEY.
1. Create site
Example response:
The site_token is shown once. Store it in a secret manager or password vault. Do not commit to git.
2. Embed in frontend
Inject at build time (Vite example):
Use CI secret stores (GitHub Actions secrets, Doppler, etc.) for production tokens.
3. Read site configuration
Returns origins, rate limit, defaults. Token hash is not reversible; you cannot retrieve the plain token again.
4. Update origins and limits
When launching a staging domain or changing traffic expectations:
Relay enforces updated origins on the next request (when site store is synced). BYO Relay JSON configs require redeploy.
5. Rotate token
If a token leaks or an employee with access leaves:
Response includes a new site_token. Update all frontend deployments. Old token stops working immediately.
6. Decommission
Archive site by revoking token, removing origins, and unpublishing workflows as needed. Postgres rows remain for audit unless operational policy deletes them.
Checklist
| Step | Done when |
|---|---|
| Site created | site_id and relay_url recorded |
| Token stored securely | Not in repo |
| Origins match deploy URLs | Relay 403 tests pass |
| Knowledge ingested | RAG answers cite KB (see knowledge guide) |
| Chat workflow published | runPublished("chat", "^1.0.0",...) succeeds |
| Smoke script green | scripts/static-smoke.sh or manual curl |
Related pages
- knowledge-and-publish.md
- relay/origin-and-rate-limiting.md
- static-product/security-model.md
- Dashboard spec Admin API reference (ArcFlow repository)