Deployment patterns

Four ways to put the runtime in the path.

The engine is identical in all four. What changes is where it runs, who operates it, and what your failure domain looks like. Pick by your topology, not by tier.

01Kubernetes services

Sidecar

The runtime runs beside your app in the same pod. Loopback latency, no extra hop on the network, and it scales with your deployment.

Lowest added latency
Per-service isolation
No shared failure domain

02Many apps, one control point

Gateway / proxy

Terminate at Envoy, NGINX, or an LLM proxy and evaluate centrally. One place to change policy for every consumer behind it.

Central enforcement
No app changes
One upgrade path

03Single-service or serverless

In-process library

Link the SDK directly and evaluate in your own process. Nothing else to operate, at the cost of per-language deployment.

No extra container
Cold-start friendly
Per-language builds

04Regulated and classified

Air-gapped

Runtime, sidecar, and control plane all inside the boundary, with policy bundles imported as signed artifacts. No egress at all.

Zero egress
Signed bundle import
Enterprise tier

Choose one

Which pattern fits you

Most teams start as a sidecar and add a gateway later when a second team needs the same policy. Moving between patterns does not change your integration code.

Getting started →

You run on Kubernetes and want the least latency: Sidecar
You have many services and one platform team: Gateway / proxy
You run one service, or serverless functions: In-process library
You cannot allow outbound network egress: Air-gapped
You want central policy but per-service failure isolation: Sidecar + hosted control plane