Over the past year, we’ve seen a shift in what Deno Deploy customers are building: platforms where users generate code with LLMs, and that code runs immediately without review. That code frequently calls LLMs itself, which means it needs API keys and network access.

This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.

Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding.

Watch the full announcement video here.

Secrets That Can’t Be Stolen

In Deno Sandbox, secrets never enter the environment. Code sees only a placeholder:

import { Sandbox } from "@deno/sandbox";

await using sandbox = await Sandbox.create({
secrets: {
OPENAI_API_KEY: {
hosts: ["api.openai.com"],
value: process.env.OPENAI_API_KEY,
},
},
});

await sandbox.sh`echo $OPENAI_API_KEY`;

The real key materializes only when the sandbox makes an outbound request to an approved host. If prompt-injected code tries to exfiltrate that placeholder to evil.com? Useless.

Network Egress Control

You can also restrict which hosts the sandbox can talk to:

await using sandbox = await Sandbox.create({
allowNet: ["api.openai.com", "*.anthropic.com"],
});

Any request to an unlisted host gets blocked at the VM boundary.

Both features are implemented via an outbound proxy similar to coder/httpjail. This gives us a chokepoint for policy enforcement. We plan to add more capabilities here: analytics for outbound connections and programmatic hooks for trusted code to inspect or modify requests.

If you’re running untrusted JavaScript or TypeScript, combine this with Deno’s --allow-net flag for defense in depth: VM-level network restrictions plus runtime-level permissions.

What You Can Build

Sandboxes are real Linux microVMs, isolated at the hypervisor level (not containers):

• Boot in under a second
• Ephemeral by default, lifetime can be extended on demand
• 768 MB to 4 GB memory
• SDKs for JavaScript and Python

Perfect for AI agents executing code, vibe-coding environments, secure plugin systems, ephemeral CI runners, and customer-supplied code.

import { Sandbox } from "@deno/sandbox";

await using sandbox = await Sandbox.create();
await sandbox.sh`ls -lh /`;

Sandbox to Production

sandbox.deploy() deploys code from your sandbox directly to Deno Deploy.

const build = await sandbox.deploy("my-app", {
production: true,
build: { mode: "none", entrypoint: "server.ts" },
});

const revision = await build.done;
console.log(revision.url);

One call to go from sandbox to production deployment.

Persistence

Sandboxes are ephemeral by default, but when you need state:

• Volumes: read-write storage for caches, databases, user data
• Snapshots: read-only images for pre-installed toolchains

Run apt-get install once, snapshot it, and every future sandbox boots with everything already installed.

Technical Details

Spec	Value
Regions	Amsterdam, Chicago
Memory	768 MB - 4 GB
Max lifetime	30 minutes
Boot time	< 1 second

Pricing

Deno Sandbox is included in your Deno Deploy plan with competitive, usage-based pricing—you pay for compute time, not wall-clock time.

• $0.05/h CPU time (40h included with Pro)
• $0.016/GB-h memory (1000 GB-h included with Pro)
• $0.20/GiB-month volume storage (5 GiB included with Pro)

See full pricing details →

Enterprise pricing available—contact deploy@deno.com.

Get Started

Deno Sandbox launches in beta today, alongside the general availability of Deno Deploy.

• Landing page: deno.com/sandbox
• Docs: docs.deno.com/sandbox
• JavaScript SDK: jsr.io/@deno/sandbox or npm
• Python SDK: pypi.org/project/deno-sandbox

We’re excited to see what you (or your AI agents) build with Deno Sandbox.