Keel, the Runtime Under the Work
The Plumbing Kept Returning
Several engineering applications I work on need the same unglamorous machinery. They have durable state, work that must be supervised and cancelled, live values that move quickly, artifacts that must survive the run, and extensions that should not receive the keys to the building.
The first time, writing that machinery inside the product feels reasonable. The third time, the similarities become difficult to ignore. Keel is the shared Rust runtime that came out of that repetition.
A Small Set of Strong Mechanisms
A Keel application opens a World, builds one Runtime, and hands cheap Handle values to the product code. Transactions and projections own state changes and reads. Records and subscriptions provide a durable journal. Watches carry the latest live state. Jobs and runs own supervised work. Streams hold high-rate typed rows, while artifacts keep the binary outputs those jobs produce.
Plugins can run as Wasm guests or sidecars. They operate through explicit grants and a scoped context rather than reaching into runtime internals. Applications register their own capabilities visibly, so the composition remains something a maintainer can read instead of an automatic discovery trick performed at startup.
A Keel, Not the Whole Boat
The name is a useful boundary. Keel is not a user interface, a distributed workflow engine, or a database wearing a nicer jacket. It sits under applications such as Dokime and gives them a stable line through the mechanisms they share. Product concepts stay in the product.
Keel is pre-1.0 and still makes clean API and storage-format breaks. That is deliberate while the public surface settles, even if it occasionally makes a dependent repository grumble. The aim is a narrow substrate that can carry serious applications without becoming the application itself. If it is doing its job, most users will never know it is there.