If you run production code, edge functions or agents on Deno Deploy, you have about six months to move them, and if you standardised on the Deno runtime, about a year of security patches. The Deno team is joining Cloudflare, and Ryan Dahl's announcement on October 9, 2026 says Deno Deploy "will continue operating for six months before shutting down," while the runtime gets monthly bug-fix and security releases for one more year before Deno's own development ends. Cloudflare is taking the people and the ideas. Deno's hosted products mostly do not survive.
The one product that does is JSR, the package registry, which keeps running with its infrastructure moving to Cloudflare. Paying Deno Deploy customers who move to Cloudflare Workers get migration support. Everyone else is on their own clock.
What Ends, and When?
Deno Deploy is the product with the hard deadline, and the runtime is the one with the long tail. Neither company has published a calendar date for either, so the dates below are counted from the October 9 announcement.
| Product | What the announcement says | Working deadline |
|---|---|---|
| Deno Deploy | Operates six more months, then shuts down | Around April 9, 2027 |
| Deno runtime | Monthly bug-fix and security releases for one year, then Deno's development ends; stays open source | Around October 2027 |
| JSR | Keeps running; infrastructure moves to Cloudflare | No end date |
| rusty_v8 | Support continues, with work toward integrating it into workerd | No end date |
| Deno Sandbox, Subhosting, Deno KV | Not named in the announcement | Ask your account contact |
The financial terms were not disclosed, and one deal write-up notes that this leaves "acquisition" unconfirmed as the legal structure. The New Stack reported it as Cloudflare acquiring Dahl's startup. For a customer, the structure matters less than the shutdown notice, which is explicit.
Six months is shorter than at least one well-known platform exit. When Facebook wound down Parse, the mobile backend it had bought, it gave developers a year-long period ending on January 28, 2017 from a January 28, 2016 announcement. Deno Deploy customers get half that.
What Cloudflare Actually Bought
Cloudflare wants Deno's team to make its Workers model run on your own servers. The joint post on Cloudflare's blog, written by Kenton Varda and Dahl, says Cloudflare is merging workerd, its open-source Workers runtime, with celld, Deno's open-source distributed implementation of Workers and Durable Objects that Deno released in August. Dahl and Bert Belder will lead an effort to make self-hosting workerd a first-class way to run applications.
The gap they are filling is specific. A Durable Object is a distributed singleton: one addressable instance with its own SQLite database, single-threaded execution and WebSocket handling. Cloudflare's post says workerd supports Durable Objects only as a single instance, which works for local testing but cannot scale, and calls that the main gap in workerd's production readiness. Celld is written in Rust and designed as one binary whose only external dependency is object storage.
The steel-man for Cloudflare is real. Its post rejects the claim that Workers was built to trap customers, saying it open-sourced workerd in 2022 because customers such as Shopify asked for it, and that some former customers have migrated away using workerd. If the merged runtime ships as described, you would get a Workers-compatible platform you can run in your own data centre, which is more portability than Deno Deploy ever offered.
But none of it has a date. Cloudflare's post promises more announcements "in the coming months." Dahl's post invites developers building agents at scale on their own infrastructure to email him. You cannot put a request for design partners into a migration plan that is due in April.
Who Is Exposed Beyond Deno Deploy Customers?
The direct customers are the obvious exposure, but Deno's runtime and hosting sit underneath other platforms, and you may be running on Deno without a Deno contract.
Start with Netlify Edge Functions. When Deno raised a $21M Series A led by Sequoia in June 2022, it named Netlify as running its Edge Functions on Deno Deploy through a partnership. Netlify's current documentation describes the product as running in "a secure runtime based on Deno" and does not mention Deno Deploy. Neither company has said publicly what the deal changes for Netlify customers.
The same 2022 post named Supabase, whose Edge Functions also run Deno code. Supabase's docs today describe its own Supabase Edge Runtime as "Deno compatible" and say functions run "on any other Deno-compatible platform (including self-hosted infrastructure)." For Supabase users, the runtime's one-year support window looks like the more relevant date than the Deploy shutdown. That is our reading; Supabase has not commented.
Agent workloads are the third exposure. Deno Sandbox is an SDK for isolated Linux microVMs "built for AI agents," billed at $0.10 per CPU-hour and $0.025 per GiB-hour of memory, and its own page says the sandboxes run on Deno Deploy. The shutdown announcement does not name Sandbox. If your coding agent or code-interpreter feature runs generated code there, plan as if it ends with Deploy until Deno tells you otherwise in writing.
Then there is Subhosting. Deno's pricing page positions the $200-a-month Builder plan at Subhosting users, the platforms that let their own customers deploy code onto Deno. If you built a product on Subhosting, your customers' code has the same six-month clock as yours.
What Moving to Workers Costs
On list price, Workers is cheaper per request than Deno Deploy for most request-heavy workloads; the real migration cost is engineering time and the parts that have no named equivalent. Prices below were checked on each vendor's live page on October 11, 2026.
| Meter | Deno Deploy Pro | Cloudflare Workers Paid |
|---|---|---|
| Base price | $20/month | $5/month minimum |
| Included requests | 5M, then $2 per million | 10M, then $0.30 per million |
| Compute | 50 active CPU hours, then $0.10/hr | 30M CPU ms, then $0.02 per million CPU ms |
| Egress | 200 GiB, then $0.20/GiB | No bandwidth charges |
Source: Deno Deploy pricing and Cloudflare Workers pricing. Durable Objects on the Workers Paid plan add their own meters: 1M requests included then $0.15 per million, and 400,000 GB-seconds included then $12.50 per million GB-seconds.
The table hides three costs. Deno KV, which Deno Deploy bills separately, is not mentioned in either announcement, so any state you keep there needs a new home and an export path. Workers is a different runtime from Deno, so code that leans on Deno-specific APIs will need changes; Dahl's post says rusty_v8 integration into workerd is in progress, which suggests compatibility work is planned but not finished. And migration support is promised only to paying customers moving to Workers. A team on the free tier, or one moving to Vercel or its own containers, gets nothing.
If you are running agent code in Deno Sandbox, the realistic alternatives are other sandbox providers such as E2B, Modal and Daytona, or Cloudflare's own Agent Cloud. Our comparison of E2B, Modal and Daytona found that idle time sets the bill, which matters more than the headline CPU rate when you reprice.
What to Do Before the Window Closes
This Week:
- Inventory every Deno Deploy project, Subhosting deployment and Sandbox integration your teams own, including the ones on personal or free accounts, which nobody will migrate for you.
- Ask your Deno account contact, in writing, for the calendar shutdown date and for the status of Sandbox, Subhosting and Deno KV, none of which the announcement names.
- If you build on Netlify or Supabase edge functions, open a ticket asking each vendor what the deal changes for its runtime and when it will say.
This Month:
- Export everything in Deno KV and test a restore into whatever replaces it. Do not wait for a migration tool that has not been announced.
- Port one representative service to Workers, or to your fallback host, and measure two things: engineering days spent and the per-request cost under your real traffic.
- Decide who owns your Deno runtime after the support year. If you run Deno in your own containers, you either fund an upgrade to a maintained runtime or accept unpatched code after roughly October 2027.
Before April 2027:
- Finish the Deno Deploy migration with at least a month of buffer. The six-month clock started on October 9.
- Keep self-hosted Workers via workerd and celld off the critical path. Revisit it when Cloudflare publishes a release date.
- Add a change-of-control and minimum-notice clause to your next serverless contract. Our guide to AI vendor exit clauses covers the language.
The Bottom Line
Deno joins a run of small-vendor deals where the customer's first news was a deadline. Juicebox bought Fetcher's assets and set an October 16 shutdown. Baseten bought Blaxel with a continuity pledge that had no end date. Deno's notice at least states durations, and it comes with migration help for paying customers. For buyers the lesson repeats: when an infrastructure startup joins a larger platform, its hosted product runs on the acquirer's schedule, and yours has to fit inside it.
Cloudflare's long-term pitch is portability. Parse customers in 2016 learned that a hosted backend you cannot run yourself leaves you with a migration on someone else's timetable. A Workers runtime you can self-host would remove that risk for the next platform exit, including one from Cloudflare. It has not shipped, though, and Deno Deploy shuts down on its own timetable regardless.
Put the April 2027 date on your platform team's roadmap this week.
Continue Reading
- E2B vs Modal vs Daytona: Idle Time, Not Cold Start, Sets the Bill
- Fetcher Shuts Down October 16 After Juicebox Buys Its Assets
- Baseten Buys Blaxel, Whose 'Keeps Running' Pledge Has No End Date
- Supabase Buys Turso and Its $4.99 Unlimited-Database Plan
- AI Vendor Exit Clauses: Standard Terms Give 0 to 90 Days to Get Out
- Cloudflare Dynamic Workers Run AI Agent Code 100x Faster Than Containers