549 karma · joined September 16, 2016
https://rivet.dev
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
We're big believers in lightweight sandboxing approachs akin to Durable Objects in addition to existing x86 sandboxes.
> 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/
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...
> 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
> 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.
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.
> 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.
Allows you to compile most C or Rust programs to run in it without modification. Also can run Claude Code, Codex, Pi, and OpenCode unmodified.
Working on polishing, security, and documentation so I can share an in-depth deep dive on HN.
We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.
In our experience, most apps don't need cross-tenant queries outside of BI. For example, think about the apps you use on a daily basis: Linear, Slack, ChatGPT all fit well with an actor-per-workspace or actor-per-thread model.
To be clear, we're not trying to replace Postgres. We're focused on modern workloads like AI, realtime, and SaaS apps where per-tenant & per-agent databases are a natural fit.
Using SQLite for your per-tenant or per-agent databases has a lot of benefits:
- Compute + state: running the SQLite database embedded in the actor has performance benefits
- Security: solutions like RLS are a security nightmare, much easier to have peace of mind with full DB isolation per tenant
- Per-tenant isolation: important for SaaS platforms, better for security & performance
- Noisy neighbors: limits the blast radius of a noisy neighbor or bad query to a single tenant's database
- Enables different schemas for every tenant
- AI-generated backends: modern use cases often require AI-generated apps to have their own custom databases; this model makes that easy
A few other points of reference in the space:
- Cloudflare Durable Objects & Agents are built on this model, and much of Cloudflare's internal architecture is built on DO
- https://neon.com/use-cases/database-per-tenant
- https://turso.tech/multi-tenancy
- Val.town & Replit
> Better usage of resources
I'd be curious to hear more about what you mean by this.
> always allows a parent style agent do complex queries
Do you have a specific use case in mind where agents need to query other agents' data?
However, we are planning on building a query engine that can operate over multiple databases. One option we're considering is exposing Rivet SQLite as a DuckDB datasource: https://duckdb.org/docs/stable/data/data_sources
- TUI (I prefer this for most programming)
- Web UI (negligible difference than VS Code)
- Mobile support (via web UI)
- TypeScript SDK to automate
(Sprites.dev in the works already.)
Posted this morning an overview of the project: https://x.com/NathanFlurry/status/2018366627021291699
As you said – in terms of project goals, the biggest difference is:
- ACP seems to be focused on providing a universal API for the subset of features required for editors
- Sandbox Agent SDK is focused on automating agents, so aims to provide a much more comprehensive API coverage for niche agent-specific features
We maintain a feature coverage matrix (https://sandboxagent.dev/docs/session-transcript-schema#cove...) – it's early, much more coming soon.
Hacked together an SF parks ranking system based on current weather