Antifailure
GitHub
Sign inRequest a demo
Product

See how your change behaves before you deploy.

Connect your coding agent through MCP. Give it an isolated copy of your stack to rehearse migrations, test user journeys, and return evidence before you merge.

Request a demoConnect your agent
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.

A full test environment for each pull request.

  • 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.

Test against the conditions your change will meet.

Bring services, data, and test traffic together in an environment dedicated to your change.

staging vs disposable twin
COVERAGE
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

Rehearse migrations at realistic database sizes.

Inspect lock durations, table rewrites, query plan changes, and compatibility with the previous release.

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 findingExample migration report with sample values.

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.

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.

Know what passed and what needs attention.

  • PASS

    Ship

    The configured checks passed. Review their scope and supporting evidence.

  • FAIL

    Do not merge

    A check found a failure. Review the evidence and reproduction steps.

  • UNVERIFIED

    We could not tell

    The run could not establish an outcome. Review the reason and rerun the affected checks.

Questions

Common questions.

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?
After masking, a scanner samples rows across every table and column for emails, card numbers, phone numbers, and keys. A signed attestation records coverage and findings. Only verified snapshots can be branched.
What stops a test run from emailing real customers or charging a real card?
Outbound traffic goes through a gateway with a policy for each host. Use sandboxes, offline mocks, local emulators, or captured messages for integrations. Unlisted destinations are blocked.
Can a run complete with no network access at all?
Yes. Supported offline mocks include Stripe checkout, subscriptions, renewals, cancellations, and signed webhooks.
What happens when a check fails because the tooling broke, not my code?
The result distinguishes application failures from blocked, flaky, and unverified checks, with a reason to help you decide what to rerun.
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?
The version 1 contract covers the manifest, CLI, documented JSON fields, provider interfaces, and error codes. The stability guide and component status document describe support and verification for each feature.
Next

Bring your next pull request.

See how Antifailure would test your stack, what it would check, and the evidence your team would review before merging.

Request a demoConnect your agent