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.
You don’t want to run untrusted code (generated by your LLMs, your users LLMs, or even hand written by users) directly on your server. It will compromise your system, steal your API keys, and call out to evil.com. You need isolation.
Deno Sandbox gives you lightweight Linux microVMs (running in the Deno Deploy cloud) to run untrusted code with defense-in-depth security. You create or programmatically via our JavaScript or Python SDKs, and they boot in under a second. You can also interact with them via SSH, HTTP, or even open a VS Code window directly into the sandbox.
import { Sandbox } from "@deno/sandbox"; await using sandbox = await Sandbox.create(); await sandbox.sh`ls -lh /`;
But there is more. 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.
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.
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. No rebuilding in a different CI system, no re-authenticating with a different tool. Just turn your dev environment directly into a production ready, auto-scaling serverless deployment.
Sandboxes are ephemeral by default, but when you need state we have you covered:
Run apt-get install once, snapshot it, and every future sandbox boots with
everything already installed. Create read-write volumes from the snapshots to
create a fresh development environment in seconds.
| Spec | Value |
|---|---|
| Regions | Amsterdam, Chicago |
| vCPUs | 2 |
| Memory | 768 MB - 4 GB |
| Lifetime | Ephemeral or timeout (supports extending on demand) |
| Max lifetime | 30 minutes |
| Boot time | < 1 second |
Perfect for AI agents executing code, vibe-coding environments, secure plugin systems, ephemeral CI runners, and customer-supplied code.
Deno Sandbox is included in your Deno Deploy plan with competitive, usage-based pricing. You pay for compute time, not wall-clock time.
Enterprise pricing available—contact deploy@deno.com.
Deno Sandbox launches in beta today, alongside the general availability of Deno Deploy.
We’re excited to see what you (or your AI agents) build with Deno Sandbox.