Secure Node.js Execution Without a Sandbox

A lightweight library for secure Node.js execution.
No containers, no VMs — just npm-compatible sandboxing out of the box.
Powered by the same tech as Cloudflare Workers.

Documentation — SDK Overview — Discord

npm install secure-exec

Why Secure Exec

Give your AI agent the ability to write and run code safely.

• No infrastructure required — No Docker daemon, no hypervisor, no orchestrator. Runs anywhere Node.js, Bun, or an HTML5 browser runs. Deploy to Lambda, a VPS, or a static site — your existing deployment works.
• Node.js & npm compatibility — fs, child_process, http, dns, process, os — bridged to real host capabilities, not stubbed. Run Express, Hono, Next.js, and any npm package.
• Built for AI agents — Give your AI agent the ability to write and run code safely. Works with the Vercel AI SDK, LangChain, and any tool-use framework.
• Deny-by-default permissions — Filesystem, network, child processes, and env vars are all blocked unless explicitly allowed. Permissions are composable functions — grant read but not write, allow fetch but block spawn.
• Configurable resource limits — CPU time budgets and memory caps. Runaway code is terminated deterministically — no OOM crashes, no infinite loops, no host exhaustion.
• Powered by V8 isolates — The same isolation primitive behind Cloudflare Workers for Platforms and every browser tab. Battle-tested at scale by the infrastructure you already trust.

Features

• TypeScript — Compile and type-check TypeScript inside the sandbox.
• Permissions — Control what sandboxed code can access on the host.
• Filesystem & Mounts — Filesystem backends for sandboxed code.
• Virtual Filesystem — A fully virtual filesystem inside the kernel, isolated from the host disk.
• Networking — Network access for sandboxed code.
• NPM & Module Loading — How sandboxed code resolves and loads modules.
• Runtime & Platform — The host environment guest code sees, plus the platform ladder.
• Output Capture — Capture console output from sandboxed code.
• Resource Limits — Bound and cancel guest execution with timeouts, memory, and CPU-time limits.
• Child Processes — Spawn child processes from sandboxed code.

Quickstart

1. Install

npm install secure-exec

2. Create a runtime

NodeRuntime.create() boots a fully virtualized VM behind the native sidecar. Guest code runs inside the kernel isolation boundary with no host escapes. All options are optional: cwd defaults to /home/user, and permissions default to a secure policy that denies network access (see step 4).

import { NodeRuntime } from "secure-exec";

const runtime = await NodeRuntime.create();

3. Run code

Use run() when you want a JSON value back; the guest calls globalThis.__return(value) to set it. Use exec() when you care about side effects and want to capture stdout/stderr/exitCode. Guest code runs as an ES module, so import and top-level await both work.

import { NodeRuntime } from "secure-exec";

// Boot a fully virtualized runtime. Guest code runs inside the kernel
// isolation boundary - no host escapes.
const runtime = await NodeRuntime.create();

try {
  // run() executes guest JavaScript as an ES module and returns the value the
  // guest passes to globalThis.__return(). stdout/stderr are captured too.
  const result = await runtime.run<{ message: string; sum: number }>(`
    console.log("hello from secure-exec");
    __return({ message: "hello from secure-exec", sum: 1 + 2 });
  `);

  console.log("stdout:", JSON.stringify(result.stdout.trim()));
  console.log("value:", result.value);
  console.log("exitCode:", result.exitCode);
} finally {
  // Tear down the VM and release the sidecar.
  await runtime.dispose();
}

4. Configure permissions (optional)

Guest code is deny-by-default: the sandbox has no network access until you opt in (the filesystem and processes are fully virtualized and never touch the host). Pass a permissions policy to NodeRuntime.create() to open up capabilities. It merges over the secure default, so you only specify what you want to change.

const runtime = await NodeRuntime.create({
  permissions: {
    // Virtualized and enabled by default (these never touch the host):
    fs: "allow",           // the in-VM filesystem
    childProcess: "allow", // spawning processes inside the VM
    process: "allow",      // process info (pid, cwd, ...)
    env: "allow",          // environment variables
    // Denied by default - opt in explicitly:
    network: "allow",      // outbound network access
    tool: "allow",         // host callbacks
  },
});

Set any scope to "deny" to lock it down. See Permissions to learn more.

See the full quickstart →

Secure Exec vs. Sandboxes

Not every workload needs a full OS. Secure Exec gives you V8-level isolation for code execution — no container required.

• Secure Exec — Run untrusted code (Node.js, Python) inside your backend process
• Sandboxes — Spin up a full OS with root access, system packages, and persistent disk

	Secure Exec	Sandbox
Performance	✅ Native V8	✅ Native container
Permissions	✅ Granular deny-by-default	❌ Coarse-grained
Setup	✅ Just npm install — no vendor account	❌ Vendor account required
Infrastructure	✅ Run on any cloud or hardware	❌ Hardware lock-in
Egress	✅ No egress fees	❌ Per-GB egress fees
API keys	✅ None	❌ Required

Full comparison guide →

Need a full sandboxed operating system? We've got that too.

The Sandbox Agent SDK lets you run coding agents in sandboxes and control them over HTTP. Supports Claude Code, Codex, OpenCode, Amp, and Pi. Works with E2B, Daytona, Vercel, Docker, and Cloudflare.

FAQ

How does it work?

Secure Exec runs untrusted code inside V8 isolates — the same isolation primitive that powers every Chromium tab and Cloudflare Workers. Each execution gets its own heap, its own globals, and a deny-by-default permission boundary. There is no container, no VM, and no Docker daemon — just fast, lightweight isolation using battle-tested web technology. Architecture →

Does this require Docker, nested virtualization, or a hypervisor?

No. Secure Exec is a pure npm package — npm install secure-exec is all you need. It has zero infrastructure dependencies: no Docker daemon, no hypervisor, no orchestrator, no sidecar. It runs anywhere Node.js or Bun runs.

Can it run in serverless environments?

We are actively validating serverless platforms, but Secure Exec should work everywhere that provides a standard Node.js-like runtime. This includes Vercel Fluid Compute, AWS Lambda, and Google Cloud Run. Cloudflare Workers is not supported because it does not expose the V8 APIs that Secure Exec relies on.

When should I use a sandbox vs. Secure Exec?

Use Secure Exec when you need fast, lightweight code execution — AI tool calls, code evaluation, user-submitted scripts — without provisioning infrastructure. Use a sandbox (e2b, Modal, Daytona) when you need a full operating-system environment with persistent disk, root access, or GPU passthrough. Full comparison →

Can I run npm install in Secure Exec to dynamically install modules?

Yes. Secure Exec supports dynamic module installation via npm inside the execution environment.

Can I use it to run dev servers like Express, Hono, or Next.js?

Yes. Secure Exec bridges Node.js APIs including http, net, and child_process, so frameworks like Express, Hono, and Next.js work out of the box. For production deployments, pair Secure Exec with Rivet Actors to get built-in routing, scaling, and lifecycle management for each server instance.

Can it be used for long-running tasks?

Yes. For orchestrating stateful, long-running tasks, we recommend pairing Secure Exec with Rivet Actors. Rivet Actors provide durable state, automatic persistence, and fault-tolerant orchestration — so each long-running task survives restarts and can be monitored, paused, or resumed without you building that infrastructure yourself.

What are common use cases?

• AI agent code execution and tool use
• User-facing dev servers (Express, Hono, Next.js)
• MCP tool-code execution
• Sandboxed plugin / extension systems
• Interactive coding playgrounds

Does this have Node.js compatibility?

Yes. Most Node.js core modules work — including fs, child_process, http, dns, process, and os. These are bridged to real host capabilities, not stubbed.

Does this have access to a full operating system?

Yes. Secure Exec includes a virtual kernel with a system bridge that supports a granular permission model. Filesystem, network, child processes, and environment variables are all available — gated behind deny-by-default permissions.

Does Secure Exec support JIT compilation?

Yes. Secure Exec runs on native V8 isolates, so your code is JIT-compiled by V8's TurboFan optimizing compiler — the same pipeline that powers Chrome and Node.js. This means full optimization tiers, inline caching, and speculative optimization out of the box.

How does Secure Exec compare to WASM-based JavaScript runtimes like QuickJS?

WASM-based runtimes like QuickJS (via quickjs-emscripten) compile a separate JS engine to WebAssembly, which means your code runs through an interpreter inside WASM — not native V8. Secure Exec uses native V8 isolates directly, so you get the same JIT-compiled performance as JavaScript running on the host. No interpretation overhead, no WASM translation layer, and full Node.js API compatibility.

Links

• Documentation
• Changelog
• Discord
• GitHub

License

Apache-2.0