Deno Deploy Shutdown Date: What Is Confirmed

The Deno Deploy shutdown date is the question every Deno developer has been typing into Google since October 9, and the honest answer is that nobody has published one. After Cloudflare took on the whole Deno team, Deno said its hosting service will keep running for six months and then close. It never named a day. If you are still deciding how worried to be about the wider story, our piece on is Deno dead covers the deal itself.

Here, we stay narrower on purpose. This article is about dates, data and decisions: which dates are real, which ones people have quietly invented, what happens to the things you stored on the platform, and how to plan a move without rushing. We checked Deno's own documentation and the press coverage of the announcement, and wherever something is our estimate rather than a fact, we say so.

One warning before we start. Search results for this topic are full of confident numbers. Some are correct, some belong to a different product, and some are simple arithmetic dressed up as news. A good rule while reading any of them: ask who said it, and whether they said a date or a length of time.

Deno Deploy shutdown date: what is actually confirmed

On October 9, 2026, Ryan Dahl, who created both Node.js and Deno, announced that the entire Deno team is joining Cloudflare. Coverage of the announcement agrees on a short list of facts about the hosting service. (For the business side of Cloudflare's deal with Deno, including who said what, our main report has the details.)

• Deno Deploy keeps operating for six months, then shuts down. That is a length of time. It is not a calendar date.
• Paying customers get migration support for moving to Cloudflare Workers.
• The price and terms of the deal were not disclosed.

So, will Deno Deploy shut down? Yes, according to the announcement. What is missing is the day. If you count six months from October 9, you land around April 9, 2027. That is our own arithmetic, so treat April 2027 as a planning estimate, not a promise. The moment Deno or Cloudflare publishes an exact day, that day replaces our guess.

It also helps to know what "six months" does not mean. It does not mean the service stops being reliable at month five, and it does not mean everything is deleted the second the clock runs out. We simply do not know how the final weeks will work: whether there will be a read-only period, an export window, or a hard stop. Those details usually arrive in a later notice, and they matter more than the headline date.

Why the date is confusing: the July 20 mix-up

If you search for the shutdown, you may stumble on a different date, July 20, 2026. It appears in Deno's migration guide, which says Deploy Classic and the subhosting v1 API "will be shut down on July 20, 2026."

That is a separate event. Deploy Classic is the older version of the platform, and the guide explains how to move to the newer Deno Deploy. It does not mention Cloudflare at all. The Cloudflare announcement is about the newer service. So two different products have two different shutdowns, and an article that mixes them up will give you a wrong deadline.

There is a second source of confusion: word choice. Deno's own wording is that its team is "joining" Cloudflare. Some news outlets call the deal an acquisition. Both can be true, but only one of them tells you anything about your hosting bill. When you read about the Deno Deploy shutdown date, the safest question is always the same: which product, and was the date announced or calculated?

The timeline in one place

Put simply, the announcement came on October 9, 2026, and that part is confirmed. Deno Deploy then runs for six months with no day given, which points to around April 2027 by our estimate. The Deno runtime gets one more year of monthly bug-fix and security releases, after which official development ends, which points to around October 2027, again as our estimate. The runtime code stays open source, and that is confirmed in Dahl's announcement. Separately, Deploy Classic and the subhosting v1 API were set to shut down on July 20, 2026, according to the migration guide, which is an older and unrelated shutdown.

If you want to know what happens to the Deno runtime after that year, and which parts of the project live on, that is covered in our main guide. Notice the gap between the two real deadlines. The hosting service ends first, in about six months. The runtime follows roughly half a year later. If you only run Deno on your own server, your clock is the longer one. If you deploy to Deno's platform, your clock is the short one, and it is already ticking.

What Deno Deploy actually runs for you

Before you plan a move, it helps to list what the platform does for your project, because each piece has to land somewhere new. For most teams it comes down to six things:

• Your code, running close to users on a global network instead of in one data center.
• Custom domains and certificates, attached to your project.
• Environment variables and secrets, stored on the platform.
• Scheduled jobs, through Deno.cron().
• Data, if you use Deno KV.
• Queues, if you built background work on them.

Moving the code is usually the easy part, especially if your handlers are written with the standard web APIs such as fetch, Request and Response. The harder parts are the ones that quietly tie you to a platform: stored data, scheduled jobs and anything that relied on a Deploy-only feature. That is the same lesson developers keep learning about edge platforms, and it connects to the broader shift we describe in real world applications of AI, where more work now runs near the user instead of in a central server.

What happens to Deno KV after Deno Deploy shuts down

This is the question we could not find a clear answer to anywhere, so here is what the documentation does tell us, with the gaps marked.

On Deploy, Deno KV is a managed service. Deno's earlier KV announcement describes the Deploy version as backed by FoundationDB and operated by Deno. When Deploy shuts down, that managed service goes with it, unless Deno says otherwise.

Locally, Deno KV is separate. It is built into the runtime and backed by SQLite, so it keeps working on your own machine. If you use KV only in local scripts, the shutdown does not touch it.

There is a self-hosted option. Deno publishes a denokv server, backed by SQLite, for running KV on your own infrastructure. One third-party host notes that it is designed around a single writer. In plain terms, it is a way to keep the same Deno.openKv() code working, but it is not a copy of the global managed service, so do not assume it behaves identically under heavy traffic.

Your data will not move by itself. Deno's migration guide says KV data is not migrated automatically between Deploy platforms and tells people to contact Deno support for help.

What we could not find: any statement about whether Cloudflare will offer a KV-compatible replacement, or an official export tool for Deploy KV. Until one exists, treat your KV data as something you need to copy out yourself while the service is still running. Check Deno's documentation for the current instructions before you start, and test the export on a small copy first.

It is also worth thinking about how you use KV, because that decides how hard the move is. If you store simple key and value pairs, almost any database can replace it. If you rely on atomic transactions, ordered key listing or the way KV handles consistency, you need a destination that offers the same guarantees. Cloudflare has its own storage products, including Workers KV, D1 and Durable Objects, but they work differently from each other and from Deno KV, so match the product to your access pattern rather than to the name.

Queues and cron on the newer Deploy

The same migration guide gives two details that tell you which features are hardest to move:

• Deno Queues are not supported on the newer Deno Deploy. Deno suggests an external message queue or a database-backed job queue instead.
• Deno.cron() works the same way, so existing scheduled jobs should keep working there.

Neither point says anything about what happens at the Cloudflare shutdown. Read them as a hint about portability, not as a forecast. If your app leans on Queues, you already know you will need a different mechanism, and it is better to design that now than in the last month.

Where you can go: the realistic options

There is no single correct destination. The right choice depends on how much you depend on platform features.

Cloudflare Workers. This is the official route, and the one Deno's migration help points to for paying customers. If your code uses standard web APIs, a move to Workers is often small. If it uses Deno-specific APIs, you will need to replace them. Our full comparison of the best Deno Deploy alternatives walks through this option and the others in more detail.

Run Deno yourself. The runtime is open source and will keep getting monthly fixes for about a year, so you can run it on a server or in a container you control. This gives you the most control and the least change to your code. The cost is that you now manage deployment, scaling and security updates yourself.

Switch runtime and platform together. If you were already thinking about leaving Deno, this is the natural moment. Node.js is the conservative choice, and many hosts run it. The price is rewriting any Deno-specific code.

Wait and watch. For a hobby project, the cheapest plan is sometimes to do nothing for a few months, see what Deno and Cloudflare publish, and then move once with better information. This only works if you are comfortable with a deadline you cannot name precisely.

A simple decision guide by project type

Because the right answer changes with the project, here is how we would think about it.

• A weekend project or a personal site. Do not rush. Keep an eye on official notices, and move in the last third of the window with the best information available.
• A small API with no stored data. Move early. Without KV, queues or cron, this is mostly a redeploy, and finishing it removes the worry.
• A production app that uses Deno KV. Start now. Data is the slow part. Decide your destination database, copy the data out, and run both systems side by side before you switch.
• A team product with paying customers. Write a plan, assign an owner and set an internal deadline well before April. Ask Deno about the migration support that paying customers were promised, and get the details in writing.

Whatever the size, keep your business logic separate from platform code. A thin layer for storage, scheduling and deployment means the next move, whenever it comes, is a weekend job instead of a rewrite. If your move also means choosing a new framework, not just a new host, our look at whether TanStack Start is production ready covers one option that went stable in October.

What to do while Deno Deploy is shutting down

With Deno Deploy shutting down in about six months, you do not need to move this week, but you should know what you have. This is the order we would work in:

1. List what runs on Deno Deploy. Projects, custom domains, environment variables, secrets, cron jobs and anything that touches KV or Queues.
2. Copy your configuration. If you keep settings in .env files, our .env diff checker compares two files by key name in your browser, so you can confirm nothing is missing on the new platform. Nothing is uploaded.
3. Test the new version against the old one. If you already have a working curl command for an endpoint, the cURL to fetch converter turns it into code for a quick comparison script, which makes it easy to check that both versions answer the same way.
4. Decide where the data goes. For KV, choose between self-hosting denokv, using another database, or waiting to see what Cloudflare announces.
5. Move one small project first. Whatever surprises you there is cheaper to find early than on your busiest app.
6. Write down the rollback. Keep the old deployment alive until the new one has handled real traffic for a while.

The pattern will feel familiar if you have ever planned around when Windows 10 updates end. Software rarely stops on the last day, but the risk of running something unsupported grows every month, and the people who plan early are the ones who stay calm.

What we still do not know

Even with careful reading, several important questions remain open:

• The exact shutdown day for Deno Deploy.
• What the migration support for paying customers includes, and how free-tier users are treated.
• Whether Cloudflare will provide a KV-compatible replacement or an export tool.
• What happens to Deno's web framework, Fresh.
• Whether there will be a read-only or export period before the final shutdown.

We will update this article when any of these are answered. If you see a source claiming a firm date today, check whether it quotes Deno or Cloudflare directly. At the time of writing, we could not find one that does.

Is Deno dead, then?

No, not today. Your Deno code still runs, the project remains open source, and the runtime gets about a year of monthly releases. What changed is that the hosting service now has an end date, and official development of the runtime has one too. If you want the longer version, including what stays (JSR and rusty_v8) and how Cloudflare describes its plans, read is Deno dead? What the Cloudflare deal means.

The practical lesson is simple. Treat any platform you do not control as something that can change its plans, keep your data portable, and write down your dependencies while there is still time. That advice would have been good on October 8, and it is better now.

FAQs

When does Deno Deploy shut down?

Deno said Deno Deploy will keep operating for six months after the October 9, 2026 announcement and then shut down. No exact day has been published. Six months from the announcement is around April 2027, which is an estimate, not an announced date.

Will Deno Deploy shut down for free users too?

The announcement describes the shutdown of the service, not only of paid plans. What differs is the help: reports say paying customers get migration support to Cloudflare Workers, and we could not find published details for free-tier users, so plan on moving those projects yourself.

Is Deno KV shutting down?

The managed Deno KV that runs on Deno Deploy depends on the platform, so it is expected to end with it unless Deno announces otherwise. Deno KV in the local runtime, backed by SQLite, is a separate feature that keeps working on your own machine.

Can I self-host Deno KV?

Yes. Deno publishes a self-hosted denokv server backed by SQLite. It is meant for running KV on your own infrastructure. It is not a copy of the global managed service, so check how it handles your traffic before relying on it.

Is the July 20, 2026 date the same shutdown?

No. July 20, 2026 appears in Deno's migration guide for Deploy Classic and the subhosting v1 API. The Cloudflare announcement concerns the newer Deno Deploy platform.

Will my Deno apps stop working when the runtime support ends?

Not on the day. Official development of the runtime ends after about a year of monthly releases, around October 2027, and the code stays open source. Your scripts keep running, but you stop receiving new features and official security fixes.

What are the main Deno Deploy alternatives?

Cloudflare Workers is the official route, running Deno yourself on a server or container keeps your code unchanged, and moving to another runtime and host is the most work. Our guide to Deno Deploy alternatives compares them.

Is Deno dead?

Not today. See our guide on is Deno dead for what stays, what goes and the dates that matter.