Skip to content
Antifailure

The local runtime

Locally, an environment is a set of containers on two Docker networks: an inner one the services share, and an outer one only the egress proxy can reach. A service has no route to the internet except through the proxy, which is what makes the policy an enforced boundary rather than a configuration file.

        ┌──────────── inner network ────────────┐
        │  web    worker    cron    database    │
        └──────────────────┬────────────────────┘
                           │ (the only way out)
                     egress proxy
                           │
                    ┌──────┴──────┐
                  outer network / internet

Everything is labelled with the environment id, so teardown of one environment can never touch another’s.

The daemon

Section titled “The daemon”
AF-RUN-002 The Docker daemon at unix:///var/run/docker.sock could not be
reached.

af doctor checks this and everything else about the machine before you need it, and names the command that fixes each thing it finds.

A service that never becomes ready

Section titled “A service that never becomes ready”
AF-RUN-004 Service web did not become ready within 180s.

Readiness is an HTTP request to health_path, defaulting to /. Any status counts, including 500: readiness means the process is listening and routing, not that the application is healthy. A service answering 500 has started, and reporting it as never having started would send you to the runtime instead of to your own handler.

The usual cause is binding to 127.0.0.1 inside the container, which makes the service unreachable from anywhere including the check. Bind to 0.0.0.0. PORT is set in the environment for you.

For a slow start, raise it:

services:
  - name: web
    health_path: /healthz
    health_timeout: 300s

A service that exits immediately

Section titled “A service that exits immediately”
AF-RUN-005 Service web exited with code 1 during startup.

The last lines of its output come with the error. af logs web has the rest. The most common causes are a missing environment variable and a command that is correct for your shell but not for the image’s.

Ports

Section titled “Ports”
AF-RUN-009 No free port was found in the range 43000 to 43020 to publish the
environment on.

Usually environments that were never torn down. af env list shows them and af env prune --older-than 24h removes the old ones after printing what it would do.

Disk

Section titled “Disk”
AF-RUN-010 Writing to /Users/you/.antifailure failed because the disk is full;
2.0 GiB is required.
AF-RUN-020 Docker has no room left for the environment: no space left on device

af golden gc reclaims goldens nothing branched from, which is usually the larger number with the Docker provider, since each one is an image. docker system prune handles what belongs to Docker rather than to Antifailure.

Two runs at once

Section titled “Two runs at once”
AF-RUN-003 Another Antifailure process holds the lock for this branch (process
4821, since 12:04).

Two af up runs on one branch would race on the same names and both fail in ways neither explains, so the second waits. If the first died without releasing it, af down cleans up.

Related: the journal, egress, building.