How it works
01 /
Read current state before deciding
Review evaluation refetches GitHub state instead of trusting a stale webhook snapshot. D1 work leases and Check Run reservations coordinate concurrent Worker invocations. The merge command also reserves each comment before attempting the action.
02 /
Put long work in a queue
Artifact work is separate from review gate checks. Folder transfers run through cron or the operator path; claims are counted even when execution ends without a result. An expired lease makes abandoned work reclaimable, and repeated failed claims eventually produce publication_failed rather than an endless retry loop.
03 /
Provide a recovery path
Scheduled reconciliation refreshes repositories and rulesets and retries failed webhook deliveries within GitHub’s delivery window. Bearer-protected operator endpoints expose aggregate health, effective permissions, reconciliation and artifact processing. Release evaluation can be triggered for a named repository.
A concrete example
Workflow example
GET /v1/health
GET /v1/permissions
POST /v1/reconcile
POST /v1/artifacts/process
POST /v1/release/evaluate
# Operator authentication is required for every endpoint.Know the boundary
Current limits
Retries are not a universal exactly-once guarantee across every external API. Operations still need bounded attempts, error reporting and attention when upstream permissions or configuration are broken. These protected endpoints belong to the existing toolkit, not a public Runnerless management API.
Common questions
Do folder uploads run inside the webhook response window?
No. Folder jobs use the queued cron/operator work path.
Can anyone trigger reconciliation from the public website?
No. The operator API requires its own bearer credential, which is never supplied by the marketing site.
Runnerless / early access
Want this in
your workflow?
Get early access ↗Register interest and tell us what slows your CI down. The optional follow-up questions come after your email is saved.