> Canonical: https://antifailure.dev/product > The twin, the state inside it, the containment around it, and the judgment it returns on a pull request. # 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. - 1 inspect - 2 provision - 3 restore - 4 exercise - 5 decide - 6 destroy change + manifest customer boundary change under test sanitized branch declared jobs journeys + route mix trace + rows + video pass or fail 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. fragmented signals one decision path - State volume Fixture volume ✓ Production-shaped subset - Rare records No long-tail rows ✓ Referential rare records - Concurrency Quiet concurrency ✓ Equivalent workload - Isolation One shared schema ✓ A branch per pull request - Egress Live Stripe and email ✓ Fail-closed containment - Decision A preview URL ✓ Pass or fail, with evidence - Safe state → - Workload → - Containment → - 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. ## 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. 110 samples · one every 250 milliseconds **blocked another** yes **table rewrite** **plan changed** 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 finding One 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. **lock** 27.4s **blocked** **rewrite** **plan** changed Add a second column of the new type, backfill it, then drop the old one. 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. - Read the repository Detection writes a manifest, names the file every answer came from, and says what it assumed. - Reproduce safely Isolated twin, sanitized state, fail-closed egress. - Exercise Declared workflows, invariants asked of the data, production's route mix. - 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. 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. ## 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. - Isolated Twin How the orchestrator provisions and tears down. Read - Migration Safety Locks, rewrites and plans, before it ships. Read - Docs How a twin run works, end to end. Read ## Know what happens before you deploy. Create a disposable production twin for every risky change. Catch migration failures before they reach customers.