Deno Sandbox Has a Shorter Clock Than the Deno Runtime

Cloudflare is absorbing the Deno team, and the headline is a one-year runtime sunset. If your agents run generated code on Deno's cloud, your real deadline is six months, and nobody has said what happens to the sandbox.

The most interesting sentence in Friday's Deno announcement is the one that isn't there.

Ryan Dahl's post on October 9 says "the entire Deno team is joining Cloudflare," and it lays out what happens to almost everything the company built. The runtime gets "another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime." Deno Deploy "will continue operating for six months before shutting down." JSR keeps running, with its infrastructure moving to Cloudflare. rusty_v8 keeps getting support.

Deno Sandbox, as far as I can tell, gets no line at all.

That matters because of where Deno Sandbox lives. Its product page calls it "an SDK for instantly creating and managing secure, isolated VMs in the cloud on Deno Deploy." Each sandbox is "its own Firecracker microVM." And the pitch is aimed squarely at the people reading this: "Built for AI agents," a place to "run untrusted or generated code with real isolation and complete control." Today that page carries a banner that reads "Deno is joining Cloudflare!" and nothing else about the transition.

So the product built for running your agent's code sits on the service with six months left.

Why the runtime headline is the wrong one to react to

A one-year runtime sunset sounds like the big news, and for a lot of TypeScript shops it is. But it's also the softer of the two deadlines. The Deno runtime is MIT licensed ("Copyright 2018-2026 the Deno authors" in its LICENSE.md), Dahl writes that "Deno will remain open source," and a binary you already run on your own machine doesn't stop working on a date. You lose future patches. You don't lose the program.

A hosted service is different. When Deno Deploy shuts down, anything that only exists there stops. Six months from October 9 lands around early April 2027, and Dahl's post gives no exact date.

Here's my position: if your agent stack touches Deno anywhere in its code-execution path, treat the six-month number as your deadline and the one-year number as background. Plan the move now, while Cloudflare is still promising "more announcements" and before those announcements set the terms for you.

Deno was already an awkward sandbox

There's a second reason to move early, and it predates Friday.

For a while the cheapest way to give an agent a Python sandbox was to run Python compiled to WebAssembly (Pyodide) inside Deno, and lean on Deno's permission flags for isolation. Two well-known projects did exactly that. Both have since walked away from it.

Pydantic's mcp-run-python was an MCP server that ran agent-written Python "using Pyodide in Deno." Its README now opens with a notice that the team is retiring and archiving it, and the reason is blunt: "there's just no safe way to run Python within pyodide safely with reasonable latency." The security notes go further. Python in Pyodide can execute arbitrary JavaScript, code can read or write files the runtime can reach, and code can exhaust machine memory because Deno has no good way to cap it. The maintainers are careful to say these aren't bugs in Pyodide or Deno. Those tools just weren't designed as sandboxes for untrusted code. Pydantic points people to its Monty project instead.

LangChain's langchain-sandbox used the same Pyodide-plus-Deno pattern. It's now marked as no longer maintained, and its README says, "We do not recommend using langchain-sandbox for any production use cases."

Deno Sandbox was the company's answer to that critique. It didn't lean on the runtime's permission model. It put each job in its own microVM with its own filesystem, network stack and process tree. That's the right design for agent code. It's also the piece whose hosting just got a shutdown date.

Where Cloudflare wants you to go

Cloudflare's own post, co-signed by Kenton Varda and Dahl, says nothing about sandboxes either. It's about workerd, the open-source Workers runtime, and celld, the self-hosted Durable Objects server Deno released in August. Dahl and Bert Belder will lead "a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model."

Dahl's Deno post is where the agent angle shows up. He writes that Durable Objects "bring together capabilities that are particularly useful for agent harnesses: inexpensive, serverless execution, persistent state, WebSockets, and a high-level JavaScript interface." He also asks agent builders, especially those who want to run on their own infrastructure, to reach him at ry@cloudflare.com.

Read those together and the direction is clear. The agent harness, the long-lived thing holding state and talking to the model, is meant to live in Durable Objects. The code your agent writes and runs is a separate question, and Cloudflare already has a product for it. The Sandbox SDK docs describe @cloudflare/sandbox as a way to "Execute untrusted or generated code in Linux virtual machines or isolated Workers," with container instances that are each "a microVM with its own kernel and network." It requires the Workers Paid plan. The docs don't label the SDK GA or beta, though they mention 0.x versions and a container scheduling policy that is still in public beta.

That's a plausible landing spot for Deno Sandbox users. It is not an announced migration path, and I wouldn't assume one.

Put this into practice

The lowest-friction first move is an inventory. You can do it in an afternoon.

Find every place Deno runs in your agent path. Search your repos and infrastructure for deno in Dockerfiles, CI workflows, MCP server configs and deno.json files. Then search your MCP client configs for mcp-run-python, which pulls in Deno through uvx. Agent tooling hides runtimes well, so check the configs your coding agents load, not only your app code.

Sort what you find into two buckets. Bucket one is self-run: the Deno binary on your laptop, your CI runner, your container. That has a year of security releases and keeps working after. Bucket two is hosted: anything on Deno Deploy, including Deno Sandbox. That has six months.

Start bucket two first. Write down what each hosted workload needs: isolation level, cold-start budget, egress rules, secrets handling, and how much memory a runaway job may take. Those requirements, not the vendor name, decide your target. If you pick Cloudflare's Sandbox SDK, prototype one real agent task end to end, including a job that tries to reach the network and a job that tries to eat memory, and see what stops it.

Retire Pyodide-in-Deno sandboxes outright. If anything you run still depends on mcp-run-python or langchain-sandbox, the maintainers have already told you not to trust it with untrusted code. The Cloudflare news just gives you a reason to schedule the work.

Pin and watch the runtime. For bucket one, pin your Deno version, subscribe to the release feed, and put a calendar reminder at month ten. If a community fork emerges, you'll want time to evaluate it before the last security release ships.

What I don't know, and what could change this

I'm working from two blog posts and a product page, and the gap I'm pointing at could close fast.

Dahl's post doesn't mention Deno Sandbox by name, as far as I can tell, and neither does Cloudflare's. That could mean a plan exists and hasn't been announced, or that Sandbox follows Deploy, or something in between. I'd treat the product page's own words, "on Deno Deploy," as the best evidence available today and update the moment Deno or Cloudflare says otherwise.

The six-month figure has no exact date attached. Dahl promises "migration support for paying customers moving to Cloudflare Workers," and nothing published says what that support includes for Sandbox workloads.

Cloudflare's Sandbox SDK isn't a drop-in replacement. It's a different API on a different platform with a paid-plan requirement, and I haven't run Deno Sandbox and Cloudflare's SDK side by side on the same agent workload. Anyone telling you the move is a config change should show you their test.

And the runtime story could improve. Deno is MIT licensed with a large contributor base, and Dahl explicitly invites others to continue it. A healthy fork would change the one-year math. It wouldn't change the six-month math for anything hosted.

The deadline you set yourself

Platform news has a way of arriving with the important part missing. This announcement told a lot of people exactly where they stand and left agent builders with the one question that matters most to them unanswered.

You don't have to wait for the answer. List what runs where, move the hosted pieces first, and decide what isolation your agents' code actually needs. If the clarification comes next week, you'll have a test harness ready to judge it. If it doesn't, you'll be the team that isn't scrambling in March.

Sources: Deno blog, Ryan Dahl, Cloudflare blog, Kenton Varda and Ryan Dahl, Deno Sandbox, Deno LICENSE.md, pydantic/mcp-run-python, langchain-ai/langchain-sandbox, Cloudflare Sandbox SDK docs.

Medium metadata

Title: Deno Sandbox Has a Shorter Clock Than the Deno Runtime
Subtitle: Cloudflare is absorbing the Deno team, and the headline is a one-year runtime sunset. If your agents run generated code on Deno's cloud, your real deadline is six months, and nobody has said what happens to the sandbox.
Tags: Deno, Cloudflare, AI Agents, Software Development, JavaScript
Canonical URL: set to the fervorai.dev post on import