|
| 1 | +--- |
| 2 | +author: nathan-flurry |
| 3 | +published: "2026-06-19" |
| 4 | +category: changelog |
| 5 | +image: true |
| 6 | +keywords: ["secure-exec", "sandbox", "rust", "code-execution", "bun", "isolation", "virtual-kernel", "process-trees", "ai-agents"] |
| 7 | +title: "Secure Exec v0.3" |
| 8 | +description: "A full Rust rewrite of Secure Exec including process isolation, Bun support, and more." |
| 9 | +--- |
| 10 | + |
| 11 | +[Secure Exec](https://secureexec.dev) is secure Node.js execution without a sandbox: no containers, no VMs, just npm-compatible isolation out of the box. v0.3 is a ground-up rewrite of the runtime in Rust, now running as its own isolated sidecar process for stronger isolation, leaner resource usage, and a clean path to running it from any language. |
| 12 | + |
| 13 | +## A Full Rewrite in Rust |
| 14 | + |
| 15 | +We rewrote the entire runtime in Rust. Secure Exec now runs as a standalone sidecar process over a Unix socket. |
| 16 | + |
| 17 | +- **Process isolation.** Guest code runs in a separate process, so everything it does, from filesystem reads to network calls, never touches the host process. |
| 18 | +- **No Node.js overhead.** Filesystem, network, and module resolution all run natively in Rust. Previously the host TypeScript had to handle every one of these operations, which was expensive. |
| 19 | +- **Better security.** A Rust core makes it far easier to reason about DoS exploits and resource bottlenecks than the previous TypeScript runtime. |
| 20 | +- **Language-agnostic.** Because the runtime is just a process behind a Unix socket, it is no longer tied to Node.js. Any language can drive it. |
| 21 | + |
| 22 | +## Bun Support |
| 23 | + |
| 24 | +Previously, Secure Exec ran V8 inside the Node process itself, so it required Node.js and was limited to specific versions. |
| 25 | + |
| 26 | +- **Now it is a separate process.** Your program talks to the sidecar over a Unix-socket WebSocket instead of loading V8 in-process. |
| 27 | +- **Bun works out of the box.** You can drive Secure Exec from [Bun](https://bun.sh), even though Bun uses JavaScriptCore, while the sidecar keeps running guest code on V8. |
| 28 | + |
| 29 | +## Rust SDK |
| 30 | + |
| 31 | +The sidecar is the engine that runs guest code; the new Rust SDK is the native client library your program uses to drive it. It is a highly portable way to work with Secure Exec from any language. |
| 32 | + |
| 33 | +- **Native client.** The crates speak the sidecar's wire protocol directly, with no Node.js in the loop, so you can embed Secure Exec straight into a Rust program. |
| 34 | +- **Easy bindings.** Use the SDK as the foundation for first-class bindings in your language of choice, for example Python via [PyO3](https://pyo3.rs), Go via cgo, and beyond. |
| 35 | + |
| 36 | +## Process Trees |
| 37 | + |
| 38 | +Secure Exec can now run full process trees, all inside the virtual kernel. |
| 39 | + |
| 40 | +- **Child processes.** Spawn child processes and pipe data between them. |
| 41 | +- **Servers.** Run long-lived servers, with traffic routed through the runtime's own virtual network stack. |
| 42 | +- **No host exposure.** Nothing maps to real host processes, so you get full process-tree semantics without touching the host. |
| 43 | + |
| 44 | +## Granular Resource Caps |
| 45 | + |
| 46 | +Untrusted code should never be able to exhaust the host. v0.3 enforces resource caps at the VM level, with sane defaults out of the box, so no single guest can run away with unbounded memory, disk, CPU, or I/O. |
| 47 | + |
| 48 | +- **Execution timeout.** Bound how long a guest may run; a runaway program is killed when the budget elapses. |
| 49 | +- **Memory.** A V8 heap limit caps how much memory guest JavaScript can allocate. |
| 50 | +- **Filesystem.** Byte and inode caps bound the virtual filesystem. |
| 51 | +- **Payload and transfer.** Caps on captured output, stdin buffering, event payload size, and `fetch()` response size bound how much data moves between guest and host. |
| 52 | +- **CPU time.** A CPU-time budget bounds core usage and blocking read time independently of the wall-clock timeout. |
| 53 | + |
| 54 | +## Configurable Runtime Surface |
| 55 | + |
| 56 | +By default, guests run with the full Node.js surface. v0.3 lets you scale that down a platform ladder, all the way to a nodeless `bare` runtime that exposes only the language and the core security layer. |
| 57 | + |
| 58 | +| Capability | `node` | `browser` | `neutral` | `bare` | |
| 59 | +|---|:---:|:---:|:---:|:---:| |
| 60 | +| Node globals | ✅ | No | No | No | |
| 61 | +| `node:*` builtins | ✅ | No | No | No | |
| 62 | +| Node identity | ✅ | No | No | No | |
| 63 | +| Web platform | ✅ | ✅ | No | No | |
| 64 | +| Universal primitives | ✅ | ✅ | ✅ | No | |
| 65 | +| Language + Wasm | ✅ | ✅ | ✅ | ✅ | |
| 66 | + |
| 67 | +Set the platform with a `jsRuntime` config when you create a VM, or omit it for full Node. Two independent knobs sit alongside it: `moduleResolution` controls how imports resolve, and `allowedBuiltins` restricts which `node:*` modules the guest can import. |
| 68 | + |
| 69 | +| `moduleResolution` | `import "pkg"` | `import "./x.js"` | `node:*` | |
| 70 | +|---|:---:|:---:|:---:| |
| 71 | +| `node` (default) | ✅ | ✅ | ✅ | |
| 72 | +| `relative` | No | ✅ | No | |
| 73 | +| `none` | No | No | No | |
| 74 | + |
| 75 | +## Get Started |
| 76 | + |
| 77 | +```bash |
| 78 | +npm install secure-exec |
| 79 | +``` |
| 80 | + |
| 81 | +- [Quickstart](https://secureexec.dev/docs/quickstart) |
| 82 | +- [Documentation](https://secureexec.dev/docs) |
| 83 | +- [GitHub](https://github.com/rivet-dev/secure-exec) |
| 84 | +- [Discord](https://rivet.dev/discord) |
0 commit comments