Deployment requirements

pistra does a lot, and none of it is free to operate. Saying that honestly takes a price list rather than a feature list. The list names what each capability adds, and what a node has to have, a process, a directory, an identity provider, three machines, before that capability is real. This page is that list, in the order a deployment usually takes the rungs on. Nothing on a higher rung is required by a lower one, and a file that stops at the first rung is a complete gateway, not a demo of one.

The shapes are the other fork, and the two are independent. A front door, a node behind a gateway and an inspector beside one climb the same ladder. Where a rung’s cost changes with the shape, the table says so.

rung	adds	requires	guides
Run	a listener in front of your traffic, the providers behind it, and a request passed through byte for byte	one process, a node file and a deployment document, one directory for its log	Govern your first provider, Deploy the front door with Helm, Run the front door on VMs, Add a custom provider, Add a provider with a catalog overlay, Schedule a pool with an endpoint picker, Watch the gateway
Govern	virtual keys, team profiles, budgets, CEL access rules, a signed audit trail, and a configuration you write through an API	nothing more than the node already runs, plus an admin door on it, either the local socket or a loopback listener	Mint, rotate and revoke a virtual key, Give a team its own policy, Cap what a team spends, Test your rules before they ship, Audit your metering against the provider, Query the gateway’s state, Suspend a key, provider or rule, Verify the audit trail, Ship the audit trail to your SIEM, Manage the configuration through the API, Manage the deployment with Terraform, Store a secret through the API
Inspect	PII, secret and identifier detection on the pattern tier, redaction and restore, guardrail rules over what was found	nothing more. and beside a gateway it needs that gateway’s ext_proc	Guard traffic you don’t route, Deploy guardrails beside your gateway, Redact PII from model output, Run a slow detector off the request path, Run a detector in shadow mode, Exempt placeholders from a credential rule, Add your own recognizer, Find Gulf identifiers, Start from a control pack, Write a control pack, Measure a detector
Identify	tokens from your identity provider on both planes, the agent and the user in every rule, admin roles from claims, sign-in from the command line, and a credential exchanged per caller at an MCP server or agent	an identity provider you administer, and a Cedar policy file for the admin plane	Connect your identity provider, Sign in from the command line, Restrict what an admin caller can do, Authenticate agents with your identity provider, Reach the admin API without your identity provider, Connect your AI governance platform
Replicate	several nodes holding one log, a control plane that survives a node, snapshots, and a cluster secret that rotates	three nodes in three failure domains, a shared secret, a volume each	Back up and restore the cluster, Recover a cluster that has lost quorum, Rotate the cluster secret, Spread a cluster across zones
Front peers	MCP servers and A2A agents behind the same keys, rules, budgets and guardrails, each agent’s card projected at the gateway’s address, and a private MCP registry	a public_url, for the cards and the resource metadata a client asks for	Front a peer agent, Serve a private MCP registry
Model detectors	names in any script, prompt injection, topics, and a model as judge	ONNX Runtime and the tokenizer shim on the node, or a remote analyzer, plus a cache directory for the models	Detect names with a model from the HuggingFace Hub, Stop prompt injection with a classifier, Keep the assistant on topic with examples, Judge with a model

How to read the table

Adds says what the rung is for. Requires names what you sign up to operate: not what the guide says to type, but what has to exist and keep existing for the guide’s result to keep working. A rung whose requirement is “nothing more” is turned on by writing a block into the file, and turned off by deleting it.

Every tutorial and how-to guide sits on exactly one rung, and the test that generates this table fails when one does not. That is the discipline. A guide cannot be written without saying what it costs, and a cost cannot be quietly moved.

The same ladder, at the command line

pistra check -config reads a file the way the gateway does and prints one line per thing it names, the cluster, the admin door, each provider, each issuer, each fronted server, the native libraries. The output is the ladder as one file climbs it. A -- line is a rung the file did not take. A FAIL is a rung it took and cannot stand on from this machine.

The console reads the same list. A page whose block the deployment has not written shows the rung it belongs to, what the rung requires and the guide to start from, in place of an empty table.

Where the ladder stops

Kubernetes is not a rung. The charts, the operator and the inspector beside a gateway are ways to run the rungs above, and each shape’s guide says what the shape itself costs. The website’s list of integrations is not a rung either. A governance platform or a SIEM reads what the Govern rung already produces.