Skip to main content
Sign In
General

Production Checklist

Checklist for deploying a self-hosted Rivet Engine to production.

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

PostgreSQL is the recommended backend for multi-node self-hosted deployments today, but it remains experimental. For a production-ready single-node Rivet deployment, use the file system backend (RocksDB-based). Enterprise teams can contact enterprise support about FoundationDB for the most scalable production-ready deployment.

Also review the general production checklist.

Security

  • Validate that you have an admin token configured. Generate a strong, random token for engine authentication. See Configuration.
  • Verify your admin token is not exposed publicly. Do not include the admin token in RIVET_PUBLIC_ENDPOINT or anywhere accessible to clients. See Endpoints.
  • Configure TLS termination. Ensure connections to the engine are encrypted via a reverse proxy or load balancer.

Resources

  • Set container resource limits. Recommended at least 1 CPU and 2 GB of RAM per Rivet Engine instance.
  • Configure health checks. Set up liveness and readiness probes on port 6421 at /health. Recommended timeout of 5 seconds.

Scaling

  • Configure autoscaling for the Rivet Engine. Set target CPU utilization to 70% and memory to 80% to ensure headroom for traffic spikes. In Kubernetes, this is configured via a Horizontal Pod Autoscaler (HPA).
  • Use 2+ engine nodes for redundancy. Running a single engine node is a single point of failure. Deploy at least two engine instances behind a load balancer.
  • RocksDB only supports a single node. Do not run multiple RocksDB nodes. For a production-ready single-node Rivet deployment, use the file system backend (RocksDB-based). For multi-node deployments, PostgreSQL is the recommended backend today, though it remains experimental as we evaluate the best fit for scalability and performance.

PostgreSQL

  • PostgreSQL is recommended for multi-node deployments, but remains experimental. Validate the deployment carefully before rollout.
  • Configure automated backups. Set up regular backups for your PostgreSQL database to prevent data loss.
  • Configure failover. Set up a standby replica with automatic failover to ensure high availability.
  • Use FoundationDB for the most scalable production-ready deployments. FoundationDB provides the best performance, scalability, and uptime for Rivet. Contact enterprise support for FoundationDB guidance.

NATS

  • Use NATS for pub/sub (recommended). By default, Rivet uses PostgreSQL LISTEN/NOTIFY for pub/sub which has limited throughput. NATS significantly improves performance for high-traffic deployments. This is not needed if using RocksDB. See Configuration.
  • Deploy 2+ NATS replicas. Run at least two NATS replicas for high availability.

Monitoring

  • Configure OpenTelemetry. The Rivet Engine supports exporting traces and metrics via OpenTelemetry. Set RIVET_OTEL_ENABLED=1 and RIVET_OTEL_GRPC_ENDPOINT to your collector endpoint (defaults to http://localhost:4317). Adjust RIVET_OTEL_SAMPLER_RATIO to control trace sampling (defaults to 0.001). See Configuration.
  • Set up alerts for critical metrics. Monitor engine CPU, memory, request latency, and error rates. Configure alerts to notify your team before issues become outages.

Enterprise

  • Contact enterprise support for production-ready deployments. We can help with architecture review, scaling guidance, and FoundationDB support.
Edit this page