How Rivet Achieves High Density and Fast Cold Starts

Rivet gets its density from where an Actor runs, not from a smaller container. An Actor lives inside a worker process you already run rather than in its own container or VM, so a server that held hundreds of pods can hold hundreds of thousands of Actors. Rivet states this yields 2,829× more workloads per server, with roughly 72.4 KB of RSS increase per running Actor and about 12 ms cold starts. Those are the vendor's own figures, so treat them as a design target to validate against your workload rather than a guaranteed result.

The mechanism: Actors share your worker process

The key architectural choice is that Rivet does not give each Actor its own isolation boundary at the OS level. Instead, many Actors are multiplexed inside a single worker process. That changes the cost model in two ways:

• Memory: you pay a small per-Actor increment (72.4 KB RSS per running Actor in Rivet's measurement) instead of a full container or VM footprint.
• Startup: because there is no container to schedule, pull, or boot, an Actor can start in milliseconds. Rivet cites 12 ms cold starts.

The density claim follows directly: if hundreds of pods fit on a server, and each pod's resources can instead host many lightweight Actors, the ceiling moves from hundreds to hundreds of thousands. The 2,829× figure is Rivet's comparison of workloads per server under this model.

What this means for cost and concurrency

If your bottleneck is per-instance overhead — many small, mostly idle, or bursty units of work — the shared-process model is where the savings come from. You are trading OS-level isolation per unit for a much lower per-unit cost. That trade is favorable when you have a large number of short-lived or low-utilization workloads, and less relevant when each workload genuinely needs its own container or VM.

What runs as an Actor

Rivet frames Actors as the durable process an agent lives in, and lists several workload types that map onto the same density model:

Because all of these run as Actors, the density and cold-start characteristics apply across them. A per-user backend or a per-agent process is exactly the kind of many-small-units pattern the shared-process model is built for.

When the density advantage matters

Use this as a decision filter:

• Fits well: large numbers of agents, per-user backends, or workflow instances that are bursty or lightly loaded, where container-per-unit overhead would dominate cost.
• Check carefully: workloads that need hard isolation between tenants at the OS level, or that are consistently CPU/memory-heavy per unit — in those cases the shared-process savings shrink and isolation requirements may push you back toward containers or VMs.
• Verify before committing: the 2,829×, 72.4 KB, and 12 ms numbers are Rivet's published figures. Reproduce them with your own Actor sizes and load profile, since real RSS per Actor depends on what your code allocates.

Getting started and verifying

Rivet is open-source and self-hostable, so you can measure the density claims on your own hardware. The documented entry point is:

npx skills add rivet-dev/skills

Rivet describes this as something you give to your coding agent. After setup, the practical validation steps are:

1. Run a representative Actor workload and record baseline RSS.
2. Scale the number of running Actors and measure the RSS increase per Actor against the 72.4 KB reference.
3. Measure cold-start latency under your load against the 12 ms reference.
4. Compare workloads-per-server against your current container or VM setup.

If your measured per-Actor overhead and cold starts land near Rivet's figures, the density argument holds for your use case. If they diverge, the gap usually traces back to how much state and memory each of your Actors holds.