# Antifailure

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

## When to use Antifailure

Use Antifailure when a pull request changes a Postgres-backed application and you need
evidence from a disposable production-shaped environment before merge. It is a fit for
masked database branches, migration lock and rewrite rehearsal, browser workflows,
contained third-party API behavior, and load comparisons against a recorded baseline.

Do not use it as a production database, a general browser automation service, a load
generator against production, or a replacement for unit tests. Start with `af init` in
the repository you want to evaluate; use the control-plane API only when you need shared
organization history or engine ingestion.

Antifailure answers one question: if this pull request merged, what would break? It
answers it by building a disposable copy of the production stack, not by running a
test suite against fixtures.

## The whole thing in four commands, five with a production database

```bash
curl -fsSL https://antifailure.dev/install.sh | sh
af init            # reads your repo, writes antifailure.yaml
af golden refresh  # only if the manifest names a production database: set
                   # that variable first, and this makes the masked copy once
af up              # database branch from the golden, built services, sealed network
af test            # agents run your workflows and return verdicts with evidence
af down            # every resource it created, gone
```

On Windows, install from PowerShell with `irm https://antifailure.dev/install.ps1 | iex`;
the commands after it are the same.

af init writes database.source_url_env only when the repository already names its
production variable. With no source, or once a verified golden for the project exists
on the machine, af up is the next command. af start reports every step as observed on
the machine and names the next one.

The installer puts af under ~/.antifailure and puts that on your PATH by appending
one line to the startup file the login shell reads, printing the line and naming
the file. AF_NO_MODIFY_PATH=1 declines it. The terminal that ran the installer
needs the one line it prints, because a running shell cannot see a file written a
second ago. In GitHub Actions it writes GITHUB_PATH instead and touches no
profile, so a later step finds af without a flag.

## What a run produces

- A masked Postgres branch. Masking is compiled to SQL and executed in resumable
  chunks, deterministic so the same customer maps to the same fake customer across
  every table and every refresh. A scanner then 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, a phone number or a key, and signs an
  attestation that records the sample size it used. An unverified golden cannot be
  branched, and that is enforced in code rather than in a checklist.
- A sealed network. Every environment gets a sidecar that owns its network
  namespace. Each host gets one of seven modes: BLOCK refuses with a readable
  decision, ALLOW passes with a rate limit, SANDBOX swaps in test credentials and
  trips a wire if a live key appears, CAPTURE records mail and SMS into a
  searchable inbox, MOCK answers from a stateful offline pack, EMULATE answers
  from an emulator inside the environment at the provider's own hostname, with no
  endpoint override in your application, and SYNTH asks a model to invent a
  response and marks the result unverified.
- Agent verdicts. Workflows are written as sentences. The runner drives a real
  browser through the accessibility tree, signs in the way a person does, and
  returns pass, fail, flaky, blocked or unverified with a video, a trace and
  reproduction steps. A failure caused by the runner is classified as such and is
  never counted against the application.
- A migration rehearsal. Pending migrations run on a fresh branch with
  per-statement timing and the strongest lock held per table, pg_stat_statements
  diffed between main and the branch, and query plans compared.

## Start here

- [Antifailure: know what happens before you deploy](https://antifailure.dev): What Antifailure is, the four things a run produces, and the commands that produce them.

## Product

- [Product](https://antifailure.dev/product): The four parts of a run: twin, state, containment, judgment. Start here.

## Solutions

- [Solutions](https://antifailure.dev/solutions): Index of the vertical and role pages.
- [B2B SaaS](https://antifailure.dev/solutions/saas): What a twin looks like for multi-tenant B2B SaaS.
- [Fintech](https://antifailure.dev/solutions/fintech): How ledger and billing flows are exercised without touching a real payment network.
- [Marketplaces](https://antifailure.dev/solutions/marketplaces): Testing the orderings a marketplace hits: queues, workers, dual-writes.
- [Developer tools](https://antifailure.dev/solutions/devtools): Why a migration that is instant on a fixture is not instant on a real table.

## Writing

- [Writing](https://antifailure.dev/blog): Index of the writing.
- [Why migration timing changes with your data](https://antifailure.dev/blog/what-staging-misses-about-migrations): How data volume, query plans, and lock duration affect a Postgres migration.
- [Check the data after masking it](https://antifailure.dev/blog/proving-the-masking-worked): How deterministic masking, read-back scanning, and signed attestations prepare data for testing.
- [Choose how external services behave in a test](https://antifailure.dev/blog/five-answers-to-an-outbound-call): Antifailure's seven per-host egress modes and how to choose the right one for an integration.

## Company

- [Pricing](https://antifailure.dev/pricing): What each tier includes and what it costs.
- [Changelog](https://antifailure.dev/changelog): What has changed and when, newest first, built from the repository's own changelog fragments.
- [About](https://antifailure.dev/about): What Antifailure is, how it works, its public status record, and what it does not promise.
- [Contact](https://antifailure.dev/contact): Working routes for private security reports, product issues, questions, documentation, and hosted-product interest.
- [Careers](https://antifailure.dev/careers): Two founding roles, the current compensation stated before the work, and a private application form.

## Legal

- [Privacy Notice](https://antifailure.dev/privacy): The privacy notice.
- [Terms of Use](https://antifailure.dev/terms): The terms of use.
- [Acceptable Use](https://antifailure.dev/acceptable-use): Acceptable use of Antifailure and its hosted services.
- [Developer Policy](https://antifailure.dev/developer-policy): What a token may reach, what a model driving the engine is responsible for, and what may change without notice.

## Elsewhere

- [Documentation](https://antifailure.dev/docs): installation, concepts, guides, provider setup, and the full reference.
- [API reference](https://antifailure.dev/docs/reference/api): hosts, authentication, errors, and endpoint boundaries.
- [OpenAPI 3.1 document](https://antifailure.dev/openapi.json): typed control-plane inputs, response envelopes, permissions, and stable operation IDs.
- [CLI reference](https://antifailure.dev/docs/reference/cli): every af command and option. Install with `curl -fsSL https://antifailure.dev/install.sh | sh`, or on Windows `irm https://antifailure.dev/install.ps1 | iex`.
- [Machine-readable error catalog](https://antifailure.dev/errors.v1.json): error codes, messages, recovery steps, retryability, and exit codes.
- [Full text of the documentation](https://antifailure.dev/docs/llms-full.txt): all 118 documentation pages as one plain-text file. Start here if you are answering a question about how to use Antifailure.
- [Source](https://github.com/antifailure/antifailure): the engine, the runner, the adapters, and the masking catalog.
- [Full text of this site](https://antifailure.dev/llms-full.txt): rendered text from every indexable page above, concatenated for a single fetch.