Rivet Actors

Build high-performance, long-lived, in-memory processes on Rivet's actor runtime. Use this skill whenever HTTP endpoints, databases, or queues no longer meet the requirements for AI agents, realtime collaboration, workflow orchestration, or geo-distributed data.

What To Do If You Get Stuck

If something is not working as intended or you are stuck, prompt the user to join the Rivet Discord or file an issue on the Rivet GitHub to report an issue and get help.

Provide the user with a pre-generated report with:

Symptoms
- If this is happening in local dev, deployed, or both
- The error you're seeing
- Relevant source code related to this
What you've tried to solve it
Environment
- RivetKit version
- Runtime (Node, Bun, etc) including version
- If applicable, provider in use (e.g. Vercel, Railway, etc)
- If applicable, HTTP router in use (e.g. Hono, Express, Elysia)

Citing Sources

When providing information from Rivet documentation, cite the canonical URL so users can learn more. Each reference file includes its canonical URL in the header metadata.

How to cite:

Use inline links for key concepts: "Use actor keys to uniquely identify instances."
Add a "Learn more" link after explanations for complex topics

Finding canonical URLs:

The Reference Map below links to reference files. Each file's header contains:

> Canonical URL: https://rivet.dev/docs/actors/actions

Use that canonical URL when citing, not the reference file path.

Examples:

Actions → https://rivet.dev/docs/actors/actions
React client → https://rivet.dev/docs/clients/react
Self-hosting on Kubernetes → https://rivet.dev/docs/self-hosting/kubernetes

First Steps

Install RivetKit (latest: 2.0.42) npm install rivetkit@2.0.42
Define a registry with setup({ use: { /* actors */ } }).
Expose registry.serve() or registry.handler() (serverless) or registry.startRunner() (runner mode). Prefer serverless mode unless the user has a specific reason to use runner mode.
Verify /api/rivet/metadata returns 200 before deploying.
Configure Rivet Cloud or self-hosted engine
Integrate clients (see client guides below for JavaScript, React, or Swift)
Prompt the user if they want to deploy. If so, go to Deploying Rivet Backends.

For more information, read the quickstart guide relevant to the user's project.

Deploying Rivet Backends

Assume the user is deploying to Rivet Cloud, unless otherwise specified. If user is self-hosting, read the self-hosting guides below.

Verify that Rivet Actors are working in local dev
Prompt the user to choose a provider to deploy to (see Connect for a list of providers, such as Vercel, Railway, etc)
Follow the deploy guide for that given provider. You will need to instruct the user when you need manual intervention.

Features

Long-Lived, Stateful Compute: Each unit of compute is like a tiny server that remembers things between requests – no need to re-fetch data from a database or worry about timeouts. Like AWS Lambda, but with memory and no timeouts.
Blazing-Fast Reads & Writes: State is stored on the same machine as your compute, so reads and writes are ultra-fast. No database round trips, no latency spikes. State is persisted to Rivet for long term storage, so it survives server restarts.
Realtime: Update state and broadcast changes in realtime with WebSockets. No external pub/sub systems, no polling – just built-in low-latency events.
Infinitely Scalable: Automatically scale from zero to millions of concurrent actors. Pay only for what you use with instant scaling and no cold starts.
Fault Tolerant: Built-in error handling and recovery. Actors automatically restart on failure while preserving state integrity and continuing operations.

When to Use Rivet Actors

AI agents & sandboxes: multi-step toolchains, conversation memory, sandbox orchestration.
Multiplayer or collaborative apps: CRDT docs, shared cursors, realtime dashboards, chat.
Workflow automation: background jobs, cron, rate limiters, durable queues, backpressure control.
Data-intensive backends: geo-distributed or per-tenant databases, in-memory caches, sharded SQL.
Networking workloads: WebSocket servers, custom protocols, local-first sync, edge fanout.

Common Patterns

Actors scale naturally through isolated state and message-passing. Structure your applications with these patterns:

Design Patterns Documentation

Actor Per Entity

Create one actor per user, document, or room. Use compound keys to scope entities:

import { createClient } from "rivetkit/client";
import type { registry } from "./actors";

const client = createClient<typeof registry>();

// Single key: one actor per user
client.user.getOrCreate(["user-123"]);

// Compound key: document scoped to an organization
client.document.getOrCreate(["org-acme", "doc-456"]);

import { actor, setup } from "rivetkit";

export const user = actor({
  state: { name: "" },
  actions: {},
});

export const document = actor({
  state: { content: "" },
  actions: {},
});

export const registry = setup({ use: { user, document } });

Coordinator & Data Actors

Data actors handle core logic (chat rooms, game sessions, user data). Coordinator actors track and manage collections of data actors—think of them as an index.

import { actor, setup } from "rivetkit";

// Coordinator: tracks chat rooms within an organization
export const chatRoomList = actor({
  state: { rooms: [] as string[] },
  actions: {
    addRoom: async (c, name: string) => {
      // Create the chat room actor
      const client = c.client<typeof registry>();
      await client.chatRoom.create([c.key[0], name]);
      c.state.rooms.push(name);
    },
    listRooms: (c) => c.state.rooms,
  },
});

// Data actor: handles a single chat room
export const chatRoom = actor({
  state: { messages: [] as string[] },
  actions: {
    send: (c, msg: string) => { c.state.messages.push(msg); },
  },
});

export const registry = setup({ use: { chatRoomList, chatRoom } });

import { createClient } from "rivetkit/client";
import type { registry } from "./actors";

const client = createClient<typeof registry>();

// Coordinator per org
const coordinator = client.chatRoomList.getOrCreate(["org-acme"]);
await coordinator.addRoom("general");
await coordinator.addRoom("random");

// Access chat rooms created by coordinator
client.chatRoom.get(["org-acme", "general"]);

Sharding

Split high-load actors by time, user ID, or random key:

import { createClient } from "rivetkit/client";
import type { registry } from "./actors";

const client = createClient<typeof registry>();

// Shard by hour
const hour = new Date().toISOString().slice(0, 13); // "2024-01-15T09"
client.analytics.getOrCreate(["org-acme", hour]);

// Shard randomly across 3 actors
client.rateLimiter.getOrCreate([`shard-${Math.floor(Math.random() * 3)}`]);

import { actor, setup } from "rivetkit";

export const analytics = actor({
  state: { events: [] as string[] },
  actions: {},
});

export const rateLimiter = actor({
  state: { requests: 0 },
  actions: {},
});

export const registry = setup({ use: { analytics, rateLimiter } });

Fan-In & Fan-Out

Distribute work across workers (fan-out) and aggregate results (fan-in):

import { actor, setup } from "rivetkit";
import { createClient } from "rivetkit/client";

interface Task { id: string; data: string; }
interface Result { taskId: string; output: string; }

const coordinator = actor({
  state: { results: [] as Result[] },
  actions: {
    // Fan-out: distribute work in parallel
    startJob: async (c, tasks: Task[]) => {
      const client = c.client<typeof registry>();
      await Promise.all(
        tasks.map(t => client.worker.getOrCreate([t.id]).process(t))
      );
    },
    // Fan-in: collect results
    reportResult: (c, result: Result) => { c.state.results.push(result); },
  },
});

const worker = actor({
  state: {},
  actions: {
    process: async (c, task: Task) => {
      const result = { taskId: task.id, output: `Processed ${task.data}` };
      const client = c.client<typeof registry>();
      await client.coordinator.getOrCreate(["org-acme"]).reportResult(result);
    },
  },
});

const registry = setup({ use: { coordinator, worker } });

Anti-Patterns

"God" actor

Avoid a single actor that handles everything. This creates a bottleneck and defeats the purpose of the actor model. Split into focused actors per entity instead.

Actor-per-request

Actors maintain state across requests. Creating one per request wastes resources and loses the benefits of persistent state. Use actors for persistent entities and regular functions for stateless work.

Minimal Project

Backend

actors.ts

import { actor, setup } from "rivetkit";

const counter = actor({
  state: { count: 0 },
  actions: {
    increment: (c, amount: number) => {
      c.state.count += amount;
      c.broadcast("count", c.state.count);
      return c.state.count;
    },
  },
});

export const registry = setup({
  use: { counter },
});

server.ts

Integrate with the user's existing server if applicable. Otherwise, default to Hono.

No Framework

import { actor, setup } from "rivetkit";

const counter = actor({
  state: { count: 0 },
  actions: { increment: (c, amount: number) => c.state.count += amount }
});

const registry = setup({ use: { counter } });

// Exposes Rivet API on /api/rivet/ to communicate with actors
export default registry.serve();
`### Hono`
import { Hono } from "hono";
import { actor, setup } from "rivetkit";
import { createClient } from "rivetkit/client";

const counter = actor({
  state: { count: 0 },
  actions: { increment: (c, amount: number) => c.state.count += amount }
});

const registry = setup({ use: { counter } });

// Build client to communicate with actors (optional)
const client = createClient<typeof registry>();

const app = new Hono();

// Exposes Rivet API to communicate with actors
app.all("/api/rivet/*", (c) => registry.handler(c.req.raw));

export default app;
`### Elysia`
import { Elysia } from "elysia";
import { actor, setup } from "rivetkit";
import { createClient } from "rivetkit/client";

const counter = actor({
  state: { count: 0 },
  actions: { increment: (c, amount: number) => c.state.count += amount }
});

const registry = setup({ use: { counter } });

// Build client to communicate with actors (optional)
const client = createClient<typeof registry>();

const app = new Elysia()
	// Exposes Rivet API to communicate with actors
	.all("/api/rivet/*", (c) => registry.handler(c.request));

export default app;

Client Docs

Use the client SDK that matches your app:

Actor Quick Reference

State

Persistent data that survives restarts, crashes, and deployments. State is persisted on Rivet Cloud or Rivet self-hosted, so it survives restarts if the current process crashes or exits.

Static Initial State

import { actor } from "rivetkit";

const counter = actor({
  state: { count: 0 },
  actions: {
    increment: (c) => c.state.count += 1,
  },
});
`### Dynamic Initial State`
import { actor } from "rivetkit";

interface CounterState {
  count: number;
}

const counter = actor({
  state: { count: 0 } as CounterState,
  createState: (c, input: { start?: number }): CounterState => ({
    count: input.start ?? 0,
  }),
  actions: {
    increment: (c) => c.state.count += 1,
  },
});

rivetkit

Rivetkit

Rivet Actors

What To Do If You Get Stuck

Citing Sources

First Steps

Deploying Rivet Backends

Features

When to Use Rivet Actors

Common Patterns

Actor Per Entity

Coordinator & Data Actors

Sharding

Fan-In & Fan-Out

Anti-Patterns

"God" actor

Actor-per-request

Minimal Project

Backend

No Framework

Client Docs

Actor Quick Reference

State

Static Initial State

Keys

Input

Temporary Variables

Static Initial Vars

Actions

Events & Broadcasts

Connections

Static Connection Initial State

Actor-to-Actor Communication

Scheduling

Destroying Actors

Lifecycle Hooks

Helper Types

Errors

Actor

Low-Level HTTP & WebSocket Handlers

HTTP Handler

Versions & Upgrades

Client Documentation

Authentication & Security

CORS (Cross-Origin Resource Sharing)

API Reference

Reference Map

Actors

Clients

Connect

General

Self Hosting

Misc Notes