Production Checklist

Checklist for deploying Rivet Actors to production.

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. See 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. See Errors.

Runtime Mode

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

Serverless

• Check platform timeouts. Rivet handles migration between invocations automatically, but shorter timeouts increase migration frequency. See Timeouts.
• Configure max runners. Go to Settings > Providers > Edit Provider > Max Runners to set the limit. The default is 100,000 runners. This is effectively your max actor count.

Runner

• Set a graceful shutdown period of at least 130 seconds. Runners need time to drain actors during upgrades. In Kubernetes, set terminationGracePeriodSeconds: 130 on the pod spec.

Actors

Design Patterns

• Do not use god actors. Avoid putting all logic into a single actor type. See Design Patterns.
• Do not use actor-per-request patterns. Avoid creating a new actor for each request. See Design Patterns.

Lifecycle

• Do not rely on onSleep for critical cleanup. onSleep is not called during crashes or forced terminations. See Lifecycle.

State

• Verify c.state does not grow unbounded. Avoid using arrays or objects that grow over time in state. Use SQLite for unbounded or append-heavy data instead.
• Verify actor data does not exceed 10 GB. Contact enterprise support if you need more storage.
• Use input parameters and createState for actor initialization. See Input Parameters.

Events

• Use conn.send() instead of c.broadcast() for private events. c.broadcast() sends to all connected clients. Use conn.send() to send events to a specific connection. See Realtime.

Actions

• Review action timeout configuration. The default actionTimeout is 60 seconds. Increase it if you have long-running actions like API calls or file processing. See Actor Configuration.
• Review message size limits. The default maxIncomingMessageSize is 64 KiB and maxOutgoingMessageSize is 1 MiB. Increase if your actors send or receive large JSON payloads. See Registry Configuration.

Queues

• Review queue limits. The default maxQueueSize is 1,000 messages and maxQueueMessageSize is 64 KiB. Increase if you expect burst traffic or large queue payloads. See Actor Configuration.
• Ensure queue handlers are idempotent. If processing fails before message.complete(), the message will be retried. See Queues.

Workflows

• Verify workflows do not generate infinite steps. Use ctx.loop to avoid creating unbounded step histories. See Workflows.

Security

Authentication

• Validate connections in createConnState or onBeforeConnect. Do not trust client input without validation. See Authentication.

CORS

• Configure CORS for production. Restrict allowed origins instead of allowing all. See CORS.

Tokens (Rivet Cloud)

• Use pk_* tokens for RIVET_PUBLIC_ENDPOINT. Public tokens are safe to expose to clients.
• Use sk_* tokens for RIVET_ENDPOINT. Secret tokens should only be used server-side.
• Do not leak your secret token. Never expose sk_* tokens in client-side code, public repositories, or browser environments. See Endpoints.
• Verify you’re connecting to the correct region. Use the nearest datacenter endpoint (e.g. api-us-west-1.rivet.dev) for lowest latency.

Access Control

Access control is only needed if you want granular permissions for different clients. For most use cases, basic authentication in onBeforeConnect or createConnState is sufficient.

• Use deny-by-default rules. Reject unknown roles in onBeforeConnect, action handlers, canPublish, and canSubscribe. See Access Control.
• Authorize actions explicitly. Check the caller’s role in each action handler and throw forbidden for unauthorized access.
• Gate event subscriptions and queue publishes. Use canSubscribe and canPublish hooks to restrict which clients can subscribe to events or publish to queues.

Clients

• Dispose connections and/or client when not in use (JavaScript client). Call conn.dispose() or client.dispose() when no longer needed to free resources. React and SwiftUI clients handle this automatically. See Connection Lifecycle.