Introducing Deno Sandbox | Deno

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 can create them 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.
But there is more. In Deno Sandbox, secrets never enter the environment. Code sees only a placeholder:
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:
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.
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.
Perfect for AI agents executing code, vibe-coding environments, secure plugin systems, ephemeral CI runners, and customer-supplied code.
Update November 2026: Deno Sandbox is no longer included in Deno Deploy plans and is not available to new customers. See Deno is joining Cloudflare.
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.