open beta · static + server-rendered · free

Deploys that fixthemselves.

Connect a repo. AutoDeploy detects how to build it, runs it in a sandbox, repairs the failures it understands, validates the result — and shows you every decision it made.

Connect GitHub

TS2322 → AI patch → rebuilt & validated → approved → live

Recorded on the local stack; the AI step uses the deterministic mock provider.

free · no credit card · rules first, AI only when needed

acme/shop ▸ main @ 9f3c2a15 stages · 1 recovery
  1. Analyze
    vite · pnpm · node 22
    running
  2. Build
    pnpm build
    queued
  3. Recover
    rule R-004 · node engine
    queued
  4. Validate
    chromium · 0 errors
    queued
  5. Live
    shop.autodeploy.fyi
    queued
recent deploys
  • adminbuild failed · escalated2m
  • bloglive38s
  • docsai patch · approval1m
  • shopauto-fixed41s

01 · build

Most of a deploy is waiting.

So every build streams to you live: queued with fair scheduling, built in a sandbox with no network except the package registry, validated in a real browser before anyone sees it.

  1. ✓Analyze
  2. ✓Queue
  3. ✓Build
  4. ✓Validate
  5. ✓Live
shop ▸ deploy #128 ▸ attempt 1 · node 22 · sandbox
$pnpm install --frozen-lockfile
 Packages: +412
 Progress: resolved 412, reused 380, downloaded 32
$vite build
 vite v7.3.6 building for production…
 ✓ 214 modules transformed.
 dist/index.html            0.46 kB │ gzip: 0.30 kB
 dist/assets/index-Bgopu29T.js  142.18 kB │ gzip: 45.71 kB
 ✓ built in 1.82s
▸validating in headless Chromium… 200 OK, 0 errors
▸live at shop.autodeploy.fyi
docs ▸ #131 ▸ attempt 1● Build failedLive
src/Header.tsx(14,31):
error TS2339: Property 'user' does not exist on type 'Props'.
signature TS_COMPILE:3fa91c · no rule matches → AI diagnosis
The prop was renamed to `account` in Props, but Header still reads `user`.
src/Header.tsx · +1 −1
- <Avatar user={props.user} />
+ <Avatar user={props.account} />
✓ scope✓ size✓ no secrets✓ rebuilt + validated⚠ awaiting your approval

02 · recover

Failures, handled.

Known failures are fixed by deterministic rules in seconds — wrong Node version, wrong output folder, stale lockfile. The rest go to a model that proposes the smallest patch, which is policy-checked, rebuilt in a fresh sandbox and validated before you ever see it. Nothing touches your main branch without you.

03 · release

Every deploy is on the record.

Builds are content-addressed and immutable. Going live — or going back — moves one pointer at the edge. No rebuild, no downtime, no guessing which files are served.

#124
#125
#126
#127
#128

rollback #128 → #127 · 3.7 ms · nothing rebuilt

04 · proof

Numbers we measured.

Not projections. Each figure comes from a test or a run you can reproduce from the repository.

duplicate job claims
0
500 jobs raced by 8 workers (integration test)
failures auto-recovered
82%
38-repo failure corpus · 64% by rules alone · 0 false fixes
worker killed → rebuild
36s
SIGKILL mid-build; lease expiry + reaper (chaos test)
rollback
3.7ms
pointer flip under an advisory lock, nothing rebuilt

05 · system

Under the hood.

Jobs live in Postgres, where leases and retries belong. Events fan out through Kafka to independent consumers. Static files are served from the edge; server-rendered apps wake on demand in sandboxed containers.

  1. 01GitHubA push or pull request arrives as a webhook.
  2. 02APIFastify checks it and records the deployment and its job in one transaction.
  3. 03PostgresHolds the job queue and every state change; events fan out to Kafka.
  4. 04WorkerClaims the job under a lease and builds in a gVisor sandbox.
  5. 05AI gatewayWhen rules can’t fix a failure, proposes a patch for a person to approve.
  6. 06EdgeServes the result from Cloudflare: files from B2, server apps on demand.

Ship something broken.

We'll tell you why — and most of the time, fix it before you notice.

Connect GitHubRead the architecture