Rivet gives each stateful entity its own actor
Rivet's core idea is simple to explain. Create one actor per agent, user, session, tenant, room, or collaborative document. Its code can keep state in memory, consume a durable queue, broadcast events to connected clients, schedule future work, and run retryable workflows. Persistence allows an idle actor to sleep and return later. That shape removes repeated glue when an application would otherwise combine a process, WebSocket server, queue, scheduler, and database record for every stateful entity.
Our checkout at commit e34eba7 contained 7,413 files and about 843,397 source lines in 36.8 MB. The repository includes the TypeScript library, experimental Rust and Python clients, a Rust engine, orchestration and routing components, a multi-region key-value system, a dashboard, examples, a website, and documentation. GitHub now resolves the requested rivet-dev/rivet URL to rivet-dev/actors, reflecting the actor-centered branding.
TypeScript is the supported path; Rust and Python are experimental
The README starts with a TypeScript actor and client. A backend processes queued messages, updates state, calls a model, and broadcasts streamed tokens. A client connects to a named actor and sends work. Integrations cover React, Next.js, Hono, Express, Elysia, tRPC, serverless platforms, containers, and several JavaScript runtimes. Vitest, logging, AI SDK, OpenAPI, and AsyncAPI examples extend that path.
Our pnpm installation pulled 2,928 packages in 94 seconds and occupied 3,846 MB. That is the contributor monorepo, not the cost of adding rivetkit to one application. The distinction is important. Product evaluators should build a narrow actor example first. People planning engine changes, docs work, or broad example maintenance must accept a much larger workspace spanning TypeScript and Rust components. The README explicitly calls the Rust and Python clients experimental, so non-TypeScript teams should verify missing features before committing.
Library, self-hosted engine, and cloud are different commitments
Local development can run actors inside the application process after installing one package. Self-hosting adds the Rivet engine as a Rust binary or container, with filesystem, Postgres, or FoundationDB storage. Rivet Cloud adds managed placement and global routing while connecting to an application's existing hosting. These options share an actor API, but they do not have the same operating model, fault tolerance, latency, or cost.
The full checkout had 9 CI workflow files and pnpm workspaces, yet no Dockerfile or top-level tests directory according to our lab signals. The README still documents a published engine container and library tests, so those signals describe repository layout rather than product capability. Self-hosters need to select storage, expose the engine safely, plan upgrades, observe actors and workflows, and test recovery. Apache-2.0 permits that work; it does not perform it.
The benchmark table is a hypothesis to verify
Rivet compares actor cold starts, memory, idle cost, state-read latency, horizontal scale, and multi-region behavior with Kubernetes pods, virtual machines, Redis, and Postgres. The README includes methodology and environment details, which is better than an unexplained performance graphic. The scenarios still come from the vendor and compare unlike deployment units. An actor, pod, virtual machine, database read, and managed edge network solve overlapping but different operational problems.
Our 3-CPU, 8 GB sandbox measured install, build, and test behavior only. We did not reproduce the README's latency, memory, cost, or scale figures, so this review does not present them as independent findings. A buyer should model its own actor state size, connection pattern, sleep frequency, storage backend, regions, and recovery behavior. The useful question is whether the actor abstraction removes enough application code to justify a new runtime boundary.
What happened when we ran it
Our run at commit e34eba7 installed 2,928 packages in 94 seconds and used 3,846 MB. The build failed with exit 1 after 15 seconds. Its tail says sandbox-coding-agent#build failed, 0 of 16 tasks succeeded, and Turbo stopped the run. The supplied lines do not include the compiler or application error above that summary, so they do not establish why the example failed.
The test command failed with exit 2 after 20 seconds. Its tail identifies hello-world-supabase-functions#check-types as the failed task, with 1 of 63 tasks successful. Again, the provided excerpt contains only the task summary and final lifecycle error. We cannot tell whether the cause was code, environment, generated files, configuration, or something else. The honest result is that this fresh monorepo snapshot did not build or test cleanly.
Active development includes fixes to actor lifecycle behavior
GitHub showed 6,085 stars, 259 open issues and pull requests combined, and a push on August 25, 2026. Recent pull requests addressed state-proxy persistence, teardown signaling, connection snapshot stalls, graceful child-process draining, workflow resume behavior, and debugging identifiers. Release v2.3.10 was published on July 26. These are signs of active engineering around the hard parts of stateful systems, alongside a sizable change queue.
The documentation is broad and specific. It explains actors, self-hosting, integrations, observability, coding-agent skills, and the benchmark methodology. The dashboard can inspect SQLite state, workflow progress, events, and invoke actions through a REPL. That visibility matters when work persists across retries and sleep. It also adds another operational interface to secure in self-hosted environments.
Start with one actor boundary, not the whole platform
A good Rivet trial is one stateful feature with painful existing glue: an agent session that streams tokens and schedules follow-up work, or a collaborative room that persists after every client disconnects. Implement it with the local TypeScript library, test reconnects and duplicate messages, then decide whether managed or self-hosted orchestration solves a real scaling problem. Avoid beginning with a multi-region migration based on claimed scale.
The failed 15-second build and 20-second test run make this exact monorepo snapshot hard to recommend to a new contributor without investigation. They do not prove the published library or cloud service fails. They do show a gap between the polished product entry and a clean whole-repository build. Rivet remains a serious actor option for TypeScript teams, with Dapr better for polyglot runtime breadth and Temporal better when durable workflows are the primary need.