Launch HN: Rivet (YC F25) – Scale and Orchestrate Agents on S3
https://github.com/rivet-dev/rivet
Hey HN, this is Nathan and Nicholas from Rivet (https://rivet.dev).Rivet is 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/
(I'm a professional developer but don't do any orchestration so trying to understand from basic mental model pov)
If you combine this with products like Sprites from Fly.io (or OSS version - agent substrate), where you pay only per execution request in a sandbox, you can have huge savings compare to the event loop inside the sanbdox. You will be billed only for request executions (tens of milliseconds per read/write, hundreds of milliseconds per search, etc.) and zero for all the waiting time during the the inference phase.
Also, if you don't require a real Linux sandbox — you might actually emulate the environment, e.g. just-bash idea with linux-like environment to give agents something that looks like their native habitat, but under the hood, it can be just CF Durable Objects SQLite or whatever else.
Probably(?) almost all knowledge work doesn't require a Linux sandbox. You can just build a document reading and editing agent that does tool calls and connects to other products via MCPs, APIs, etc. And lightweight actors make a lot of sense to me in these cases.
> Also, if you don't require a real Linux sandbox — you might actually emulate the environment
We built agentOS for this: https://rivet.dev/agentos/
It provides Linux-compatible sandboxing using V8 / WebAssembly. Supports full POSIX filesystems, networking stacks, and process trees.
> Wouldn't an agent in any capacity need a sandbox runtime to do agentic work?
Developers on Rivet use 3 different patterns:
- Just agents: many agents just need tools, such as customer support or personal agents
- Agents with lightweight sandbox: Rivet provides a V8 / WebAssembly sandboxing library for running JS & Python with a filesystem, which covers most workloads like data analysis, file processing, evals, and code mode (https://rivet.dev/agentos/)
- Agent outside of the sandbox: expose the sandbox to the agent as tools, which is better for blast radius, trust boundary, and orchestration (see below)
> Is the idea that state/memory/context and runtime env are separate concepts in rivet?
Exactly, Rivet Actors support running the harness outside of the sandbox. It's often referred to "separation of head from the hands."
I wrote a bit about why a while back: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...
> When you say "sandboxes are too slow" do you mean needing to boot the sandbox to get back Agent state?
Specifically coldstarts. As LLMs are getting faster and have more realtime use cases, sandboxes are become the bottleneck on time to interactive for an agent.
https://rivet.ironcladapp.com/
Instead, we provide an optional agent library that runs Pi Durable on top of actors (https://rivet.dev/agents/docs/quickstart/) or you can write your agent from scratch if you choose.
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.
> Have you had agents like claude code , codex etc all fully running in agent-os?
We have gotten them all working inside of agentOS. However, we found it's a better architecture to run the agent loop outside of agentOS and expose it as tools. The trust boundary & blast radius of running the agent inside the sandbox makes it difficult.
Also, the memory overhead of running individual Claude Code instances is nuts, it's better to run the agents in a single process using tools.
I wrote a bit more on it here: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...
> 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.
Appreciate it!
Rivet has a much different architecture than most S3-backed databases. Having an object-per-actor doesn't scale well with cost and performance, so we built a SSD tiered storage engine instead: https://rivet.dev/changelog/2026-10-26-introducing-rivet-3-0...
Ping me on Discord if you give it a try, would be fun to catch up: https://rivet.dev/discord
I would rather have lead with the durability aspect.
..and how you're doing anything with s3-backing durably and safely with latency numbers less than several hundred ms
> 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.
The other route for fast S3 writes others have used (Turso springs to mind) is express S3 zones but those have a lot of region specific fine print still.
It provides Linux-compatible sandboxing using V8 / WebAssembly. Supports full POSIX filesystems, networking stacks, and process trees. Security-wise, it's the same model as Cloudflare Workers & Chromium.
Rivet is frequently used for running the harness outside of the sandbox. Wrote a bit about why here: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...
> Sandboxes are expensive, mostly idle, and slow to start.
Many sandboxing startups would disagree. Do you have any numbers to support?
> Many sandboxing startups would disagree. Do you have any numbers to support?
There is no one-size-fits-all, but we're finding Rivet's benefits fit well for most agent workloads. I don't believe sandboxes are going away, but I think different workloads will move to specialized architectures.
Regarding cost, there are F500 companies using Rivet's tools for saving cost for use cases like RL.
Regarding coldstarts, it depends heavily on the use case, and there's not a one-size-fits-all. Benchmarks are pulled from Compute SDK sandbox benchmarks, more here: https://rivet.dev/docs/benchmarking/
We're big believers in lightweight sandboxing approachs akin to Durable Objects in addition to existing x86 sandboxes.
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.
I could be totally mistaken but that's my current understanding.
We also provide guides for every major cloud, and no special tuning is required as you add nodes.
If you’re self hosting and have questions, please let us know on Discord or GitHub! https://rivet.dev/discord
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.
I read "Rivet (https://rivet.dev) – a fast, high-density, and scalable orchestrator for agentic workloads using the actor model" and I think "I have no idea what this means, except it's a new way to make a backend service of some kind??"
I've reached an age where, if I don't understand what it is from your description, I'm not the problem.
“Actor” comes from established CS terminology [1], and agents-in-actors make sense in principle.
Agree with others in this thread that a few use-cases in the README would help me decide whether this is worth banging my head against or not.
[1] https://en.wikipedia.org/wiki/Actor_model
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.
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?
https://github.com/orgs/Latentpedia/discussions/4
Related work:
https://sigmodrecord.org/publications/sigmodRecord/1712/pdfs...
https://arxiv.org/abs/2301.01395
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?
I wonder when one approach will be used over the other.
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.