---
title: "Production Checklist"
description: "Checklist for deploying a self-hosted Rivet Engine to production."
skill: true
---

<Tip>
We recommend passing this page to your coding agent to verify your configuration before deploying.
</Tip>

<Warning>
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](https://rivet.dev/sales) about FoundationDB for the most scalable production-ready deployment.
</Warning>

Also review the [general production checklist](/docs/general/production-checklist).

## Security

- **Validate that you have an admin token configured.** Generate a strong, random token for engine authentication. See [Configuration](/docs/self-hosting/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](/docs/general/endpoints#public-endpoint).
- **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.
- **Validate the rate limit on your serverless actor host.** Actor start requests are sent from your engine instances, so they all originate from a small set of IPs. Per-IP rate limits on the actor host will throttle the engine before they would throttle end-user traffic. Size the limit to your peak actor create and wake rate, and configure platform max concurrency (e.g. on GCP Cloud Run) to match your expected concurrent actor count.

## 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](https://rivet.dev/sales) 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](/docs/self-hosting/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](/docs/self-hosting/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](https://rivet.dev/sales) for production-ready deployments.** We can help with architecture review, scaling guidance, and FoundationDB support.
