infrastructure for the agentic era. Orchestrate agents. Operate their environment. Automate workloads. Deploy what they build.
San Francisco, CA
Joined September 2019
- Tweets396
- Following2
- Followers5.4K
- Likes256
Rivet retweeted
In the next version of Rivet:
🔻 25% less RAM on RivetKit (JS)
🔻 33% less RAM on the control plane under SQLite load
Rivet retweeted
S3 is the only dependency in Rivet 3.0 (coming soon)
It's architected for easy self-hosting and embedding in your own apps
But that also meant getting rid of NATS....
Rivet retweeted
Running the harness outside of the sandbox is dirt cheap!
For example, Pi on Rivet Actors takes ~0.8 MB of RAM per active session
+ starts in tens of milliseconds
+ hibernates when idle
~~~
How?
When running an agent in a sandbox, you're paying for the overhead of an entire Node.js process for each session
That's usually hundreds of MB for every single agent session, plus multiple seconds to actually start up
When you run the harness within your own backend, you have a single process that can run hundres of agents per process
That means you've already paid for the fixed overhead of running Node.js (the hundreds of MB)
And each new agent session is just a few JS objects in memory
~~~
If you look at the graph, there's a baseline of 223 MB for the base Node.js process + imported libraries, but each new session takes only 0.82 MB
Granted, this depends heavily on how much of the session you keep in memory. Real-world results are going to be higher, but not by much since text doesn't take much memory.
Benchmark: github.com/rivet-dev/actors/…
~~~
In terms of security, the agent doesn't have access to the host it's running on
Instead, it's given tools that can talk to an external sandbox on demand
Read more about how to do this here: rivet.dev/blog/2026-07-27-ru…
Rivet retweeted
Secure Exec SDK got a huge refresh
(secure Node.js execution w/o a sandbox)
💅 Simpler API, host fns, TypeScript checking
⌛ 𝚌𝚛𝚎𝚊𝚝𝚎𝚅𝚖() for long-running processes & fs
📦 Dynamically install NPM pkgs
$ 𝚗𝚙𝚖 𝚒𝚗𝚜𝚝𝚊𝚕𝚕 𝚜𝚎𝚌𝚞𝚛𝚎-𝚎𝚡𝚎𝚌
Rivet retweeted
Very excited for the launch!
Getting questions on how Secure Exec / agentOS compares:
Both let you run untrusted JS as a library, without creating a heavy Linux sandbox.
But, they have different scopes:
→ Secure Exec provides access to a sandboxed fs / net / shell
→ secure-eval-worker only allows for Node.js without full fs / net / shell.
This means Secure Exec can run most Node.js libraries (and CLIs!) out of the box.
(Including Next.js, npm, esbuild, git, etc)
~~~
How does Secure Exec do this?
Secure Exec / agentOS provide a "virtual operating system."
It's a Linux-compatible OS that lives in the library (in userspace) that gives Node.js sandboxed access to:
- Filesystem
- Network requests (e.g. fetch / WebSockets / TCP)
- Run servers (e.g. Next / Hono)
- Shell commands
- Process trees
None of the sensitive functionality touches the host unless you explicitly allow it.
It also enables powerful functionality like:
- User-generated HTTP servers
- Mounting anything as a filesystem (S3, GDrive, host, etc)
- Injecting tokens for incoming & outgoing requests
- Dynamically install NPM packages
- Have agents fetch HTTP requests from another server inside the same context
Out of the box, it supports just about everything you'd expect:
- TypeScript (full tsc)
- Next.js
- npm (yes, really)
- React
- Astro
- esbuild (wasm)
- git (via agentOS)
- Express / Hono
(secure-eval-worker does support read-only access to a filesystem)
~~~
Secure Exec also provides full TypeScript type checking.
This allows your agents to:
Generate code → check types → feed errors back in to LLM → repeat
~~~
Secure Exec also has a different security boundary.
Secure Exec is modeled after Cloudflare Workers & Chromium's architecture.
It focuses on providing layers of security without impacting performance & compatibility.
Currently, secure-eval-worker runs in the same process as your host application.
Secure Exec has a few extra security boundaries:
- Runs in a separate, dedicated process from your application code
- Process can be jailed with additional OS-level isolation
- Tenants can be isolated by process optionally
~~~
Do you need a full OS?
Not all use cases do.
But the more of POSIX and more flexibility you give your agents, the faster & more efficient they work.
We've seen a lot of companies basically re-implement a slower filesystem and switch to Secure Exec / agentOS to get more mature POSIX compliance & feature set.
e.g. just binding host tools to S3 or Google Drive tends to grind to a halt.
~~~
Other features that both support:
- Long-running contexts / sessions
- Host tools / callbacks
- Async JavaScript execution
- TypeScript execution
- Execution timeouts and cancellation
- Configurable V8 memory limits
- Structured inputs and return values
- ES modules and compatible supplied dependencies
~~~
Would it be possible for us to use secure-eval-worker with Secure Exec / agentOS's virtual OS?
Maybe, but it'd take significant work forking and binding to the Node.js fs / net / proc APIs.
People have experimented with this before, but my hunch is we can provide better security + performance keeping this under one roof.
~~~
The hardest part of building this is building a new runtime loop that can prevent resource exhaustion from the guest.
It took us a long time to get this right in Secure Exec, it's fun to see we landed on a similar architecture.
~~~
Congrats on the launch, been hoping to see something like this in Node.js for a while!
Running JavaScript at runtime is everywhere now: AI-generated changes, user automation, plugins, programmable app parts. The problem is that a regular `eval()` inherits all the host's permissions.
Today we're introducing @platformatic's new library, `secure-eval-worker`, which runs JS in Node.js workers with only the permissions you choose.
Rivet retweeted
If you're on Rivet Actors / Workflows (open-source Durable Objects alternative)
We've supported this for a while. Each branch gives:
- Isolated Actors / Workflows / agentOS
- Dedicated preview hostname
- Scales to 0, costs nothing
- Separated in billing
- Works with BYOC or Rivet-managed actors
Rivet retweeted
bilis can now spot errors from your logs, autofix & open pr. Powered by agentOS from @rivet_dev
Rivet retweeted
Rivet 🤝 Turso
I love what happens when tools are build in open standards (SQLite) + plugability
𝚗𝚙𝚖 𝚒𝚗𝚜𝚝𝚊𝚕𝚕 @𝚝𝚞𝚛𝚜𝚘𝚍𝚊𝚝𝚊𝚋𝚊𝚜𝚎/𝚛𝚒𝚟𝚎𝚝-𝚎𝚡𝚙𝚎𝚛𝚒𝚖𝚎𝚗𝚝𝚊𝚕
The @rivet_dev team did an amazing job with the SQLite support internals that building a Turso Cloud integration was a breeze! Nice work @NathanFlurry and the team!
Rivet retweeted
“Harness outside of sandbox” is absolutely the right pattern, but very difficult w/ stateless HTTP
Highly recommend trying Rivet Actors for this:
- Stateful
- Schedules + workflows + multiplayer
- Sqlite DB per agent
- Durable
- Sleeps when idle
- OSS & self-hostable
Rivet retweeted
🔮 Agents won't run in Linux sandboxes in 3 months
Worth watching:
- @LangChain's experiments
- @rivet_dev's agentOS for WASM-based sandboxing
- @CloudflareDev's Project Think using V8 isolates
- @vercel_dev's just-bash for Bash-in-JS
Links below 🧵
Rivet retweeted
Memory of coding harnesses in agentOS (portable WASM OS for agents):
🥇 Codex (WASM): 122 MB
🥈 Pi (V8): 153 MB
🥉 Claude Code (V8): 316 MB
OpenCode & Amp coming soon
This is the memory for the *entire* VM, including bash, Node.js, Python, git fully loaded
Rivet retweeted
🤘 Rivet Secure Exec (V8 isolates):
Securely execute Node.js anywhere (Railway, Vercel, Hetzner, Kubernetes)
vs
🔥 Firecracker (microVMs):
Full Linux operating system, but requires specialized infrastructure
Rivet retweeted
Rivet Secure Exec v0.2.0 just got more secure
Process isolation now separates Node.js instances from the host
- Security → improved isolation against V8 0-days
- OOM protection → in case of over-provision
- Bun support → no longer tied to embedded V8
All written in Rust 🦀
