alt Hacker NewsLaunch HN: Rivet (YC W23) – Scale and Orchestrate Agents on S3
Hey HN, this is Nathan and Nicholas from Rivet (https://rivet.dev) – a fast, high-density, and scalable orchestrator for agentic workloads using the actor model. Rather than running a heavyweight sandbox per agent, each agent gets a lightweight actor backed by S3.
Actors provide a long-lived process for long agent turns, in-memory state for context, a WebSocket server for multiplayer, durable SQLite storage backed by S3, and hibernation when idle.
It's a similar model to Cloudflare Durable Objects, but it’s open source and self-hostable.
Here’s a video walkthrough: https://www.youtube.com/watch?v=3Ev6I7DOV9c
When we went through YC in 2023, we were building infrastructure for multiplayer games like Diep and Krunker. This involved heavily optimizing high-throughput matchmaking, real-time player messages, and blitz scaling. Through that process, we spent a lot of time on workloads where Postgres couldn't keep up with our throughput. We started out by hacking together Lua scripts on top of Redis, but this became too cumbersome to maintain and upgrade. This led us to extend our game server orchestrator to support what we call Rivet Actors today: many lightweight workers with in-memory state and durable storage. By using actors, we were able to serve tens of millions of monthly active users.
As agents grew in popularity, it became clear that running agents in sandboxes is inefficient. Sandboxes are expensive, mostly idle, and slow to start. Developers started using actors because they are far more memory efficient (72 KB baseline for actors vs 512 MB for a minimal sandbox) and fast to start (4.9 ms p99 for actors vs 1.7 s p99 for sandboxes).
For example, Amp is using Rivet to orchestrate multiplayer agents. They originally tried to build on Cloudflare Durable Objects, but couldn’t launch because of the platform’s limitations and unresponsive support. They migrated to Rivet Actors in a weekend and deploy on-prem. Rivet’s flexible architecture lets them adapt it to their own use cases without being constrained by a framework or the memory, storage, and runtime limits of Cloudflare Durable Objects.
Under the hood, Rivet is backed by S3 while maintaining SSD speeds.
Why S3? Previously, Rivet ran on FoundationDB. However, we were surprised to find that companies are storing orders of magnitude more data on Rivet Actors than in Postgres, such as large session transcripts, agent artifacts, and full POSIX filesystems. As their data grew, they had to start paying for SSDs that sat mostly idle with old transcripts. This led us to double down on S3 as our primary storage medium without sacrificing performance. This choice means that data stored on Rivet is 10× cheaper than on EBS gp3 while maintaining SSD speeds.
It’s not as simple as writing data straight to S3. Lots of PUTs for tiny blobs of data are slow and expensive. Instead, we use an SSD tier to optimize speed and cost:
When you write data to an actor’s SQLite database, the write is acknowledged once SSDs in 2 of 3 availability zones have it. Then, the data is batched to S3 in the background. This means that S3 is never on the write path, which lowers latency and cost. When reading data or waking an actor, Rivet reads from SSDs if already cached and falls back to S3 if not. SSD caches can be tuned to meet your needs, giving you configurable tiered storage for your actors.
This architecture lets Rivet provide 1.07 ms durable writes (3 AZ, p99), 1.36 ms reads (p99), and 138 ms reads from object storage (p99).
We’ve spent a lot of time making sure that Rivet can run wherever you need it. Self-hosting requires deploying a single Rust binary with S3 as the only dependency, Rivet Cloud lets you deploy dedicated clusters on AWS or GCP in any region, and BYOC lets us deploy Rivet to your VPC without having to operate it yourself. Rivet also runs identically in local dev as in production, since Rivet is a lightweight binary that runs anywhere
Rivet Actors can be written in TypeScript or Rust. Out of the box, they support agents (Pi Durable), workflows, real-time, multiplayer, running AI-generated code, Durable Streams, and integrations with tools like Vercel’s Eve and Turso. See all of our available guides, or point your agent at them: https://rivet.dev/docs/#guides
Try it out now, by reading our quickstart guides (https://rivet.dev/docs/) or ask your agent: “Run npx skills add rivet-dev/skills, then build a multiplayer chat agent and run it locally.”
We’d love to get feedback on your experience with Rivet! We’re deeply invested in making Rivet an easy-to-self-host, flexible, and efficient way to run agentic workloads.
GitHub: https://github.com/rivet-dev/rivet
Architecture: https://rivet.dev/docs/architecture/
Benchmarks: https://rivet.dev/docs/benchmarking/
Self-hosting: https://rivet.dev/docs/deploy/self-host/
Comments
One thing that bit me running long agent workflows: hibernate/resume is great until tool results aren't part of the durable snapshot. If the actor wakes from SQLite alone and the previous turn's tool payload lived only in memory (or a temp file), the next step invents a confident continuation. We ended up treating "resume" as unsafe unless the last tool I/O was written into the same durable store as the conversation before suspend. Density numbers matter less than whether wake always reconstitutes enough to refuse to continue when that evidence is missing.
Love that architecture. I’m becoming a major fan of SQLite for agents to work with. I wonder if you looked at Cloudlfares D1 as an option. For myself, I built an easy mcp for my agents to run SQLite databases which I’m finding mostly useful for scheduled agents in Claude, they have stuff to keep track of. https://getairdash.com if anyone wants to try that out (it’s free, cloudflare is very very cheap)
Curious how hibernation works across a multi-minute agent turn with tool calls in between. When the actor wakes, is conversation state just the SQLite snapshot, or do you keep a warm in-memory buffer for the active turn? Also would love a rough density number—actors per host—for a coding-agent style workload with a WebSocket client attached.
Rivet is very cool. Switched a Cloudflare Durable Object piece of our infrastructure that lived in its own little fairy tale land to our own infra within the rest of our VPC. Was a very pleasant experience.
Haven't had the chance to try Rivet v3 yet but hoping to get to it soon.
The hard part for me has not been getting agents to write code. It has been keeping a bunch of long-running ones alive without burning through quota every few hours. Suspend/resume and cost tracking that I do not have to build myself would help.
Not using the actor model, and yet massively parallel: https://gnosh.ai/swarm.html
I wonder when one approach will be used over the other. Actually, I can imagine both approaches working together.
Just filed two provisional patents on this stuff today; build on gno.land and let's talk shop, I see symbiosis.
Fascinating architecture—treating agent turns as persistent lightweight actors backed by tiered SQLite/S3 rather than spinning up dedicated VMs makes a lot of sense for latency and cost.
For workflows that inevitably require arbitrary shell execution or local compiler tools (like coding agents running tests), do you envision delegating just the side-effect execution out to ephemeral runners while keeping the stateful actor long-lived, or is Rivet primarily focused on API/tool-calling agents?
Distributed actors are also good platforms to run graph algorithms. We're evaluating Rivet as a potential substrate to run page rank and clustering algorithms on large graphs, while supporting cypher queries over the result.
https://github.com/orgs/Latentpedia/discussions/4
Related work:
https://sigmodrecord.org/publications/sigmodRecord/1712/pdfs...
How does hibernation decide an actor is idle? In my agent runtime actors run in XS. Messages are queued and only handled once the current handler returns, so a synchronous handler is never cut in half. But while a handler waits on an async call, an HTTP request say, other messages still get handled. So “no message being processed” isn’t the same as “nothing in flight”. Does Rivet hibernate an actor with an outstanding request, and if so, what happens when the response comes back?
Even as someone who’s very involved in the space, I don’t understand what you guys do. It’d be helpful if your website led with the problem you’re solving instead of technical benchmarks.
I also don’t really understand the distinction between an actor and an agent. I’ve never heard anyone call them actors, and I doubt you’ll win that mindshare as a small startup.
Hey Nathan! You build a fantastic product and your tech seems rock solid. I think you would benefit from more use-case specific tutorials and how-to guides so that people find and use your product for the applications that it's a great fit for. Multi-agent systems, code review agents, software factories, etc.
More so than ever, folks are choosing to build rather than buy -- you should emphasize that your product lets teams avoid having to choose by handling the "boring" parts for them and letting them focus on the parts that are unique to their business.
Moving state persistence to write-ahead SQLite tiered into S3 is a very clean answer to the latency-cost trap of raw object storage. The big operational win with decoupled actor state like this is avoiding zombie locks when an agent execution times out mid-turn. Curious how you handle split-brain fencing if an actor network partition occurs while a batched write is still draining to S3.
Hey Nathan! I remember Rivet from Playflow, back when you guys did game server orchestration. Great to see you guys grow!
Have you had agents like claude code , codex etc all fully running in agent-os? Trying to understand the use case a bit better here. For context, I've recently built our own pipeline which spins up ephemeral linux vms for claude code, codex, etc which do their work & the state always persists but frees up resources when finished. Is the idea pretty much similar for agent-os here?
Also with the s3 backing changes, it reminds me a lot of the work done on celld, good to see more self-hostable durable objects out there.
Love the actor model approach here. Hibernating idle agents while keeping state durable in S3 is a huge win for cost.
Curious how Rivet handles the runaway loop problem though. When you have long-lived actors passing messages to each other, a simple state bug can cause them to ping-pong the exact same payload indefinitely.
Because the actors stay alive and keep responding (returning 200s), your infra looks perfectly healthy, but the developer's OpenAI bill just exploded in the background.
Are you leaving loop detection entirely to the devs building on top of Rivet, or is there any native circuit breaker at the orchestrator level to kill an actor that's stuck in a cyclic state?
Congrats on the launch! Rivet seems neat; will definitely give it a spin.
> Sandboxes are expensive, mostly idle, and slow to start.
Many sandboxing startups would disagree. Do you have any numbers to support?
Same problem here. Internally we simulated it with just-bash plus whatever filesystem was handy. For production we went with DO after surveying their agent ecosystem, but it has since split into two paths (@cloudflare/agents or think vs. @cloudflare/computer) with real trade-offs. Rivet's s3 setup looks like a much closer fit for us — I'd want to try it on the next project.
Congrats! How is the security posture? Without really comparing isolation and sandboxing etc.. comparing with E2B is not the same.
Wouldn't an agent in any capacity need a sandbox runtime to do agentic work? When you say "sandboxes are too slow" do you mean needing to boot the sandbox to get back Agent state? Is the idea that state/memory/context and runtime env are separate concepts in rivet?
(I'm a professional developer but don't do any orchestration so trying to understand from basic mental model pov)
Congrats on the launch! The explanation of keeping S3 off the write path made the storage model much easier to understand. For someone starting with a small self-hosted deployment, what tends to be the first operational challenge as usage grows?
Congratz on the launch! I love how efficient this is - I'm pretty sure more agents will be built this way than having the heavy sandbox. Quick note, in the README on GH there's a link to https://github.com/rivet-dev/rivet/blob/main/engine/packages... which doesn't lead anywhere.
What if I just want self-hostable TypeScript actors _without agents_? I'm a long-time fan of Akka et. al., but to my knowledge Node never got a proper framework.
This is soooo cool! Awesome!
You mention support for Turso, like we could use Turso instead of sqlite?
Amazing work though, definitely will be following with keen interest and likely adopting it! Love that the genesis came from trials and tribulations for game dev.
Keeping S3 off the write path is the design choice that makes the whole pitch click for me: acknowledging a write once two of three availability zones have it on SSD, then batching to object storage in the background, gets durability without paying object-storage latency on every turn. That also explains why separating the agent loop from the sandbox matters, since a long-running turn shouldn't have to keep a heavyweight environment warm just to hold its state. My main question is how that tiering behaves when an actor wakes after a long idle period and its data has fully cooled to S3: is that 138 ms read the typical cost, or does it get worse with larger session transcripts and filesystems?
Been running Rivet v3 self-hosted on AWS and it's dope!
Interesting idea, horrible ux atm though, my codex/claude whatever is just as confused as me what and how are we supposed to use it exactly and all the edge cases. Hope you folks can figure out some interesting ideas to improve it though.
My first reaction: this is weird; agentic workloads have many problems but orchestration speed ain't one of them. You spend most of the time waiting for the model! Is this for small models?
I would have lead with the durability aspect.
looks cool - I'm curious how this is similar / different from celld
..and how you're doing anything with s3-backing durably and safely with latency numbers less than several hundred ms
[dead]
[dead]
Ooh, so mod_rivet is getting funding? That's great. Tcl does not get enough love these days.
Ah, another rivet. I initially thought it was a pivot of:
> When you write data to an actor’s SQLite database, the write is acknowledged once SSDs in 2 of 3 availability zones have it. Then, the data is batched to S3 in the background. This means that S3 is never on the write path, which lowers latency and cost. When reading data or waking an actor, Rivet reads from SSDs if already cached and falls back to S3 if not. SSD caches can be tuned to meet your needs, giving you configurable tiered storage for your actors.
As someone who is not incredibly deep in the agent space, but works a lot on scientific and distributed computing, this really caught my eye. Seems like this is primarily part of the cloud offering, but a true posix compatible filesystem that interops cleanly with S3 on the backend would be an incredibly interesting product (especially if it were open-sourced).
A brief sidenote: I did a triple take when I saw the name because Rivet is the internal name of our long-running job queue service. You all have great taste.