Rivet Actors are durable processes for agents, workflows, and sandboxes.
12 ms cold starts, 72 KB per Actor, billions on one control plane.
Open source and self-hostable.
Quickstart • Documentation • Changelog • Discord • X
|
Give your coding agent the Rivet skills to create examples or integrate into existing projects: npx skills add rivet-dev/skillsWorks with Claude Code, Cursor, Windsurf, and other AI coding tools. |
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 worker process you already run, not in its own container or VM. A server that held hundreds of pods holds hundreds of thousands of Actors.
- 12 ms cold starts: A cold start includes scheduling the Actor, loading its state, 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 12 ms with nothing lost.
- SQLite or a POSIX filesystem per Actor: Every Actor gets a SQLite database or a POSIX filesystem, tiered to S3. Idle Actors cost nothing, so millions can sit parked with their state intact.
- 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?");Every product Rivet ships is an Actor, scheduled by the same control plane.
- Actors: Give every agent a durable process to live in.
- 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: A backend per user, deployed the moment it is generated.
- 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.
| Rivet Actor | Kubernetes pod | |
|---|---|---|
| Cold start | 12.3 ms | ~6 s |
| 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 |
Benchmark details & methodology
- Cold start (12.3 ms): Round trip of an HTTP request waking an Actor from hibernation: 12.3 ms p50, 27.7 ms p99. Measured September 2026 on FoundationDB with the Rust rivetkit SDK. Uses an experimental Rivet feature that will be enabled by default in an upcoming update.
- Memory per instance (72.4 KB): RSS increase per running Actor. Measured September 2026 on FoundationDB 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.
Routing, scheduling, types, and telemetry, built in.
- Fault tolerance by design: A worker going down reschedules its Actors elsewhere with their state intact. No replay harness or checkpointing of your own.
- 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 with no external dependencies 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.
|
Install Actors and run it locally while you build. When you ship, run the same open-source control plane as a Rust binary or container on your own infrastructure. npm install rivetkit |
Deploy Actors on Rivet Cloud with managed infrastructure and persisted Actor data. Or bring your own worker and run Actors on your compute while Rivet Cloud provides the control plane and routing layer. |
Run the control plane inside your own VPC, fully managed by Rivet. Your data never leaves your cloud and there is no inbound management connection. |
Run your agent infrastructure where your data already lives. The control plane is a single Rust binary: one process to install, monitor, and upgrade, on Kubernetes with the Enterprise Helm chart or as a systemd unit. Use Postgres or FoundationDB for persistence and tiered storage to S3. 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 →
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 workers on: Vercel • Railway • AWS ECS • AWS Lambda • GCP Cloud Run • Cloudflare • Kubernetes • Docker
Frameworks: React • Next.js • Hono • Elysia • tRPC • Effect
Runtimes: Node.js • Bun • Rust
Tools: Vitest • OpenTelemetry • Pino • AI SDK • OpenAPI • AsyncAPI
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 Actors for you on Rivet Compute, with preview deployments and auto-scaling in edge regions, or you can bring your own worker 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. For enterprise support with a self-hosted deployment, contact us.
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. Each Actor also comes with SQLite 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, no 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, multi-region routing, 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.
| 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) |
| Container Runner | Runs Actors as containers |
| Dashboard | Inspector for debugging Actors |
| Documentation | Source for rivet.dev/actors/docs |
| Examples | Runnable examples |
- 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