Antifailure
GitHubDocs
Sign inStart free
Product

A disposable production twin that proves whether a deployment is safe.

Connect a repository and a cloud environment. For every risky change, Antifailure builds an isolated production twin, fills it with safe production-shaped state, exercises it, and says whether the deployment is safe to ship.

Start the quickstartRequest hosted access
disposable twin · one run
LIFECYCLE
  1. 1inspect
  2. 2provision
  3. 3restore
  4. 4exercise
  5. 5decide
  6. 6destroy
Inputs
Repository

change + manifest

Cloud

customer boundary

Isolated run boundarytemporary
Candidate

change under test

Safe state

sanitized branch

Workers

declared jobs

Load

journeys + route mix

Side-effect firewall
all egress has an explicit mode
Outputs
Evidence

trace + rows + video

PR gate

pass or fail

Resource journal
every temporary resource recorded
teardown proof
A six-stage disposable twin run: inspect the repository, provision an isolated stack, restore safe state, exercise workflows behind a fail-closed egress boundary, decide, and destroy every journaled resource.

Seven pieces, one decision. None of these is the product on its own.

Twin, state, containment, behavior, judgment, evidence, and cleanup. The output is a pass or a fail on the pull request, and then the environment is destroyed.

  • Twin

    An isolated, temporary copy of the relevant application stack.

  • State

    A safe, referentially consistent, production-shaped dataset.

  • Containment

    No charging cards, emailing users, or invoking production webhooks.

  • Behavior

    Agents driving the workflows you declared, and traffic shaped like production's log.

  • Judgment

    Workflow verdicts, invariants asked of the data, and latency against production's p95.

  • Evidence

    FAIL

    A pass or fail on the pull request, with the rows, the trace and the video behind it.

  • Cleanup

    Destroy temporary resources and prove that cleanup completed.

The question staging cannot answer. What happens when this change meets real data, concurrency, workers, and the deploy process.

Preview tools, test-data platforms, E2E suites, load tests, packet mirrors, and observability each cover one fragment. A disposable twin unifies the minimum set required to validate a real deployment.

staging vs disposable twin
COVERAGE
Dimension
Shared staging

fragmented signals

Disposable twin

one decision path

  1. State volume
    Fixture volume
    Production-shaped subset
  2. Rare records
    No long-tail rows
    Referential rare records
  3. Concurrency
    Quiet concurrency
    Equivalent workload
  4. Isolation
    One shared schema
    A branch per pull request
  5. Egress
    Live Stripe and email
    Fail-closed containment
  6. Decision
    A preview URL
    Pass or fail, with evidence
Closed decision loopPR gate
  1. Safe state
  2. Workload
  3. Containment
  4. Evidence
A six-dimension comparison showing that staging leaves production scale, rare records, concurrency, branch isolation, side-effect containment, and merge judgment fragmented, while a disposable twin closes the loop.
Scope

Postgres migrations first. Not universal multicloud cloning.

Exclusive locks, table rewrites, pool exhaustion, query-plan regressions, and old binaries that cannot read candidate writes. Conventional tests miss all of them. So the first thing built completely is the check for a risky Postgres-backed deployment, rather than a shallow version of everything.

subscriptions · migration rehearsal
LOCK TRACE
Strongest lock observed
ACCESS EXCLUSIVE27.4s
finding
migration tx
ACCESS EXCLUSIVEhold 27.4s
app session
waiting session observed
sampler
250ms
Observation receipt

110 samples · one every 250 milliseconds

release seen
blocked another
yes
table rewrite
yes
plan changed
yes
A sampled Postgres migration trace showing an ACCESS EXCLUSIVE lock held for 27.4 seconds, a waiting application session observed during the hold, and 110 observations taken at 250 millisecond intervals before release.

Example findingOne migration rehearsed, with the numbers chosen. The measurements are the ones af insights takes: the strongest lock mode and its hold time, whether another session was left waiting on it, rewrites, and plans before and after.

af insights · migration rehearsal
EVIDENCE
Deployment judgment
Migration safety report
merge gateFAIL
lock
27.4s
blocked
yes
rewrite
yes
plan
changed
checkevidencestate
strongest lockACCESS EXCLUSIVE 27.4s on subscriptionsblocking evidence
blocked anotheryes, a session was seen waitingblocking evidence
table rewriteyes, reported by Postgressupporting evidence
plan changeIndex Scan to Seq Scan on eventssupporting evidence
Plan delta · eventsregression observed
baseline
Index Scan
relation: events
candidate
Seq Scan
relation: events
rehearsallock samplesreportpull request blocked
A failed migration rehearsal report that records the strongest lock, the blocked session, a table rewrite, a baseline-to-candidate query plan regression, and a concrete lint remediation.

A 27-second lock is a finding. Not a line in a log nobody reads.

The rehearsal runs the pending migrations against a branch with production's shape and samples what is locked every 250 milliseconds. It reports the strongest mode held per table, how long it was held, and whether another session was left waiting on it.

How a run decides

  1. Read the repository

    Detection writes a manifest, names the file every answer came from, and says what it assumed.

  2. Reproduce safely

    Isolated twin, sanitized state, fail-closed egress.

  3. Exercise

    Declared workflows, invariants asked of the data, production's route mix.

  4. Decide

    Pass or fail on the pull request, then destroy the environment.

The output is a decision. Not a dataset. Not a preview URL alone.

  • PASS

    Ship

    Every workflow reached the outcome it declared, and every invariant held.

  • FAIL

    Do not merge

    A workflow failed or an invariant broke. The only verdict that exits non-zero.

  • UNVERIFIED

    We could not tell

    Flaky, blocked or unverified. Something is wrong with the run, and it does not count against you.

What we will not claim

Zero rollback. No deployment can ever fail. Thousands of AI agents behave exactly like humans. One click perfectly clones every cloud. Where a run could not measure something, it says so rather than scoring it.

Questions

What people ask first. Answered here rather than in a sales call.

Does production data leave my infrastructure?
No. The hosted control plane holds organizations, policy, aggregated reports, and billing. Raw snapshots, secrets, and captured request bodies stay in your cloud by default.
How do I know the masking actually worked?
A scanner reads back every column of every table, sampling rows rather than reading all of them, looking for anything that still parses as an email, a card number, a phone number, or a key, then signs an attestation that records the sample size. An unverified golden cannot be branched, and that is enforced in code rather than in a checklist.
What stops a test run from emailing real customers or charging a real card?
Every environment gets a sidecar that owns its network namespace, and nothing leaves except through it. Each host gets one of six modes: BLOCK, ALLOW, SANDBOX with test credentials and a tripwire if a live key appears, CAPTURE into a searchable inbox, MOCK from a stateful offline pack, or SYNTH, which asks a model to invent a response and marks the result unverified. An unlisted host fails closed.
Can a run complete with no network access at all?
Yes, for the covered surface. The Stripe pack is complete enough to run checkout, subscribe, renew, and cancel with signed webhooks and no network.
What happens when a check fails because the tooling broke, not my code?
It is classified as such. A run returns pass, fail, flaky, blocked, or unverified, and a failure caused by the runner is never counted against your application.
Which databases and platforms does it support?
Postgres, sourced from Docker, Neon, Supabase, or DBLab thin clones in front of any Postgres including RDS, Cloud SQL, and Azure Database. It runs locally on Docker, in GitHub Actions, or on your own Kubernetes.
Is it open source?
The repository is MIT licensed except for the ee/ directory, which is under the Antifailure Enterprise License. That directory is never compiled into the community binary, images, or Helm chart.
Is it production ready?
Version 1.0 commits to the manifest schema, the command line, the documented JSON fields, the provider interfaces and the error codes, and breaking any of those costs a major version. It is a promise about interfaces, not a claim that every component is finished: docs/plan/STATUS.md still gives the honest answer per component, marking each one proven, written, or planned.
Keep reading
Next

Know what happens before you deploy.

Create a disposable production twin for every risky change. Catch migration failures before they reach customers.

Start the quickstartRequest hosted access