Rivet Actors are the primitive for stateful workloads. Built for AI agents, collaborative apps, and durable execution.
rivet (rivet-dev/rivet)
Searching Database…
rivet README
The project's README from github.com/rivet-dev/rivet. As one markdown file: README.md.
Fast, high-density, scalable orchestration for agentic workloads.
Rivet Actors are durable processes for agents, workflows, and sandboxes.
6.9 ms cold starts, 72 KB per Actor, billions on one control plane.
One Rust binary and a bucket. No database, no message bus. Open source and self-hostable.
Quickstart • Documentation • Changelog • Discord • X
Getting Started
Use with Your Coding AgentGive your coding agent the Rivet skills to create examples or integrate into existing projects: Works with Claude Code, Cursor, Windsurf, and other AI coding tools. |
Start From Scratch |
What is Rivet?
Rivet is an orchestrator for agentic workloads. Where Kubernetes schedules pods, Rivet schedules Actors: long-lived processes with durable state, a SQLite database, a queue, realtime connections, and scheduling, each addressed by key.
Create one Actor per agent, per session, per user, or per tenant. Run it on plain Node.js, Bun, or Rust. Open source and self-hostable.
- 72 KB per Actor: An Actor lives inside a node process you already run, not in its own container or VM. A server that held hundreds of pods holds hundreds of thousands of Actors.
- 6.9 ms cold starts: A cold start includes scheduling the Actor, creating its storage, and serving the first request. No image pull, no container boot.
- Billions of Actors on one control plane: Actors are scheduled independently, so adding capacity means adding machines. The same control plane runs a thousand Actors or a billion.
- Hibernates when idle, wakes on demand: An idle Actor writes its state and unloads. The next request brings it back in 4.4 ms with nothing lost.
- Keep state with each Actor: Every Actor gets its own SQLite database and key-value storage. The control plane replicates writes to the disks of several instances before acknowledging them, then moves data to object storage in the background. Storage never runs out and the bucket never sits on the write path.
- One Rust binary and a bucket: There is no database to run and no message bus. Control plane instances are identical, run every service, and find each other through the bucket.
- Run code agents generate at runtime: Each piece of new, untrusted code gets an Actor of its own, with its own database and filesystem and no reach into anyone else's.
- Works with the tools you already use: Typed SDKs for your backend and React hooks for your frontend. No custom runtime, so your existing packages, tooling, and tests work unchanged.
Backend
import { actor } from "rivetkit";
import { db } from "rivetkit/db";
const agent = actor({
// Per-Actor SQLite database, persisted across restarts and hibernation
db: db({
onMigrate: async (db) => {
// Apply the SQLite schema
await db.execute(`CREATE TABLE IF NOT EXISTS messages (role TEXT, content TEXT)`);
},
}),
actions: {
chat: async (c, text: string) => {
// Durably save the message
await c.db.execute("INSERT INTO messages VALUES (?, ?)", "user", text);
const messages = await c.db.execute("SELECT role, content FROM messages");
const response = streamText({ model: openai("gpt-5"), messages });
// Stream tokens to every connected client for multiplayer
for await (const delta of response.textStream) {
c.broadcast("token", delta);
}
// Durably save the response
await c.db.execute("INSERT INTO messages VALUES (?, ?)", "assistant", await response.text);
},
},
});
Client (frontend or backend)
// Connect to an Actor
const agent = client.agent.getOrCreate("agent-123").connect();
// Listen for realtime events
agent.on("token", delta => process.stdout.write(delta));
// Call an action on the Actor
await agent.chat("how many r's in strawberry?");
Actor types
Every product Rivet ships is an Actor, scheduled by the same control plane.
- Actors: Long-lived processes with state, realtime, and scheduling built in.
- Agents: A durable process per agent, with memory that survives restarts.
- Workflows: Multi-step operations that replay instead of starting over.
- Sandboxes (agentOS): A filesystem, shell, and network for code you did not write.
- Dynamic Apps (preview): A backend per user, deployed the moment it is generated.
Built for everything agents need
- Coding agents: One Actor per agent with a durable process, a sandbox, and state that survives restarts.
- Agent app builders: Your product generates a whole backend for a user; each one deploys as its own Actor that scales to zero.
- Company-specific agents: Run agents inside your VPC next to Postgres, your APIs, and your helpdesk, so no data leaves your cloud.
- Personal agents: A long-lived Actor per user with memory, scheduling, and reminders, online for months.
- Realtime apps: One Actor per document, room, or channel broadcasting changes to every connected client.
How Actors compare to Kubernetes
| Rivet Actor | Kubernetes pod | |
|---|---|---|
| Cold start | 6.92 ms | ~6 s |
| Wake from hibernation | 4.37 ms | ~6 s (new pod) |
| Memory per instance | 72.4 KB | ~200 MB |
| Memory while idle | 0 MB (hibernates) | Always resident |
| Scale | Billions of Actors on one control plane | ~5k nodes per cluster |
| Storage | Bottomless SQLite, replicated and moved to your bucket | Persistent volume per pod |
Benchmark details & methodology
- Cold start (6.92 ms): Client send to full first reply from a newly created keyed Actor, including scheduling, storage creation, and framework startup: 6.92 ms p50, 8.11 ms p99 over 1,500 samples.
- Wake (4.37 ms): Client send to full reply from an Actor asleep for at least 10 seconds: 4.37 ms p50, 6.80 ms p99 over 1,200 samples.
- Setup: Measured October 25, 2026 on Azure
eastus2across three availability zones. Three control plane instances (Standard_L8as_v5, local NVMe), one per zone, with every write acknowledged by 2 of 3 instances. One node VM running Node.js 24 in the first zone. Full method and reproduction steps at rivet.dev/docs/benchmarking. - Memory per instance (72.4 KB): RSS increase per running Actor. Measured with the Rust rivetkit SDK.
- Kubernetes figures are typical published values, not a matched benchmark. ~6 s cold start assumes a pre-provisioned node; ~200 MB is a typical idle Node.js pod; ~5k nodes is the documented cluster limit.
Features
Routing, scheduling, types, and telemetry, built in.
- Fault tolerance by design: A node going down reschedules its Actors elsewhere with their state intact. No replay harness or checkpointing of your own.
- Keep state with each Actor: Every Actor gets its own SQLite database and key-value storage. The control plane replicates writes and moves data to object storage, so you never size a disk for an Actor.
- Multi-region: Place Actors near the users and data they serve, and route requests to wherever each one currently lives.
- HTTP & WebSocket networking: Address an Actor directly over HTTP or hold a live WebSocket to it. No queue or broker in between.
- End-to-end type safety: Actor definitions generate their own client types, so a signature change breaks the build rather than production.
- React SDK: First-party hooks that subscribe a component to an Actor's state and keep it live as the Actor updates.
- OpenTelemetry & observability: Traces, metrics, and structured logs emitted in OTel format, into the collector you already run.
- Single Rust binary: The control plane ships as one static binary. Run a few identical instances behind a load balancer with an object storage bucket: no database and no message bus to stand up first.
- Cron & scheduling: Wake an Actor on a schedule or at a timestamp it sets for itself, without a separate scheduler.
- Sleeps when idle: Idle Actors release their resources and wake with durable state intact when the next request arrives.
- Actor-to-Actor calls: Actors address each other by key and call across the cluster as if the other one were local.
- No Kubernetes operator: One control plane behind a load balancer, speaking plain HTTP inside your VPC. No CRDs, no operator, no service mesh to keep alive.
- Open source: Apache 2.0, self-hostable in full. The managed service runs the same control plane you can run yourself.
Deployment Options
Local & Self-HostInstall Actors and run it locally while you build. When you ship, run the same open-source control plane as a container on vanilla Docker, Kubernetes, or a VM, with a bucket for durable storage. |
Rivet CloudCreate a project and deploy. There is nothing to operate. Or bring your own nodes and run Actors on your compute while Rivet Cloud provides the control plane and routing layer. |
BYOCThe whole stack runs inside your VPC, and Rivet manages it for you over an outbound connection. Every Actor's data stays in your own account and your own bucket. |
Every option runs the same binary. The only difference is who operates it. Self-hosting means running four things: identical control plane instances (one to try it, three or more in production), a persistent disk per instance that holds recent writes and the instance's identity, one bucket per cluster on S3, Google Cloud Storage, Azure Blob Storage, or any S3-compatible store, and the nodes that run your Actors. There is no database to run and no message bus. Local dev matches production: the same binary, APIs, and control-plane behavior from laptop to production.
Open source, permissively licensed: Apache 2.0 means you own your infrastructure. The managed service runs the same control plane you can run yourself. Talk to an engineer →
Works with the tools you already use
Typed SDKs for your backend and React hooks for your frontend. Rivet runs on native Node.js and Bun with no custom runtime, so your existing packages, tooling, and tests work unchanged.
Deploy nodes on: Docker Compose • Kubernetes • VM & bare metal • Hetzner • AWS ECS • Railway • Render
Frameworks: React • Next.js • Hono • Elysia • tRPC • Effect
Runtimes: Node.js • Bun • Rust
Tools: Vitest • OpenTelemetry • Pino • AI SDK • OpenAPI • AsyncAPI
FAQ
Does Rivet have BYOC?
Yes. Rivet deploys into your own cloud account, including air-gapped environments: the control plane and storage run inside your VPC while Rivet operates them. See the BYOC docs.
Does Rivet have a cloud?
Yes. Rivet Cloud is fully managed. It can run your app's Docker image as actor nodes on a Rivet Cloud cluster, or you can bring your own nodes and run Actors on your compute while Rivet Cloud provides the control plane and routing layer.
Can I self-host Rivet?
Yes. Rivet is fully self-hostable; see the self-hosting docs. The control plane runs anywhere a container runs, with guides for Docker Compose, Kubernetes, VMs and bare metal, Hetzner, Railway, Render, and AWS ECS. For enterprise support with a self-hosted deployment, contact us.
Do I still need Postgres, FoundationDB, or NATS?
No. An object storage bucket is the only dependency: there is no database to run and no message bus, and control plane instances find each other through the bucket. Rivet works with Amazon S3, Google Cloud Storage, Azure Blob Storage, and any S3-compatible store such as MinIO, Cloudflare R2, or Hetzner Object Storage. A local filesystem backend is available for trying Rivet on one machine.
Is Rivet open-source?
Yes. Rivet is open source under the permissive Apache 2.0 license. You're looking at it.
How does Rivet compare to Kubernetes?
Rivet is an orchestrator for stateful Actors. Think of an Actor like a pod, but much smaller, more lightweight, and faster to start: 72 KB and 6.9 ms versus 200 MB and seconds. Each Actor also comes with a bottomless SQLite database for structured persistence, instead of or in addition to a filesystem, which gives it more flexibility than a Kubernetes pod.
How does Rivet compare to Cloudflare Durable Objects?
Rivet is often used as an open-source alternative to Cloudflare Durable Objects that is easy to self-host and scales. It also fixes many of the constraints of Durable Objects: no 128 MB memory cap, bottomless storage instead of a 10 GB SQLite limit, Actors are not randomly evicted, and you control the runtime because Actors run on vanilla Node.js or Bun instead of a custom runtime. Rivet also adds built-in connection handling, event broadcasting, durable scheduling and cron, full Vitest support, lifecycle hooks for draining, and control over Actor upgrades. See the Cloudflare Durable Objects comparison.
Does Rivet use a custom V8 runtime?
No. Rivet runs on native Node.js and Bun, so your existing packages, tooling, and tests work unchanged.
Does Rivet support Bun?
Yes. Rivet supports Bun in addition to Node.js.
Does Rivet support Effect?
Yes. Rivet Actors work with Effect; see the Effect agent example.
Is Rivet like Erlang, Akka, or Orleans?
Rivet implements the virtual actor pattern, which is closest to Orleans, but focuses on what modern workloads need: SQLite persistence instead of simple JSON stores and support for modern runtimes. Erlang and Akka do not provide virtual actors out of the box, though ecosystem packages exist that offer functionality comparable to Rivet Actors.
Does Rivet require microVMs, gVisor, or nested virtualization?
No. Rivet only needs a standard process that connects to the control plane over WebSocket. That process can be Node.js, Bun, Rust, or anything else.
Projects in This Repository
| Project | Description |
|---|---|
| RivetKit TypeScript | Client & server library for building Actors |
| RivetKit Rust | Rust SDK |
| RivetKit Python | Python client (experimental) |
| RivetKit Swift | Swift client (experimental) |
| Control Plane | Rust control plane that schedules, routes, and persists Actors |
| ↳ Pegboard | Actor scheduling & networking |
| ↳ Gasoline | Durable execution engine |
| ↳ Guard | Traffic routing proxy |
| ↳ Epoxy | Multi-region KV store (EPaxos) |
| Dashboard | Inspector for debugging Actors |
| Documentation | Source for rivet.dev/actors/docs |
| Examples | Runnable examples |
Community
- Discord - Chat with the community
- X/Twitter - Follow for updates
- Bluesky - Follow for updates
- GitHub Discussions - Ask questions
- GitHub Issues - Report bugs
- Talk to an engineer - Discuss your use case