Skip to main content
Sign In
Workers

Production Checklist

Deploy-time configuration to check before you put workers in production.

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

Split by runtime mode, because the two halves barely overlap. A reader on a serverless platform can skip the runner section entirely.

Environment

  • Set NODE_ENV=production. Ensures optimized performance and disables development-only behavior.
  • Ensure log level is not set to debug. Leave RIVET_LOG_LEVEL at its default or explicitly set it to warn to avoid excessive logging.
  • Do not set RIVET_EXPOSE_ERRORS=1 in production. This exposes internal error details to clients. It is automatically enabled when NODE_ENV=development.

Runtime Mode

  • Configure a runner version. Required for graceful upgrades and draining of old actors. Applies to both serverless and runner modes.

Serverless

  • Check platform timeouts. Rivet handles migration between invocations automatically, but shorter timeouts increase migration frequency.
  • Verify /api/rivet/start body size limits. Serverless actor starts carry actor config and preloaded KV or SQLite startup data in the request body. Keep serverless.maxStartPayloadBytes and your platform or proxy body limit at 16 MiB or higher, or lower the preload budget if your platform cannot accept that size.
  • Configure the concurrent actor ceiling. maxConcurrentActors caps how many actors the pool will run, and defaults to 1000. In the dashboard it is still surfaced as Settings > Providers > Edit Provider > Max Runners, a deprecated name for the same limit; RivetKit-configured pools set it to 100,000. Raise or lower it to match the capacity you actually want to pay for.
  • Verify your platform rate limit accommodates your actor create and wake frequency. Actor start requests are sent from Rivet’s servers, so they all originate from the same IP. Per-IP rate limits will throttle the control plane well before they would throttle real end-user traffic. Size your platform’s rate limit to your peak actor create and wake rate, not your end-user request rate.
  • Set the per-instance max concurrent actor limit. Each serverless instance hosts one actor per in-flight /api/rivet/start request, so your platform’s per-instance concurrency (e.g. GCP Cloud Run --concurrency, AWS Lambda reserved concurrency, Vercel maxDuration + concurrency) directly caps actors per instance. Pick a value based on per-actor memory and CPU; the platform autoscales out additional instances once existing ones hit the cap.
  • Tune requestLifespan to your platform’s hard request timeout. requestLifespan (default 3600, 60 minutes) is the total lifespan of each serverless request before actors migrate to a fresh instance. Set it just below your platform’s hard timeout (e.g. 295 for Vercel Hobby, 3595 for Vercel Pro, 840 for Cloud Run’s 15-min cap). Configure it through your registry configuration.
  • Set drainGracePeriod whenever requestLifespan is short. It is the time reserved at the end of requestLifespan for actors to stop gracefully before the request is forcibly closed, and it defaults to 1800 (30 minutes), which is also its maximum. The control plane rejects any config where drainGracePeriod is not strictly less than requestLifespan, so every lifespan under 30 minutes must set it explicitly. Lower it for short-lived stateless actors, raise it if your actors do non-trivial cleanup or final SQLite writes. Configure it through your registry configuration.

Runner

  • Set a graceful shutdown period of at least 35 minutes. Runners need up to 30 minutes to drain actors during upgrades, plus buffer for shutdown overhead. In Kubernetes, set terminationGracePeriodSeconds: 2100 on the pod spec.

Next steps

Application design guidance (actor sizing, state growth, queue limits, CORS) stays in the product documentation. It is advice you need before writing the actor, not before shipping it.

Edit this page