Skip to main content
SQLite is the default and it is production-grade on one host. A file, no server, no ops, and the one-effect-once guarantee held by BEGIN IMMEDIATE and a unique constraint across processes rather than merely across threads. Postgres is for many hosts, and that is the whole of the decision: choose by how many machines write to the store, not by how serious you are.

​
What this section answers

​
Where it stands

  • Version 0.6.0, on PyPI, Python 3.11 and later.
  • 3,939 tests, every version specified before it was written and every requirement mutation-tested. Read more.
  • 11 guarantees you can check in your own setup, with ctrlrun verify against your policy, on your store’s backend, in a scratch store it creates. Read more.
  • One host: a file. SQLite, no server, no ops. Many hosts: Postgres, the same guarantees, graded by the same suite. Read more.
  • Soaked for 20m 0s on postgres: 889,735 actions, 0 unattributed ambiguous outcomes, positive control fired. The roadmap asks for a week; that is not met. Read more.
  • Each receipt carries the hash of the one before it, so an alteration is detected and named. Read more.
  • Apache-2.0, and the enforcement kernel stays open source. Releases carry PyPI provenance attestations from GitHub Actions.
Not yet:
  • No soak of the length the roadmap asks for. (the criterion is a week of calendar time; the published run is 20m 0s)
  • No external security audit. (planned for v0.8 or v0.9)
  • No third-party review of the kernel. (every review so far was run inside this project)
  • No sector packs. (the policy templates are starting points, not a product)

​
The shape of a deployment

Authority and policy are evaluated independently and authority runs first, so a denial there never leaves an approval request behind. The store is the only shared state, and it holds eight tables: the effect keys in flight and the continuations holding some of them open, the approvals granted and consumed, the delegations that say who may act, the receipt chain and its head, the event log, and the schema version. Everything else is in your process and dies with it. That is why the questions in this section are all questions about the store.

​
What this does not do

  • It does not run anything for you. There is no daemon, no scheduler and no background thread. Nothing sweeps expired leases, nothing retries on your behalf, and a restarted process repairs nothing. See recovery for why that is deliberate.
  • It does not make an external system idempotent. CTRLRun refuses to knowingly act twice. Whether the remote acted is a fact only the remote holds.
  • It does not roll anything back. It is not a transaction manager and it never pretends a remote write is undone.
  • It is not a dashboard. Receipts are portable JSON; ctrlrun effects, inspect, receipts and stats are the interface, and an OpenTelemetry exporter is the extra.
Verified by T141 and T154 — the three shipped stores run the same store conformance suite, every case a pass or a named not-applicable — and by ctrlrun verify, which grades G1 through G11 against your policy, on your store’s backend, in a scratch store it creates and destroys. It never opens the store you run on.

​
Next

Related topics

Run it in productionFrequently asked questionsThe soak, and what it does not establishCTRLRunRunning on Postgres