Control Plane

Production Checklist

Checklist for putting a self-hosted control plane into production.

We recommend passing this page to your coding agent to verify your configuration before deploying.

Security

Configure an admin token. Generate a strong random value and set RIVET__AUTH__ADMIN_TOKEN. Without one the API is unauthenticated. See Configuration.
Keep the admin token out of client reach. It must never appear in a public endpoint or anywhere a browser can read it.
Terminate TLS. Every connection to the control plane should be encrypted at a reverse proxy or load balancer. See TLS.

Set container resource requests and limits. The shipped Kubernetes manifests request 2 CPU and 2 GB per control plane instance, with limits of 3 CPU and 4 GB. Size other platforms to match; 1 CPU is enough only for a quiet single-node deployment.
Configure health checks. Liveness and readiness probes against /health on port 6421, with a five second timeout. See Ports.
Raise load balancer idle timeouts to 3600 seconds. Long-lived WebSockets are dropped by the 30 to 60 second defaults, which causes reconnect storms. This is the most common self-hosting mistake. See Ports.

Run two or more nodes. A single control plane node is a single point of failure. Deploy at least two behind a load balancer.
Do not run multiple file system nodes. RocksDB is single-node. Multi-node deployments need PostgreSQL or FoundationDB. See Storage.
Configure autoscaling, on a shared backend only. Target 60% CPU and 80% memory to leave headroom for traffic spikes. In Kubernetes this is a Horizontal Pod Autoscaler, and the shipped manifests include one at 2 to 10 replicas with a 15 minute scale-down stabilization window. Memory is a backstop rather than a scaling signal: it does not fall as fast as CPU, so scaling in needs to wait it out. Never autoscale a node on the file system backend: adding replicas to a single-node RocksDB deployment corrupts it.
Check the rate limit on your serverless worker platform. Actor start requests all originate from your control plane nodes, so they come from a small set of IPs. Per-IP rate limits throttle the control plane long before they would throttle end-user traffic. Size the limit to your peak actor create and wake rate.

Choose the backend that matches your node count. File system for a single node, PostgreSQL for multi-node up to roughly 1,000 concurrent actors, FoundationDB beyond that. See Storage.
Configure automated backups, and restore one into a scratch environment to prove the path works. See Backup & Restore.
Configure failover. A standby replica with automatic failover, for PostgreSQL.
Deploy two or more NATS replicas for multi-node pub/sub high availability.

Pin the image tag. Never run latest in production. See Upgrades.
Configure OpenTelemetry. Set RIVET_OTEL_ENABLED=1 and point RIVET_OTEL_GRPC_ENDPOINT at your collector. Tune RIVET_OTEL_SAMPLER_RATIO for trace volume.
Set up alerts. CPU, memory, request latency, and error rates, with thresholds that fire before an outage rather than during one.

Contact enterprise support for architecture review, scaling guidance, and FoundationDB.