rivet-dev/rivet

Rivet schedules "Actors": long-lived processes addressed by key, each with its own SQLite database, key-value storage, a queue, realtime connections, and scheduling. It is aimed at teams that run many small stateful workloads — one per agent, session, tenant, document, or room — and would rather not put each behind a container or VM. The control plane is a Rust binary; managed cloud, BYOC, and full self-hosting run the same code.

What changes in a workflow

Instead of modelling each agent or document as a pod, you define actor actions in TypeScript/Rust on Node.js or Bun. An action can write to the actor's SQLite database and broadcast to connected clients over WebSocket; clients call it by key through a generated, typed client. Idle actors persist state and unload, then wake on the next request, and a failed node's actors are rescheduled with their state intact. This is the main trade: you give up per-unit containers and get lightweight, key-addressed units with built-in persistence, routing, and scheduling.

Typical use cases in the docs are one actor per coding agent, a backend per generated user app, company agents that stay inside a VPC, and one actor per realtime room. Workflows and sandboxes are additional actor types. There is also a skills package that hands setup instructions to AI coding tools such as Claude Code and Cursor.

Deployment and requirements

The README claims room for many actors on one control plane and gives concrete benchmark figures for this, so the architecture is the point. Self-hosting means running identical control plane instances (one to try, three or more in production), a persistent disk per instance, one object-storage bucket per cluster (S3, GCS, Azure Blob, or S3-compatible like MinIO or R2), and the nodes that execute actors. The bucket is the only external dependency; the project says no Postgres, FoundationDB, or NATS is required. A local filesystem backend exists for single-machine trials. Deployment guides exist for Docker Compose, Kubernetes, VMs, AWS ECS, Railway, and Render; nodes need only a standard process that connects over WebSocket.

Performance claims and their scope

The 6.92 ms cold start and 4.37 ms wake figures come from a stated setup: October 25, 2026, Azure eastus2, three control-plane instances across availability zones, writes acknowledged by 2 of 3 instances, and one Node.js 24 node VM. They measure client send to full first reply, not application-level throughput. Memory figures are RSS increase per actor with the Rust SDK. The Kubernetes comparison is described as typical published values, not a matched benchmark.

Limits and open questions

The per-actor SQLite model makes cross-actor queries non-trivial. In the HN thread a maintainer acknowledged this and said a multi-database query engine is planned, with DuckDB as one option. Discussion also raised the burden of reimplementing database transactions. One commenter reported replacing a Durable Objects feature with Rivet Actors and being happy, while saying the SQLite store was not yet in use. These are user opinions from February 2026, not project guarantees. Python and Swift SDKs are labelled experimental; the TypeScript and Rust SDKs are the primary paths.

Licensed Apache-2.0, so self-hosting is permitted under those terms. Whether to self-host or use Cloudflare-managed compute depends on your compliance and operational needs.

Project source and documentation