Deployment models

These docs assume a gateway is already deployed. This page explains the shapes it can take, for context when you operate it.

Hybrid vs. fully self-hosted

• Fully self‑hosted — you run the control plane, data planes, database, and cache entirely within your boundary. Nothing leaves your infrastructure.
• Hybrid — the data plane (and private‑route context) runs in your environment, close to your private upstreams, while sharing a control surface. environment_id is the gateway execution boundary in both cases.

A self‑hosted gateway starts with one configured tenant and a default environment (commonly tenant_local / prod).

Default stack

Layer	Default
Control plane & data plane	Rust
Policy	Cedar
Durable truth & audit metadata	PostgreSQL
Hot session / cache state	Valkey
Eventing	PostgreSQL outbox / internal queue
Observability	OpenTelemetry (customer‑controlled)
Packaging & supply chain	Kubernetes + Helm + Cosign + SBOM
CLI & diagnostics	Go (gatewayctl)

Bootstrapping

A fresh self‑hosted deployment is initialized with the CLI:

gatewayctl bootstrap-self-hosted --help
gatewayctl bootstrap-admin --email you@example.com

Then verify health with Check deployment status.

Note

Backup/restore, upgrade/drain, and offline/restricted installs are operational topics covered in the next documentation wave. Use gatewayctl status and the deployment status guide to confirm a deployment is healthy.