Security

Branches are sealed copies with their own credentials, on infrastructure you own. Your data never leaves your machines.

Minimal production footprint

anybranch reads from production over the engine’s replication and never writes to your application tables. On Postgres it adds only its own publication, slot, metadata schema, and DDL event trigger, all named anybranch_<name>, and rm removes them. On MySQL and MongoDB it creates nothing on the source.

Per-branch credentials

Roots that anybranch creates get a generated admin password, and every clone rotates to its own password on first start — so a branch URL never opens its parent. Postgres accepts the password over TCP and trusts only its Unix socket (which anybranch itself uses); MongoDB runs with a keyFile and a generated root user. A leaked branch URL has no path to production and no shared credential. This is what makes it safe to hand a branch to a coding agent.

Server token

The control API is guarded by a single admin token (ANYBRANCH_TOKEN) presented as Authorization: Bearer. There is no tenancy: anyone with the token is an admin. Keep it in a secret store, put the server behind your network boundary or a TLS terminator, and rotate by restarting with a new value.

Anonymization

Use a per-root branch_sql hook to redact or synthesize sensitive columns on every new branch. It runs once per branch, right after creation, and never touches the source. See Settings.

WAL retention

A stopped Postgres synced root keeps its replication slot, which retains WAL on the source until the root is started again or removed. status shows how much WAL the slot is holding. Preflight warns when max_slot_wal_keep_size is unbounded — set a bound so a forgotten root cannot fill the source’s disk.