Reference
How it works
Config generators are easy and mostly worthless: plausible YAML that does not boot is worse than no YAML. Zeroth's product is the verification loop — and because proving a configuration costs real time and credits, that loop runs when you ask for it, not before.
route Pipeline
Steps 01–06 always run and provision nothing. 07 is opt-in.
- 01Safety — admission control: host allowlist (public GitHub/GitLab only), size preflight, private-address refusal.
- 02Ingest — shallow clone (
--depth 1 --single-branch), size re-check. - 03Fingerprint — deterministic rules engine. Facts and evidence only; no source code leaves this stage.
- 04Analyze — the model reasons over facts alone and emits a manifest as JSON.
- 05Deployability verdict — deployable, needs changes, or not deployable, decided from facts. Fatal findings disable the deploy button outright and produce a fix prompt (or an AI-drafted patch, on request — the one step where cited files reach the model). Advisory findings demote it to "deploy anyway".
- 05bValidate — JSON Schema, semantic checks, and platform-constraint checks on the rendered YAML (bind 0.0.0.0, deployFiles present, build/run os match…), local and free. Failure class 1.
- 06Generate — Jinja renders the import YAML and
zerops.yaml; the generator parses its own output before returning it. The run stops here, at ready. - 07Pathfinder — on request only: a real Zerops project is created, deployed, and probed on every route the code declares. On failure the runtime logs feed a diagnosis, the repair lands as a visible diff, and the loop retries. Every transition is persisted, so the run replays as a timeline afterwards. Then a bundle plus
DEPLOYMENT.md.
layers Three failure classes
Each caught at the cheapest level that can catch it.
| Class | Caught at | Cost | Repair |
|---|---|---|---|
| Schema | Local validation | Milliseconds | Model corrects its own JSON |
| Infrastructure | Project import | One API call | Model patches the manifest |
| Runtime | Build / verify | Full build cycle | Model reads logs, patches the manifest |
Catching each at the cheapest level available is what separates a tool from a demo. Schema errors need no provisioning at all — the repair loop is demonstrable even with zero credits.
rocket_launch Where a verification lands
You choose the target when you start a verification run.
Provisioned on Zeroth's own account and destroyed in a finally block on every path. Nothing survives the run.
Provisioned with a token you supply for that one run. A project that came up is kept; failed attempts are still torn down rather than abandoned in your account.
Your token is held only for the run — never written to the database, the logs, or the downloadable
bundle — and each run gets an isolated zcli session, so concurrent runs cannot see each
other's credentials.
dns Zerops services
What Zeroth itself runs on.
| Service | Type | Role |
|---|---|---|
| web | python@3.12 | UI, live run view, gallery |
| api | python@3.12 | Job intake, SSE relay, bundle download |
| worker | python@3.12 | Clone, fingerprint, analyze, deploy, repair |
| db | postgresql@16 | Jobs, attempts, artifacts |
| cache | valkey@7.2 | Job queue, event fan-out, rate limits, concurrency cap |
Only web and api are public. Everything else talks over the private network.
shield Safety
- check Public GitHub/GitLab only, size-capped, private addresses refused.
- check Repository code never executes on the Zeroth worker — only inside the deployment target.
- check Teardown runs in a
finallyblock on every path. - check Global concurrency cap and per-IP rate limit, so a burst of traffic cannot drain credits.
- check No platform secrets are placed in ephemeral project environments.