Sixteen guides, grouped by what you came for: how to install it, where to start, how the stack is secured, the practice of running agents, and what changed in October. Each service has its own guide too, listed beside its room on the Stack page.
On a Debian or Ubuntu box you own, on a Kubernetes cluster, or as a sandbox on your laptop. It comes up closed, checks itself, and adds the rest when you ask.
Every service is its own repository with its own releases. How each one ships, whether it runs alone, and where its install command lives.
One command on a box you own, one agent pointed at it, one address to write to, and then make it fire on purpose. Four steps, what each is for, and where each one goes wrong.
What a measurement on this stack actually established, the limit published beside each one, three conclusions we withdrew, and the list of what nobody has established yet.
One machine, a five-node cluster, or a hyperscaler. Six clusters measured across three clouds and then destroyed: how each performed, the storage line that differs by a factor of 108, and a published conclusion we had to withdraw.
The eight figures on the home page: how each was measured on real infrastructure, the bugs the live runs caught, and where the rest of the record is.
Read the guideWhy every control sits where an agent cannot talk to it.
Read the guideThe damage does not arrive as a sentence, it arrives as a tool call. Eight failure modes a fleet actually hits, the control that answers each, and what to rehearse in CI so a broken guardrail fails a build rather than an incident review.
A tool used to be code you shipped. Over the Model Context Protocol it is a description you fetched, from a server that can change it after you approved it. Six failure modes, and the control that answers each.
A static key answers one question, badly. What an identity has to be instead, nameable, attributable, attestable and revocable, plus delegation chains, when to demand a signature per action, and how to evaluate anything in this space.
Governance is the set of controls that decide what an agent may do while it is doing it. Every question a fleet has to answer at runtime with the tool that owns it, the five decisions every governed team ends up making, and the order to adopt them in.
Cloud FinOps assumes somebody provisioned the thing. Agent spend appears when an agent decides to try again. What breaks, what to instrument first, and how to report it in a format finance already reads.
One explains what happened, the other decides what may happen. The same incident seen by each, why the control alone is opaque, and the single integration decision that makes them meet: one run id.
Twelve controls that answer before a call: what each one does, what it does not do yet, and how to check it, one at a time.
A hub that holds the control plane and the policy, and a gateway at every site that reaches it over outbound HTTPS through one narrow door. One script on the hub, one command per site, four variables at the site, and what the runs showed.
One ordinary failure, an agent stuck in a retry loop, followed from its first over-budget call to the evidence an auditor reads months later. Eight steps, the event each one writes, and what only becomes visible in that order.
Every control the guides describe has an Apache-2.0 service behind it, and they run on infrastructure you own. Walk the stack, or start the live services locally in one command and watch the money plane light up. Unfamiliar term? The glossary defines the vocabulary these guides use.