Rivet Open-Sources an Actor-Based Agent Orchestrator Backed by Tiered S3 Storage

Summary:Rivet has open-sourced an actor-based orchestrator designed for long-running agentic workloads. Instead of provisioning a full sandbox for every agent, it keeps each agent in a lightweight actor with in-memory state, durable SQLite storage, WebSocket support, and idle hibernation. The persistence layer combines a replicated SSD write tier with background batching to S3. Rivet reports 72 KB baseline actor memory, 4.9 ms p99 startup latency, 1.07 ms p99 durable writes across three availability zo

---

Rivet has open-sourced an actor-based orchestration infrastructure for long-running agentic workloads. Its central design choice is to replace a full sandbox per agent with a lightweight, long-lived actor. Each actor can hold in-memory context, execute durable SQLite transactions, expose WebSocket endpoints for multiplayer collaboration, and hibernate when idle.

From Sandboxes to Long-Lived Actors

Conventional agent sandboxes provide strong isolation but can remain expensive and slow to start. Rivet reports a baseline memory footprint of 72 KB for an actor versus 512 MB for a minimal sandbox. Its p99 startup latency is 4.9 ms for actors and 1.7 seconds for sandboxes.

That difference matters when a platform maintains thousands of agents waiting for tool calls, user input, or collaboration events. Sandboxes can keep paying for mostly idle resources, while actors make capacity planning easier and support hibernation.

The actor model does not automatically provide the same security boundary as a sandbox. Code running inside an actor still needs explicit network policies, filesystem permissions, CPU and memory limits, timeouts, and audit controls. Systems that execute untrusted generated code should separate state orchestration from isolated execution.

State Ownership and Concurrency

Rivet Actors resemble Cloudflare Durable Objects in several respects, but can be self-hosted and run from a single Rust binary. An actor typically owns the state for one logical session or task, giving messages a serialized processing order and reducing races caused by concurrent writes to shared state.

That ordering also creates a throughput constraint. A long-running model inference or external tool call inside the event loop can block subsequent messages. A practical design should keep short state transitions inside the actor while offloading long computations to workflows or dedicated workers, then writing the result back through the actor. Rivet supports workflows and Durable Streams, but developers still need to define ownership boundaries explicitly.

The SSD-Cached, S3-Backed Storage Model

Rivet previously used FoundationDB, then moved to a tiered architecture with SSD for fast access and S3 for durable object storage. Agent transcripts, generated artifacts, and complete POSIX filesystems can consume substantially more storage than conventional relational workloads, making it inefficient to keep all cold data on SSDs.

The system does not synchronously write every SQLite change to S3. Doing so would generate excessive PUT requests and expose object-storage latency to every write. Instead, its write path works as follows:

1. The write enters the SSD tier.
2. The system acknowledges durability after replicas in two of three availability zones have persisted it.
3. Data is batched to S3 in the background.
4. Reads use the SSD cache when available and fall back to object storage on a miss.

This separates durable-write acknowledgment from archival to object storage. Rivet reports p99 durable writes of 1.07 ms across three availability zones, p99 cached reads of 1.36 ms, and p99 object-storage reads of 138 ms.

The design introduces write amplification and a background synchronization window. Two-of-three-zone replication should preserve acknowledged data during a single-zone failure, but operators still need to verify that S3 and the replication logs can fully reconstruct state after permanent node loss.

Interpreting the Performance Claims

The 72 KB memory baseline and 4.9 ms startup latency demonstrate the efficiency of the actor abstraction, but they should not be extrapolated directly to a full agent. Production memory also includes model context, tool output, SQLite page cache, serialization buffers, and third-party dependencies.

Rivet says its storage can cost one-tenth as much as EBS gp3 while retaining SSD-like performance. That result depends heavily on object size, cache hit rate, SSD provisioning, S3 request patterns, and regional pricing. Workloads that repeatedly modify large POSIX filesystems can generate substantial background synchronization traffic; append-heavy workloads with high cold-data ratios are more favorable.

The reported millisecond storage latencies also do not represent end-to-end agent latency. Model inference, external tool calls, WebSocket serialization, and event-loop scheduling are often larger components of task duration. Capacity planning should therefore track active actors, completed tool calls per second, task latency, and total cost per completed workflow in addition to database metrics.

Trade-Offs Against Sandboxes and Durable Objects

Rivet's differentiator is not a new actor programming model by itself. It combines durable state, real-time collaboration, persistent artifacts, and a lightweight runtime for agents in a deployment model that can run locally, in a managed cloud, or inside a customer's VPC.

Compared with Cloudflare Durable Objects, Rivet offers deployment flexibility and self-hosting. The tradeoff is operational ownership: customers must manage upgrades, capacity, availability-zone configuration, and recovery. Compared with per-task sandboxes, actors reduce idle cost and cold-start latency, but they do not automatically reproduce sandbox-grade isolation.

Actors are a natural fit for agents that wait on tools, human input, or other agents. Sandboxes or microVMs remain preferable for untrusted code, kernel-level access, or strict tenant boundaries. Rivet is better understood as a control and state layer than as a universal replacement for execution isolation.

Deployment Recommendations

Rivet supports three deployment models: a self-hosted Rust binary using S3 as its only external dependency, dedicated clusters on AWS or GCP, and BYOC deployments inside the customer's VPC. Actors can be written in TypeScript or Rust, and the same lightweight runtime is used for local development and production.

A pragmatic rollout would:

• validate state transitions and measure peak active actors, idle ratios, and per-actor memory with non-sensitive workloads;
• move long-running inference and external tools into separate workers so actor event loops remain responsive;
• distinguish SQLite records that require immediate SSD durability from large artifacts suitable for background archival;
• track cache hit rate, S3 fallback frequency, synchronization backlog, and cross-zone recovery time;
• enforce network allowlists, filesystem permissions, resource quotas, and audit logs for generated-code execution;
• evaluate full task latency and cost per completed workflow rather than treating 72 KB memory and sub-millisecond storage operations as end-to-end agent benchmarks.

Rivet offers a useful middle ground between stateless functions and heavyweight sandboxes. Its strongest fit is stateful, collaborative agents that spend substantial time waiting rather than executing untrusted code. The headline numbers are promising but vendor-provided, so fault recovery, background synchronization consistency, real multi-tenant behavior, and security isolation still require independent validation.

---

Source: GitHub Projects via Hacker News (2026-11-05)

— END —

Tags: #Rivet Follow #Actor Model Follow #Agent Orchestration Follow #Tiered S3 Storage Follow #Rust Follow