Skip to content
pistra

Deploying pistra

pistra is one binary. Two questions decide everything on this page, and they are independent of each other.

How much of the request path does it own?

Section titled “How much of the request path does it own?”

This is the fork that matters, because it decides what you configure and what you hand over.

  • The front door. pistra owns the listener. It terminates TLS, mints and checks virtual keys, holds the budgets, inspects content and routes to the provider. Everything in the documentation applies. → Deploy the front door with Helm
  • Behind a gateway. The same process with TLS and the listener left to the gateway you already run. There is no second binary and no reduced build. You are declining a job rather than giving up a feature. → the same guide, one section down
  • Beside a gateway. Guardrails only, served over ext_proc to somebody else’s listener. No provider, no credential and no routing decision to make, so it can be deployed into a path you do not own. → Deploy guardrails beside your gateway

Architecture draws all three if none of them is obviously you.

What is it running on?

Section titled “What is it running on?”

This matters less than it looks like it should. The chart and the systemd units install the same binary with the same configuration, and they differ only in how replicas find each other to form one raft cluster.

And one thing that is not a shape

Section titled “And one thing that is not a shape”

If your models are self-hosted, pistra can reach the servers directly rather than sending everything to one address, asking the pool’s endpoint picker which one should take each request. That is a provider setting, not a deployment shape, so it composes with any of the above. → Schedule a pool with an endpoint picker