> ## Documentation Index > Fetch the complete documentation index at: https://docs.ctrlrun.dev/llms.txt > Use this file to discover all available pages before exploring further. # Run it in production > SQLite is the default and is production-grade on one host. Postgres is for many hosts. What survives a crash, and what you do yourself. **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 | If you are asking | Read | | -------------------------------------------------------------- | ---------------------------------------------------------- | | Which store, and what does each cost me? | [SQLite or Postgres](/production/postgres) | | What happens when the database write is lost mid-`COMMIT`? | [How reservation works](/production/how-reservation-works) | | What happens when I deploy a new version over an old database? | [Migrations](/production/migrations) | | The process died holding a key. Now what? | [Recovery after a crash](/production/recovery) | | Somebody edited a receipt. Would I know? | [Receipt integrity](/production/receipt-integrity) | | Has this been run under load? | [The soak](/production/soak) | | What do I watch, and what do I page on? | [Operations](/production/operations) | ## Where it stands * **Version 0.6.0 is in development**; [PyPI](https://pypi.org/project/ctrlrun/) has 0.5.0. Python 3.11 and later. * **3,941 tests**, every version specified before it was written and every requirement mutation-tested. [Read more](/how-this-is-built). * **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](/security/verify-guarantees). * **One host: a file.** SQLite, no server, no ops. **Many hosts: Postgres**, the same guarantees, graded by the same suite. [Read more](/production/postgres). * **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](/production/soak). * **Each receipt carries the hash of the one before it**, so an alteration is detected and named. [Read more](/production/receipt-integrity). * **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 ``` your process ──► @protect / gateway ──► principal ──► authority ──► policy ──► approval │ reservation ◄────────┘ │ executor │ the store: a file, or Postgres, shared across hosts effects · continuations · approvals · delegations receipts · receipt_chain · events · schema_version ``` 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](/production/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 * [SQLite or Postgres](/production/postgres): the choice, and what each one costs. * [How reservation works](/production/how-reservation-works): the lost `COMMIT`, in two rows. * [Get started](/get-started/quickstart) · [Why](/why). ## Related topics - [Run it in production](/production/index.md) - [Frequently asked questions](/faq.md) - [The soak, and what it does not establish](/production/soak.md) - [CTRLRun](/index.md) - [Running on Postgres](/postgres.md)