airlockd — HTTP API, embedded
console, and schema migrations in a single binary — running
from a Compose bundle in deploy/:
airlockd is the only thing that talks to Postgres. airlock publish and
push-ingestion agents ship events to it, decision flagging runs
inside it, and it migrates its own database at startup — there is no SQL to
run, ever.
Start it
http://localhost:4747 with the admin account
configured at deploy time, then manage everything else from the console.
Accounts and tokens
Auth is built in — Airlock’s own user table, no external IdP to stand up:- Users — created by an admin in the console (or
POST /api/v1/admin/users): email, password, and a role,adminoruser. Disable rather than delete; history stays attributed. - CLI identity —
airlock loginonce per machine exchanges email + password for an ingest-scoped token. Sessions and published events carry that identity from then on. - Push-ingestion tokens — an admin mints a named token per external agent
(
"market-resolver-7") reporting decision events. Scoped, revocable, with a last-used time.
Backup
Upgrade
Teardown
Security notes
- No outbound connections. Events come to the backend; it makes no calls out. Postgres is not published outside the compose network.
- A dump leaks no credentials. Tokens and sessions verify against hashes.
- Reads are per-account. Admins see everything,
useraccounts see only their own activity, and every account is revocable — there is no shared read-everything key. - Bind scope. The bundle publishes
airlockdon every interface so laptop-to-laptop demos work. On a network you do not control, bind it to127.0.0.1or front it with your reverse proxy for TLS.