Quickstart

This goes from nothing to a running environment on your own machine. It needs Docker and a Postgres connection string you are allowed to read from. It does not need an account, a control plane, or a cloud provider: everything here runs locally, and the hosted pieces are optional and come later.

Install

curl -fsSL https://antifailure.dev/install.sh | sh

The installer downloads the release for your platform, checks it against the published checksum, and puts af and its runner under ~/.antifailure. It is POSIX sh rather than bash, so it works in an Alpine container as well as on a laptop. If you would rather read it before running it, it is the same file served at that URL, and the source is in the repository.

Check the machine has what the engine needs:

af doctor

af doctor reports what it found and what it could not, by name. It is worth running first because every problem it names here is one you would otherwise meet halfway through a run.

Describe the repository

af init

Detection reads the repository and writes antifailure.yaml: the services it found, the port each listens on, the migration command, and a network policy derived from the SDKs in your dependency list. If your package.json has stripe in it, the Stripe hosts arrive in the manifest without being asked.

Two things about this worth knowing, because they are deliberate:

It never executes anything from the repository. Detection reads files. A repository that would like to run a script during setup does not get to.

Anything it is unsure about becomes a question rather than a silent guess, and everything it reports names the file it came from. You can answer the questions without a prompt if you are scripting it:

af init --non-interactive

That accepts every default and prints what it assumed, which is the honest version of a silent run.

Read the manifest before going further. It is meant to be audited rather than trusted, and the manifest reference explains every key.

Look at what would happen

af explain

This resolves the manifest and prints the plan: which golden a branch would come from, what each service would build from, and the mode every host in the network policy has been given. Nothing is created. It is the cheapest way to find out that a setting does not mean what you assumed.

Bring an environment up

af up

That builds the services, creates a masked branch of the golden, and starts everything inside a network namespace that reaches nothing except the hosts your policy allows. The first run is the slow one, because the golden has to be built and masked before anything can branch from it. Later runs branch from what already exists.

While it runs, or afterwards:

af status
af logs

Prove the containment

The interesting property is not that the environment came up. It is that it cannot reach anything you did not name.

af net policy

prints the decision for every host the policy knows, and

af net explain https://api.stripe.com/v1/charges

answers for one specific request: which rule matched, which mode it is in, and what would happen. If something reached the network unexpectedly, af net log has the record of it, including the denials.

The modes are covered in egress. The short version is that BLOCK refuses with a decision you can read, SANDBOX swaps in test credentials and trips a wire if a live key ever appears, CAPTURE records mail and messages into an inbox your tests can read, and MOCK answers from an offline pack with no network at all.

Tear it down

af down

Everything it created is removed, and the removal is checked rather than assumed. If a previous run was killed halfway, the journal reconciles it: see the journal for why that matters and af env prune for sweeping up after a machine that lost power.

What to read next

Goldens and masking are the two ideas everything else rests on: how a masked copy of production is built once and branched cheaply, and how identifiers are replaced deterministically so the same customer is the same fake customer in every table and every refresh.

Verification explains why an unverified golden cannot be branched at all, which is enforced in code rather than in a checklist.

Building services covers what happens when detection guessed wrong about how your services are built, which is the most common reason a first af up does not go cleanly.