A proving ground for changes that deserve more than staging.
Antifailure is an open-core project for pre-production testing and release safety. It builds disposable, production-shaped environments so a team can inspect evidence before a risky change reaches production.
Production shape, contained effects, and a result you can inspect. The evidence matters more than the claim.
Antifailure builds a disposable copy of your production stack for every pull request. It branches a masked, referentially consistent Postgres from a verified golden, builds your services and then runs them inside a sandbox that cannot reach the internet except where you say it can, drives real workflows with agents that use the accessibility tree the way a person does, and rehearses pending migrations for exclusive locks, table rewrites and query plan regressions before any of it reaches production.
The category is stated narrowly: Pre-production testing and release safety for teams that deploy to Postgres. Antifailure is not a replacement for every test suite, database tool, or preview platform. It combines those concerns when a release needs a production-shaped rehearsal and an explicit record of what the environment did and did not reproduce.
The implementation, plans, and known limits are public in the source repository. Installation and operating details live in the documentation.
One run, four accountable stages. Each stage leaves evidence for the next.
Build a disposable twin
The change gets a temporary copy of the application stack instead of sharing a long-lived staging environment.
Prepare verified state
Postgres data is masked inside the customer boundary, scanned, and attested before an environment can use it.
Contain and exercise
Egress policy controls external effects while deterministic workflows and exploratory agents use the running application.
Report and remove
The run returns evidence and a verdict, then cleanup removes the resources it created and records the outcome.
Inspectable where trust matters.
The repository is MIT licensed except for the separately licensed ee/ directory. The community build excludes that directory rather than hiding it behind a runtime switch. The customer-side engine, masking, containment, and cleanup paths remain inspectable where they handle sensitive state.
See the open-core license boundary and the control-plane architecture.
Evidence, not certainty.
A passing run describes behavior under the fidelity it reached. It does not promise that no deployment can fail, that every cloud can be cloned perfectly, or that open source replaces compliance. Those limits are part of the product definition, not footnotes added after a result.
Read the terms and stated limits or the release-security model.
Know what happens before you deploy.
Create a disposable production twin for every risky change. Catch migration failures before they reach customers.