Cloudflare Acquires Deno: What Changes on Workers
On 9 October 2026 the Deno team announced that it is joining Cloudflare. If you build client sites on Cloudflare Workers, nothing breaks and nothing needs to change this month. If you have anything running on Deno Deploy, you have six months to move it. And if you have been uneasy about how tied a Workers site is to one company, the announcement comes with a promise that matters more than the deal itself: a supported way to run the same code on your own servers.
We run a group of content sites and client builds on Workers, so we read both announcements line by line to see what we need to do. This post is that reading: what was said, what was only promised, a checklist for each situation, and how we now think about the risk of building on one company’s platform. It is written for agency owners and the people who make hosting decisions for clients. A short developer section near the end is marked so you can skip it.
In this guide
- What was announced, in plain words, with the dates
- Who needs to act now and who does not
- If you have apps on Deno Deploy: a six-month move plan
- If you build on Workers: what changes and what does not
- The lock-in question, and what the self-hosting promise is worth today
- A one-hour dependency audit for any site on a hosted platform
- What to tell clients who ask
- For developers: what moves easily and what does not
- Questions people ask
What was announced?
Two posts went up on the same day. Deno’s is titled Cloudflare acquires Deno and was written by Ryan Dahl, who created Node.js and later Deno. Cloudflare’s is a joint post by Kenton Varda and Ryan Dahl. Here is what they say, without the background.
| Product | What happens | Timeline stated |
|---|---|---|
| Deno runtime | Monthly releases with bug fixes and security updates, then the team stops developing it. It stays open source and others may continue it. | One more year of support |
| Deno Deploy (hosting) | Keeps running, then shuts down. Paying customers get help moving to Cloudflare Workers. | Six months |
| JSR (package registry) | Continues, with its infrastructure moving to Cloudflare. | No end date given |
| rusty_v8 | Continues to be supported, with work towards using it inside workerd, the Workers runtime. | No date given |
| celld | Its code and ideas are to be merged back into workerd so that self-hosting Workers becomes a supported option. | “In the coming months” |
Two names in that table need a sentence each. workerd is the program that runs Workers code. Cloudflare open-sourced it in 2022, and says in the joint post that it is the same code it runs in production. celld is a project the Deno team released in August 2026: an open-source implementation of Workers and Durable Objects that you run on your own machines. Its own site lists Workers, Durable Objects, KV, Queues, D1, R2, Workflows, Cron Triggers and static assets as supported, and says a deploy reads your existing Wrangler configuration file.
The Deno post is direct about the cost of the decision. The team chose to put future work into the shared platform “rather than continuing to develop a separate runtime and hosting service”, and it calls this “a consequential change for people who have built on Deno”. That is an honest way to say that a runtime and a hosting product people depended on now have end dates.
Who needs to act, and by when?
| Your situation | Action | Deadline |
|---|---|---|
| Sites or apps hosted on Deno Deploy | Plan and complete a move | Before the six-month shutdown, so by early April 2027 if the clock started on the announcement date. Confirm the exact date in your Deno Deploy dashboard. |
| Tools or services that run on the Deno runtime on your own servers | Decide whether to move to Node.js or stay and watch who takes over maintenance | About a year of security updates remain |
| Packages you publish to or install from JSR | Nothing | None |
| Sites on Cloudflare Workers or Pages | Nothing required. Do the dependency audit below when convenient. | None |
| WordPress sites that only use Cloudflare for DNS, caching or firewall | Nothing. This does not touch you. | None |
Most agencies we know sit in the last two rows. If that is you, the rest of this post is about judgement and preparation, not an emergency.
If you have apps on Deno Deploy: how do you move in six months?
Six months sounds generous. It is not, once you remove the weeks nobody will work on it. Treat it as a project with a date, and start with a list.
- List every project in your Deno Deploy account, including the small ones: a webhook receiver, a form handler, a redirect service, a cron job somebody set up two years ago. Small forgotten services are the ones that fail on shutdown day.
- For each one, write down what it stores and where. If it uses Deno KV, the built-in database, that data has to be exported and loaded somewhere else. If it only talks to outside services, the move is mostly code.
- Write down what triggers it. A public web address, a scheduled job, a queue. Each trigger needs an equivalent at the destination.
- Pick the destination per project, not for the whole account. Deno is offering paying customers help moving to Workers, and for request-handling code that is the natural home. But a project that needs long-running processes or a full Node.js environment may fit better on an ordinary server or container. Choose by what the code does.
- Move the smallest project first. You will learn the real effort from one small move, and that tells you whether the rest fit in the window.
- Run old and new side by side before switching. Point a test address at the new copy, compare the responses for the same requests, and only then change the live address. Keep the old one running until the new one has handled real traffic for a week.
- Tell the client now. A short note that says “the hosting company for this service is closing it in six months, we are moving it, here is the plan” lands far better in October than in March.
One caution about the offered migration help: the announcement says it is for paying customers. If your projects are on a free tier, assume you are doing the move yourself.
If you build on Workers: what changes and what does not?
Nothing changes in the product you use today. Your deploys, your bindings, your pricing and your dashboard are the same as they were on 8 October. Neither post announces a change to Workers itself.
What changes is direction. Three things in the joint post are worth knowing because they affect decisions you make over the next year.
Self-hosting is now a stated goal with named people on it
Cloudflare says that Ryan 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”, and that this will involve merging code and ideas from celld back into workerd. The post is frank about why this was needed. It says Cloudflare released workerd intending people to run it in production, that few have, and that “we haven’t done a great job of building out the ecosystem of adjacent services and tooling to make it really work”.
The known gap is named
The same post admits that workerd “has always had one big gap in its production-readiness: Durable Objects”. It implements them only in a single-instance way, which the post describes as good enough for local testing but unable to scale. celld was built to close that gap. So if your site depends on Durable Objects, the realistic way to self-host it today is celld, not workerd alone.
The stated ambition is wider than Cloudflare’s own network
Deno’s post says the aim is “to make this programming model the default way to build servers, whether you run on Cloudflare’s network or your own infrastructure”. If that happens, code written for Workers becomes more like code written for Node.js: something several hosts can run. That is a promise about the future. It should make you more comfortable, and it should not yet change a contract.
Does this end the lock-in worry?
Not yet. It changes the worry from “there is no exit” to “there is an exit that is not finished”. Both are worth understanding, because clients ask about this and the honest answer has two halves.
The worry is real in one specific way. A site built for Workers is not a set of files you can copy to any server. It is written against Cloudflare’s services: a key-value store, a database, file storage, sometimes Durable Objects. Cloudflare’s own post describes the criticism it gets, that software built on Workers is hard to move and that apps using Durable Objects “are not just written differently but architected differently”. Its answer is that Workers is different because the design is better, that the runtime is open source, and that some former customers did leave by running workerd themselves.
Here is how we weigh it today:
- What exists now. workerd is open source. celld is open source and can be installed today. Cloudflare’s post ends by saying you can start self-hosting either one now.
- What is promised. A supported, documented, first-class self-hosting path, with more announcements “in the coming months”. No date, no feature list.
- What we have not verified. We have not run one of our own sites on celld. Its site publishes performance and cost figures, which are the project’s own measurements, and it lists things that are out of scope, including anything that needs Cloudflare’s network, its GPUs or a browser farm. Until we have moved a real site and served traffic from it, we treat the exit as plausible and untested.
Our rule for client work stays the same as before the announcement: do not plan on a feature that has been announced and not shipped. If a client needs a guaranteed exit path in writing, test it on their site before you promise it.
The other lesson in this announcement
There is an irony worth saying out loud. The same announcement that makes Workers easier to leave also shuts down a hosting service on six months’ notice. Deno Deploy was a well-funded product from a respected team, and its customers now have a deadline they did not choose. That is the real risk of any hosted platform. It is rarely a sudden price rise or a rug pull. It is a company changing its priorities, politely and with notice, on a timeline that is shorter than your client’s planning cycle.
We wrote about the same pattern from the plugin side in Don’t Marry a Plugin or Theme: Start From Your Business Flow. The principle carries over: know what you depend on, and know what it would take to leave, before someone else sets the date.
How do you audit what a site depends on?
This takes about an hour per site and works for any hosted platform, not only Workers. Do it once and keep the result with the project notes.
- List every platform service the site uses. On Workers that means reading the Wrangler configuration file and listing each binding: KV namespaces, D1 databases, R2 buckets, Durable Objects, Queues, image resizing, scheduled triggers. If you did not build the site, ask the developer for this list. It should fit on half a page.
- For each service, write where the data would go if you left. Files in object storage can be copied to any S3-style storage. A SQL database can be exported. A key-value cache can usually be thrown away and rebuilt. Durable Objects are the hard one, because the logic and the data live together.
- Take one real export. Not a plan to export. Download the database and the file storage once and confirm you can open them. We take a restore point and a portable export before every platform upgrade, a routine we described in How We Update Five Live Sites Without Breaking Them.
- Check who holds the accounts. The domain, the DNS, the platform account and the code repository should be in the client’s name or in an account the client can access. An exit plan is no use if the agency that left holds the login.
- Write one paragraph: “if this platform gave six months’ notice, we would…” If you cannot write it, that is the finding. You do not have to fix it today. You have to know.
- Rate each dependency. Easy to replace, replaceable with work, or would need a rebuild. Anything in the third group is a business decision the client should make knowingly.
For our own content sites the audit is short. We checked the configuration of each one: they use a database, file storage and a cache, all of which have ordinary equivalents elsewhere, and none of them uses Durable Objects. That puts them in the “replaceable with work” group. A real-time app built around Durable Objects would land in a different group, and after this announcement it has a better story than it did a week ago.
What should you tell a client who asks about this?
Clients who read the tech press will ask, and the question is usually some form of “is our site affected?” Three answers cover almost every case.
- “Your site runs on Workers.” Nothing changes for your site. The company that hosts it has hired the team behind a competing technology and has committed to making it possible to run sites like yours on other servers. That lowers your long-term risk. We will keep you posted when that option is ready to test.
- “You have a service on Deno Deploy.” That hosting product is closing in six months. We have a plan to move it, it will be done by a date we will agree, and you should not see any interruption.
- “You are on WordPress with ordinary hosting.” This does not affect you.
Keep it to that. A client does not need the history of JavaScript runtimes. They need to know whether to worry and who is handling it.
For developers: what moves easily and what does not
This section is for the people doing the work. Skip it if that is not you.
From Deno Deploy to Workers. Both platforms are built around the same web-standard request and response objects, so plain request-handling code usually needs small changes. The work is in the edges. Deno-specific APIs (anything under the Deno namespace, including Deno.serve and Deno KV) have no direct equivalent and need rewriting against Workers bindings. Deno KV data needs an export and a load into KV, D1 or a Durable Object, depending on how you used it. Imports by URL or from JSR need to work with your bundler. Environment variables and secrets move to Wrangler configuration. We have not done one of these migrations ourselves, so take this as a map of where to look and check the official migration guidance when Deno publishes it.
From Workers to self-hosted. Per the celld site, celld deploy reads your existing wrangler.json and stops on a key it does not know instead of ignoring it, which is the behaviour you want from a migration tool. Each KV namespace, D1 database, queue and Workflow becomes a “cell” with its own storage, and R2 bindings read and write to a bucket you own. The site notes one writer per KV namespace and per queue. Anything that relies on Cloudflare’s network itself is listed as out of scope.
A cheap test worth running. Pick your simplest Workers project and try to run it on celld on a small server. Do not move it. Just see whether it starts and serves a page, and write down what failed. An afternoon of that tells you more about your real exit cost than any announcement.
What to watch for. The workerd repository for the merge work, the Workers changelog for a supported self-hosting guide, and Deno’s own channels for the Deploy shutdown date and migration tooling. When the supported path ships, re-run the test above.
What we are doing
Three things, none urgent. We checked our site repositories and found nothing that runs on Deno Deploy or depends on the Deno runtime. We are adding the six-point audit above to the notes for each Workers site we look after, so the exit paragraph exists before anyone needs it. And we have put the celld test on the list for a quiet week, on our smallest site, so that the next time a client asks “could we leave if we had to?” the answer comes from something we ran.
The wider habit is the one we use for any dependency that can change under us. We described it for AI tooling in MCP Servers Change Under You: How We Pin, Test and Watch Them, and it applies to hosting just as well: write down what you rely on, test that it still behaves, and watch for the announcement that changes it.
Questions people ask
Did Cloudflare buy Deno?
Deno’s own announcement is titled “Cloudflare acquires Deno” and says the entire Deno team is joining Cloudflare. Neither post gives financial terms. The practical outcome is that the team’s work moves to Cloudflare’s Workers platform.
Is Deno being shut down?
The Deno runtime gets one more year of monthly bug-fix and security releases from the team, after which the team stops developing it. It remains open source, and the announcement invites others to continue it. Deno Deploy, the hosting service, shuts down after six months.
Do I need to change anything on my Cloudflare Workers site?
No. Neither announcement changes how Workers behaves or what it costs. The news affects future options, mainly the ability to run Workers code on your own servers with official support.
Can I run a Cloudflare Workers app on my own server today?
Cloudflare says you can start self-hosting with workerd or celld now. workerd has a known limit with Durable Objects, which only run as a single instance. celld was built to remove that limit and lists most Workers services as supported. A fully supported, first-class path is promised and not yet released, so test with your own project before relying on it.
What happens to JSR?
JSR, the package registry, continues to operate. Its infrastructure moves to Cloudflare. No change is required from people who publish or install packages.
Should an agency avoid building on Workers because of lock-in?
We do not think so, and this announcement makes the case for Workers stronger, not weaker. What an agency should avoid is building on any platform without knowing the exit. Do the dependency audit, take a real export, and keep the accounts in the client’s name.
If you are deciding where a client site should live, or you have inherited something on a platform that is closing and need a plan, you can reach us through the contact page. For what moving a business site to a headless setup on this kind of platform involves, see From Heavy Theme to Headless: A Migration Playbook for Business Sites.