Introducing Rivet BYOC ☁️ for AWS and Google Your data never leaves your security perimeter. Your entire agent infrastructure is in your VPC. Manage from the Rivet dashboard. rivet.dev/changelog/2026-09-…

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…

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 $ 𝚗𝚙𝚖 𝚒𝚗𝚜𝚝𝚊𝚕𝚕 𝚜𝚎𝚌𝚞𝚛𝚎-𝚎𝚡𝚎𝚌

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!