What are Rivet Actors and what workloads can they run?

Rivet Actors are durable processes that each agent, workflow, or sandbox runs inside. Instead of giving every workload its own container or VM, an Actor lives inside a worker process you already run, which is how Rivet claims a server that held hundreds of pods can hold hundreds of thousands of Actors. If you're building agentic systems and want persistence, replay, and high density without managing a container per task, Actors are the unit to understand.

The core idea: one durable process per workload

An Actor is a long-lived process with its own state that survives restarts. Rivet's page describes it as "a durable process to live in" for every agent. Two numbers frame the design:

• 12 ms cold starts — Actors start in milliseconds, not minutes.
• 72 KB per Actor (72.4 KB per running Actor RSS increase) — small enough that density, not provisioning, becomes the constraint.

Because an Actor runs inside a worker process rather than its own container or VM, the overhead per workload drops sharply. That's the mechanism behind the "2,829× more workloads per server" claim: it's a density argument, not a raw speed argument.

What workloads can Actors run?

Rivet groups workloads into a few Actor types, each aimed at a different job.

Workflows: replay instead of restart

The distinguishing feature of Workflows is that multi-step operations replay rather than start over. If a step fails or the process restarts, the workflow resumes from where it was instead of re-running everything. This matters for long flows where re-executing earlier steps would be expensive or have side effects.

Sandboxes: for untrusted code

Sandboxes give you a filesystem, shell, and network — the pieces needed to execute code you didn't write. This is the Actor type to reach for when the workload is "run this code safely," not "keep this state alive."

Dynamic Apps: a backend per user

Dynamic Apps deploy a backend the moment it's generated, so each user gets their own instance. The page's example is a CRM generated for a roofing business, with schema, API routes, and a live release — the pattern is per-user backends spun up on demand.

Where Actors show up in practice

Rivet lists several concrete scenarios, which are useful for judging fit:

• Coding agents — an agent that fixes a flaky test, opens a PR, and resumes after restarts (the example shows it resumed after 2 restarts).
• Agent app builders — generating and deploying a per-user app with schema, routes, and a release.
• Company-specific agents — running inside your VPC so no data leaves your cloud, connecting systems like a helpdesk, orders API, and Postgres.
• Personal agents — scheduled tasks like a weekday morning briefing, with memory that persists (the example shows 1,204–1,205 memories and "online 214 days").
• Realtime apps — collaborative editing synced at 12 ms.

The common thread: state that must persist, work that must survive restarts, or code that must run isolated.

When Actors are the right fit — and when they aren't

Reach for Actors when:

• Your workload needs durable state across restarts.
• You're running many small workloads and container-per-task overhead is the bottleneck.
• You need multi-step flows that resume rather than restart.
• You're executing untrusted code and need a filesystem, shell, and network.

Look elsewhere when:

• Your workload is stateless and short-lived — the durability machinery adds little.
• You need a full VM-level isolation boundary per task; an Actor shares a worker process by design.

Getting started

Rivet is open-source and self-hostable. The page's quick-start path is to hand the skills package to your coding agent:

npx skills add rivet-dev/skills

Rivet also has a pricing page at rivet.dev/pricing/, so check there for current plan details before assuming a free tier — the source material doesn't state pricing terms. For deeper detail on each Actor type, the site links out to dedicated pages for agentOS, Dynamic Apps, Enterprise, and Actors.