Overview
What Exo is, what it owns, and how these docs are organized.
Exo is an opinionated control plane for registering, configuring, deploying, observing, and governing Apps. It is infrastructure, not a general-purpose application generator and not a CMS. Its reusable core is schemas, access controls, provider adapters, provisioning, deployment contracts, evidence, and documentation (architecture).
Exo lives at exo.now. Its shared staging environment is
https://staging.exo.now, and every managed App stages under it at staging.exo.now/{app}.
The product hierarchy
Exo uses five nouns, and each one has a precise meaning:
| Term | Meaning |
|---|---|
| App | Owns persistent runtime state, identity, privileged workflows, releases, and operating responsibility. |
| Page | A routable content unit owned by Construct. Exo sees Pages only as typed resources for grants, routing, deployment evidence, and aggregate policy. |
| Surface | An embedded functional tool that inherits the identity and release boundary of the App or Page that contains it. |
| Component | A reusable implementation or UI unit with no identity responsibility. |
| Organization | Ownership and collaboration. Legacy Payload tenants records are migration input, not a synonym for App. |
Five responsibilities, kept separate
Exo is easiest to understand as five connected responsibilities rather than one large admin panel. They are deliberately separate: a green build is not a deployment, a provider deployment is not a review, and a completed issue is not a Production approval.
| Responsibility | Question it answers | Primary interface | Source of truth |
|---|---|---|---|
| Work | What are we trying to change, and who owns the next action? | Exo portfolio | Exo work item |
| Product | What App, environment, grant, and release state do we manage? | Exo control plane | Convex records and versioned contracts |
| Source | What exact code and agent context produced the result? | Entire | Commit, branch, session, checkpoint, and tag |
| Runtime | What is configured and running now? | Railway or another OCI provider | Live provider state and secrets |
| Evidence | Is the declared version healthy, reviewable, and approved? | Exo portfolio | Provider observations, manifests, checks, and approvals |
What Exo owns, and what it does not
- Exo owns App registration, organizations and access, environments, provider provisioning, deploy/release/rollback state, runtime-dependency metadata, policy and security controls, audit evidence, orchestration, health, and bounded usage and cost aggregates (ADR 0003).
- Construct owns Page and website editing, Puck, publishing, Page authorization, and authenticated Surfaces.
- Independent Apps own their domain records. Exo provisions and observes their resources and accepts only bounded operational observations. It does not centralize their prompts, content, user data, datasets, or financial ledgers.
Platform services
Exo provisions shared services to every App so that Apps skip basic plumbing:
- Exo Key: the single identity provider and OAuth client. Apps are relying parties.
- exo-verify: code verification as a service, with a standard verify contract, sandboxed runs, live staging checks, and AI review.
- exo-analyze: Exo-owned product analytics, from visits through cost to serve.
- exo-deploy: one release path for every surface (web on Railway, mobile on Expo).
- exo-router: Exo's smart model routing, one metered AI egress. Apps never hold provider keys.
How these docs are organized
Tenets
The four principles every decision is checked against.
The stack
Twelve dimensions: platform, boundary, replaceability, cost, and status.
Cost and unit economics
Every cost figure recorded in the ADRs, in one place.
Platform services
Exo Key, exo-verify, exo-analyze, exo-deploy, and exo-router.
How work ships
Canary branch → Staging → Release Candidate → Production.
Decision records
The ADRs, rendered straight from docs/adr.
Roadmap
Rendered from roadmap/items.
Conventions
Every statement here is drawn from the repository: docs/, docs/adr/, roadmap/, and the
code. Each page links to its sources. Anything the repository does not record is marked
TBD, not estimated. When a source document and these pages disagree, the source document
(and the newest accepted ADR) wins, and the page should be fixed.
Source: content/docs/index.mdx