Skip to main content
Sign In

The primitive for
stateful workloads.

One Actor per agent, per session, per user. The same primitive powers realtime apps, multiplayer, and collaborative state.

Start Building Quickstart Guide

One primitive, every stateful workload.

The same Actor that holds an agent's memory holds a game lobby, a shared document, or a running workflow.

AI agents

One Actor per agent. Persistent memory, tool execution, and long-running context that survives restarts — in your existing Node.js or Bun backend.

Read the docs

Realtime & multiplayer

WebSockets and event broadcast built in. One Actor per room, match, or channel keeps every client in sync without a separate realtime service.

Read the docs

Collaborative state

One Actor per document or workspace. State lives next to compute, so concurrent edits stay consistent without cache-invalidation gymnastics.

Read the docs

Durable workflows

Queues, schedules, and timers on the same primitive. Multi-step operations pick up where they left off, even across sleeps and deploys.

Read the docs

A lightweight primitive with powerful capabilities.

One Actor per agent, per session, per user — state, storage, and networking included.

In-memory state

Co-located with compute for instant reads and writes. Persist with SQLite or BYO database.

Runs indefinitely, sleeps when idle

Long-lived when active, hibernates when idle.

Scales to zero, bursts to thousands

Sleeps at near-zero cost when idle, fans out when traffic spikes.

Global edge network

Deploy close to your users or in specific legal jurisdictions without complexity.

WebSockets

Real-time bidirectional streaming built in.

Workflows

Multi-step operations with automatic retries.

Queues

Durable message queues for reliable async processing.

Scheduling

Timers and cron jobs within your actor.

Actors in action.

One primitive that adapts to agents, workflows, collaboration, and more.

backend.ts
const agent = actor({
  // In-memory, persisted state for the actor
  state: { messages: [] },

  // Long-running actor process
  run: async (c) => {
    // Process incoming messages from the queue
    for await (const msg of c.queue.iter()) {
      c.state.messages.push({ role: "user", content: msg.body.text });
      const response = streamText({ model: openai("gpt-5"), messages: c.state.messages });

      // Stream realtime events to all connected clients
      for await (const delta of response.textStream) {
        c.broadcast("token", delta);
      }

      c.state.messages.push({ role: "assistant", content: await response.text });
    }
  },
});
client.ts
const agent = client.agent.getOrCreate("agent-123").connect();
agent.on("token", delta => process.stdout.write(delta));
await agent.queue.send("hello!");
Rivet Actor/ AI Agent

Each agent runs as its own actor with persistent context, memory, and the ability to schedule tool calls.

In-memory state(Context)SQLite or BYO database persistence(Memory)Scheduling(Tool calls)

How Actors Compare

Rivet Actors vs. traditional infrastructure.

Cold Startlower is better
~0xfaster
Rivet ActorIncludes durable state init, not just a process spawn. No actor key, so no cross-region locking. Measured with Node.js and FoundationDB.~20ms
Kubernetes PodNode.js 24 Alpine image (56MB compressed) on AWS EKS with a pre-provisioned m5.large node. Breakdown: ~1s image pull and extraction, ~3-4s scheduling and container runtime setup, ~1s container start.~6s
Virtual MachineAWS EC2 t3.nano instance from launch to SSH-ready, using an Amazon Linux 2 AMI. t3.nano is the smallest available EC2 instance (512MB RAM).~30s
Memory Per Instancelower is better
~0xsmaller
Rivet ActorRSS (resident set size) delta divided by actor count, measured by spawning 10,000 actors in Node.js v24 on Linux x86.~0.6KB
Kubernetes PodMinimum idle Node.js container on Linux x86: Node.js v24 runtime (~43MB RSS), containerd-shim (~3MB), pause container (~1MB), and kubelet per-pod tracking (~2MB).~50MB
Virtual MachineAWS EC2 t3.nano, the smallest available EC2 instance with 512MB allocated memory.~512MB
Read Latencylower is better
0ms
Rivet ActorState is read from co-located SQLite/KV storage on the same machine as the actor, with no network round-trip.0ms
RedisAWS ElastiCache Redis (cache.t3.micro) in the same availability zone as the application.~1ms
PostgresAWS RDS PostgreSQL (db.t3.micro) in the same availability zone as the application.~5ms
Idle Costlower is better
$0
Rivet ActorAssumes Rivet Actors running on a serverless platform. Actors scale to zero with no idle infrastructure costs. Traditional container deployments may incur idle costs.$0
Virtual MachineAWS EC2 t3.nano ($0.0052/hr compute + $1.60/mo for 20GB gp3 storage) running 24/7. t3.nano is the smallest available EC2 instance (512MB RAM).~$5/mo
Kubernetes ClusterAWS EKS control plane ($73/mo) plus a single t3.nano worker node with 20GB gp3 storage, running 24/7. t3.nano is the smallest available EC2 instance (512MB RAM).~$85/mo

Actors scale to zero with no idle infrastructure.

Horizontal Scalehigher is better
Infinite
Rivet ActorsRivet Actors scale linearly by adding nodes with no single cluster size limit.Infinite
KubernetesKubernetes officially supports clusters of up to 5,000 nodes per the Kubernetes scalability documentation.~5k nodes
Postgres1 primary
Multi-Regionlower is better
Global
RivetRivet automatically spawns actors near your users and handles routing across regions for a seamless edge network.Global edge network
Traditional Deployment1 region

Methodology — figures are directional, measured on commodity AWS infrastructure. Hover each entry for the measurement setup.
Rivet Actor Inspector in light modeRivet Actor Inspector in dark mode

Built-In Observability

Debugging and monitoring for actors and agents, from local development to production at scale.

SQLite Viewer

Browse and query SQLite databases in real-time across actors and agent sessions

Workflow State

Inspect workflow progress, steps, and retries as they execute

Event Monitoring

Track every state change, action, and agent event as it happens in real-time

REPL

Debug actors and agent sessions by calling actions, subscribing to events, and interacting directly with your code

Frequently asked questions

A Rivet Actor is a long-lived unit of compute that keeps its own state between requests. It is like a serverless function with memory and no timeouts. The common pattern is one actor per agent, per session, or per user, with state, storage, and networking included. See the Rivet Actors docs for details.
Serverless functions are stateless and short-lived, so every invocation re-fetches data from a database and long-running work hits timeouts. A Rivet Actor remembers state between requests, holds WebSocket connections, and runs as long as it has work to do. It still sleeps when idle, so you keep the scale-to-zero economics of serverless.
No. State lives on the same machine as your compute, so reads and writes are fast with no database round trips. Use in-memory state for small values and each actor's built-in SQLite database for large, relational, or queryable data. State is persisted, so it survives restarts, crashes, and deployments. You can still connect to an external database when you need one.
Cloudflare Durable Objects provide stateful serverless computing tied to the Cloudflare platform. Rivet Actors give you the same actor model capabilities as open source software that works with your existing infrastructure, so you can deploy on Kubernetes, AWS, a VPS, or Rivet Cloud without vendor lock-in. See the full Rivet vs Cloudflare Durable Objects comparison.
Actors automatically sleep after a period of inactivity to free up resources. Their state is persisted, and they wake on demand when a request, message, or scheduled alarm arrives. Sleeping actors consume no compute, which makes Rivet Actors cost-efficient for bursty workloads. See the lifecycle docs for how sleeping works.
The core pattern is one actor per entity in your system: a user, a document, a chat room, or an agent. Each actor is small and independent, so the system scales from zero to millions of concurrent actors automatically, with instant scaling and no cold starts.
Yes. Realtime is built in. Clients call actions to send data to an actor, and the actor pushes updates back over WebSockets with events, either to specific connections or broadcast to all of them. There is no external pub/sub system or polling to manage.
Rivet Actors are written in TypeScript or JavaScript and run on Node.js, Bun, and Deno, with a Rust SDK available in preview. Quickstarts cover backend, React, Next.js, and Rust apps. Client libraries are available for JavaScript, React, and Swift.

Infrastructure for
the agentic era.

Build with agents, build for agents, and run it where your data lives.

Start BuildingTalk to an Engineer