A convincing model for stateful application work
Rivet starts from a useful observation: many modern backends are collections of small, stateful things. An AI agent has conversation memory and a queue of messages. A collaborative document has connected editors and updates to broadcast. A chat room has history, timers, and live clients. Teams commonly spread those responsibilities across a web server, Redis, a database, a queue, a scheduler, and a separate real-time service. Rivet puts them behind an actor abstraction instead.
Each actor is a long-running logical process with in-memory state, persistence, a durable queue, scheduling, workflows, and WebSocket communication. It can sleep while idle and resume when work arrives. The project suggests one actor per agent, session, user, document, or tenant. That is the right level of explanation: Rivet is not an agent framework or database replacement by itself, but an application runtime that coordinates stateful units of work.
The repository contains much more than a small SDK. RivetKit provides the TypeScript programming model, while the Rust engine handles actor orchestration, routing, durable execution, and storage. The dashboard supplies an SQLite viewer, workflow inspection, event monitoring, and a REPL. Experimental Rust and Python clients sit alongside the main TypeScript implementation. Apache 2.0 licensing keeps both the engine and library available for self-hosting.
The local developer experience is the best part
A basic trial is refreshingly direct. Install rivetkit, define an actor and registry, start the server, then connect from TypeScript or React. Node.js, Bun, and Deno are documented, and the local process exposes developer tools on port 6420. Teams can also install Rivet's coding-agent skills for Claude Code, Cursor, Windsurf, and compatible assistants.
The API brings related behavior together. Actor code can update local state, iterate over queued messages, stream events to clients, schedule future work, and run retryable multi-step operations. Keeping those concerns in one unit should make an agent session or collaborative room easier to reason about than a chain of unrelated services.
Rivet publishes striking comparisons for cold starts, memory use, and local reads. The README includes methodology, which is better than presenting bare numbers, but buyers should treat them as project-run measurements under specific hardware and deployment assumptions. A Kubernetes pod and a Rivet actor are not interchangeable units. The practical advantage is the architecture's intent: small stateful processes that can hibernate, not a promise that every workload will reproduce the headline figures.
Self-hosting changes the size of the job
The README's single Docker command is enough to inspect the engine. The Docker Compose guide then shows the real shape: an engine, persistent storage, an application runner, endpoint credentials, and runner registration. Production adds decisions that cannot be hidden by the actor API.
For a single node, the docs recommend the file-system backend based on RocksDB. For multiple nodes, they recommend PostgreSQL, but explicitly describe it as suitable for light-to-moderate workloads, roughly up to 1,000 concurrent actors. The most scalable FoundationDB path comes with a direction to contact enterprise support. That boundary matters. Organizations choosing open source specifically to operate a large platform without vendor involvement should validate it before committing.
The production checklist calls for at least two engine nodes, a load balancer, two or more NATS replicas for multi-node messaging, TLS termination, database backups and failover, resource limits, health probes, autoscaling, and OpenTelemetry. Rivet Cloud and self-hosted Rivet are therefore very different purchasing decisions. The managed route lets an application team focus on actor code; the self-hosted route needs platform ownership.
The rough edges are specific, not theoretical
Recent reports show a runtime still being hardened. One issue describes an actor action hitting a closed SQLite coordinator immediately after a local engine restart, with a bounded client retry as the observed workaround. Another reports scheduled actions without payloads failing validation in the Effect integration. A self-hosted user found the Inspector console unable to open its WebSocket because the UI omitted a protocol header. There is also a release report showing 2.3.9 artifacts identifying themselves as 2.3.7.
These reports argue for pinning versions, exercising restart and recovery paths, and testing the dashboard against the exact engine image. External identity also needs attention: an open request says validating OIDC or JWT tokens from providers such as Keycloak currently requires manual discovery, key fetching, verification, and caching code.
Language support is another practical filter. TypeScript has the clearest path, while the repository calls Rust and Python experimental. An older open request asks for a .NET SDK and describes HTTP wrappers or a Node.js bridge as the current options. Polyglot organizations should check the client they actually need, not infer equal support from the Rust-heavy repository language.
Healthy, ambitious, and best adopted deliberately
The repository was pushed on August 7, 2026, release 2.3.10 arrived on July 26, and issues and pull requests were still changing on August 8. GitHub's combined open count is dominated by pull requests, while the open issue search returned a much smaller set of current reports. This is an active project with a busy development queue, not an abandoned engine with an old release badge.
Documentation is excellent for a project with this breadth. It separates local quickstarts, deployment targets, runtime modes, storage backends, security, and production checks. Crucially, it states the PostgreSQL and FoundationDB boundaries instead of hiding them.
Rivet is a strong trial for a TypeScript team whose system already looks like actors: agents, rooms, documents, sessions, or tenants with state and live connections. It is less compelling as a casual replacement for a queue, or as a large self-hosted platform chosen only from the quickstart. Build one representative actor, test failure recovery, and price the managed and self-hosted paths separately. If the model simplifies the application enough to justify the operating layer, Rivet earns a place on the shortlist.