Bun Positioning for isolated-jsc
Bun makes TypeScript execution fast. @absolutejs/isolated-jsc makes untrusted TypeScript and JavaScript execution embeddable inside Bun, with bounded JavaScriptCore execution and explicit host capability brokering.
#The gap
The market pain is not "how do I evaluate code." The pain is running tenant, plugin, or AI-generated code without ambient access to Bun, process, filesystem, network, Workers, or shell APIs. Teams also need timeouts, heap limits, deterministic teardown, metrics, and audited host tools.
oven-sh/bun#6617Bun issueasks for sandboxing permissions.
oven-sh/bun#25929Bun issueasks for a secure runtime for AI-agent generated code.
oven-sh/bun#23653Bun issueshows the migration trap:
isolated-vm is a V8 addon, not a JavaScriptCore solution for Bun.#Quick answers
Why not Node isolated-vm?It is the right shape for Node/V8, but Bun is JavaScriptCore.
isolated-jsc ports the isolate-shaped API to Bun/JSC instead of trying to load a V8 addon.Why not just use Bun Workers?Workers are the portable substrate and fallback backend. This package adds the sandbox product layer: hardened globals, heap limits, timeouts, metrics, error fidelity, TypeScript helpers, pools, execution receipts, output limits, and explicit host capability brokers with manifests, redaction, per-tool output byte caps, and bounded audit buffers. As of 0.11.0 that layer also covers hibernating keyed pools that checkpoint idle tenants to bytes, operator-shaped pool metrics with drain and warm, and optional OpenTelemetry tracing.
When should I require FFI?Require
backend: 'ffi' for hostile-code production paths on macOS or Linux where JavaScriptCore is available. Use backend: 'auto' for portable defaults, demos, and CI. Add OS boundaries when a sandbox escape would expose meaningful host secrets.#Existing options
| Option | Good fit | Bun gap |
|---|---|---|
| new Function / direct eval | Trusted configuration snippets | No meaningful authority boundary. User code sees the host global surface. |
| Node node:vm | Convenience contexts for trusted or semi-trusted code | Node documents it as not a security mechanism for untrusted code, and it is Node/V8 rather than Bun/JSC. |
| Node isolated-vm | Mature isolate-shaped API for Node users | It is a V8 addon. It does not give Bun a JavaScriptCore-native isolate primitive. |
| Bun Worker | Portable separate-thread execution in Bun | Useful substrate, but not a complete untrusted-code permissions model by itself. |
| Process or container per script | Stronger blast-radius control | Higher cold start, higher RSS, serialized IPC, and more operational surface for frequent tenant scripts. |
| Cloudflare Workers / Deno Deploy | Hosted or platform isolate execution | Excellent platforms, but they change the runtime and deployment model instead of embedding in a Bun server. |
#Where it fits
@absolutejs/isolated-jsc is the middle tier: stronger than eval, node:vm, or proxy sandboxing; lighter and more embeddable than a process or container per script; native to Bun and JavaScriptCore instead of Node and V8.
FFI backenduse for production Bun/JSC isolation where JavaScriptCore is available.
Worker fallbackuse for local development, CI, demos, Windows, and hosts without libJSC.
OS boundaryadd process, container, uid, seccomp, or network policy when a sandbox escape would expose high-value secrets.
#Pain points
AI code executionModel-generated snippets need timeouts, heap caps, console capture, and host tools without file, network, process, or shell authority.
Tenant scriptingSaaS teams want customer-authored transforms, policy checks, workflow steps, and webhooks without a custom service per tenant.
Plugin evaluationInternal tools and build systems want plugins while keeping filesystem, network, process, and package-manager access explicit.
Node-to-Bun migrationTeams that already know isolated-vm need an isolate-shaped JavaScriptCore path when the host app moves to Bun.
#Objections
Why not wait for Bun permissions?Runtime permissions would be valuable, but this is an embedding API: many tenant isolates inside one Bun app, host tools passed intentionally, pooled lifecycle, and per-run metrics.
Why not just use Workers?Workers are the portable substrate and fallback path. The product layer adds hardened globals, memory limits, timeout behavior, error fidelity, TypeScript helpers, execution receipts, result and console limits, capability brokers with redacted bounded audit events, and hibernating keyed pools with operator metrics and OpenTelemetry tracing.
Is this enough for arbitrary hostile code?Use FFI plus OS isolation when host secrets or broad network/filesystem access are in scope. The claim is defense in depth, not magic in-process containment.
#Launch copy
PrimaryThe missing
isolated-vm layer for Bun.ExpandedRun untrusted JavaScript and TypeScript inside a bounded JavaScriptCore isolate, from a Bun host, with explicit capability brokering, redacted receipts, and bounded outputs instead of ambient
Bun/process access.SecurityUse FFI for production Bun/JSC isolation, Worker fallback for portability, and compose with process or container boundaries for fully adversarial code.