Cloudflare Acquires Deno: Runtime and Deploy Shutdown Dates

Cloudflare has acquired Deno, the startup behind the Deno JavaScript and TypeScript runtime, and the entire Deno team — including Node.js creator Ryan Dahl — is joining Cloudflare. The companies announced the deal on October 9, 2026, confirming that Deno's standalone runtime will get only bug-fix and security-update releases for about one more year before development effectively stops, and that the separately hosted Deno Deploy service will shut down within six months. Financial terms were not disclosed.

For anyone currently running production workloads on Deno Deploy, or shipping applications on the standalone deno runtime, this is a real deadline, not a rumor. Both companies published their own accounts of the deal on the same day, and this article is built directly from those two posts, Cloudflare's developer documentation, and public financial history — not from secondhand paraphrase.

What Cloudflare and Deno actually announced

In a joint pair of posts — one on Cloudflare's own blog, co-authored by Cloudflare principal engineer Kenton Varda and Ryan Dahl, and one on Deno's blog, written by Dahl — the two companies confirmed that Cloudflare has acquired Deno Land Inc. Dahl wrote plainly that "the entire Deno team is joining Cloudflare to take that work further," ending Deno's run as an independent company a little over eight years after he first unveiled the project at JSConf EU 2018 as a response to things he said he regretted about Node.js, the runtime he had created a decade earlier.

Neither company's post states a purchase price, whether the deal was cash, stock, or a mix, or any other financial terms. Coverage describing the transaction as having "undisclosed terms" is consistent with what both primary posts actually say: they simply don't mention a number.

Why Cloudflare wanted Deno's team and technology

The stated rationale, in both posts, is narrower than "Cloudflare bought a rival runtime." Cloudflare's interest is specifically in Cloudflare Workers, its serverless JavaScript platform, and in Durable Objects, the stateful compute primitive Workers apps use for things like WebSocket connections, coordination, and per-object SQLite storage. Varda explained that Deno's team had, shortly before the deal, shipped an open-source project called celld: a reimplementation of the Workers runtime designed from the ground up to be self-hostable and to scale Durable Objects beyond Cloudflare's own infrastructure, where workerd (Cloudflare's own open-source Workers runtime) had only ever run a single instance.

Rather than have two overlapping open-source projects — Cloudflare's workerd and Deno's celld — chasing the same goal, the companies say they're merging them. "We're merging workerd and celld," Dahl wrote, with his team now leading the effort to make workerd a credible option for people who want to self-host Workers-style applications instead of only running them on Cloudflare's network.

Dahl's own framing is about simplifying infrastructure he had already tried to simplify once with Deno Deploy. "I wanted to simplify that layer, too," he wrote, describing the complexity that sits underneath any hosted serverless product. He said what draws him to the Durable Objects model is that "the scaling is built into the programming model, rather than infrastructure each app has to assemble itself" — and that AI agents, which need cheap persistent compute, state, and WebSockets together, are a specific reason that model matters now.

Varda, for his part, used the announcement to push back on a complaint developers have long made about Workers: that its programming model is deliberately different from standard Node-style servers to lock customers into Cloudflare's platform. He argued the opposite — that making workerd open source and letting people run it themselves is simply "good business," pointing to Shopify having asked for an open-source Workers runtime back in 2022 before adopting Workers for Platforms. Pulling Deno's runtime engineers and celld's code into that effort is, in Cloudflare's telling, how it intends to make the Workers model "a mainstream way to build servers" rather than a Cloudflare-only one.

What happens to the standalone Deno runtime

If you run deno directly — on your own servers, in CI, in a container, wherever — Deno's blog post is explicit about what to expect. Cloudflare will "support the Deno runtime for another year with monthly releases containing bug fixes and security updates." After that one-year window, active development of the runtime stops. The project will "remain open source," and Deno says it welcomes outside contributors who want to keep developing it independently; Cloudflare also says it will keep supporting rusty_v8, the Rust bindings for V8 that Deno is built on, and intends to work it into workerd over time.

In practice, that means the runtime isn't disappearing from disk on any specific date — existing deno installations and the source on GitHub keep working exactly as they do today. What changes is the pace and nature of updates: for roughly a year you can expect security patches and bug fixes but not new features, and after that, Deno Inc.'s own engineering effort moves entirely onto Cloudflare's shared platform. Whether the open-source community picks up meaningful maintenance after that point is, as of this announcement, unknown.

What happens to Deno Deploy

Deno Deploy — the company's own hosted cloud for running Deno applications, launched in 2021 as a more developer-friendly alternative to piecing together your own serverless infrastructure — is being shut down outright, not merely deprioritized. Deno's post says the service "will continue operating for six months before shutting down," with the company offering migration support "for paying customers moving to Cloudflare Workers." Based on the October 9, 2026 announcement date, that puts Deno Deploy's shutdown at roughly early-to-mid April 2027, though neither company's post names an exact calendar date, so treat that as an approximation derived from the stated six-month window rather than a published deadline.

This is the more urgent of the two deadlines for most teams. A runtime you self-host can keep running on old bits indefinitely even after updates stop; a managed platform that's shutting down cannot. Anyone with production traffic on Deno Deploy needs a migration plan well inside that six-month window, not at the end of it.

JSR and the rest of the Deno ecosystem

Not everything Deno built is being wound down. JSR, the package registry Deno launched as a modern, TypeScript-native alternative to parts of npm's registry, continues operating — its infrastructure is moving onto Cloudflare rather than being shut off. That's a meaningfully different outcome than the standalone runtime or Deno Deploy, and worth separating out: registry continuity matters for a different reason than runtime continuity, in roughly the same way that recent scrutiny over security gaps in npm's own publishing pipeline mattered to people who'd never touch Deno's runtime directly, because a lot of JavaScript tooling quietly depends on whichever registry is behind the scenes.

Migration options, compared

For developers currently on Deno Deploy or the standalone Deno runtime, the realistic paths forward break down into a handful of options. None of them is a drop-in replacement — moving runtimes always means re-testing compatibility — but the tradeoffs differ enough to lay out directly.

What to actually do if you're affected

If Deno Deploy is in production anywhere you're responsible for, the first move is confirming your account status and any migration-assistance offer directly through Deno's own channels rather than assuming a generic timeline applies to your plan or contract. If you only use the standalone runtime for local tooling, scripts, or CI, the one-year patch window gives genuine breathing room — there's no need to rip it out this week — but it's a reasonable time to start evaluating Node.js or Bun for anything you expect to still be running in two or three years, simply because both have development roadmaps that don't depend on this acquisition's one-year clock. Teams building anything resembling Durable-Objects-style stateful compute — session state, WebSocket coordination, small per-user databases — are the clearest candidates to look directly at Cloudflare Workers and Durable Objects now, since that's explicitly where Cloudflare says the combined team's future work is going.

The money behind the deal

Deno Land Inc. was a venture-backed company, not a side project. It disclosed roughly $5.9 million in seed funding in March 2021 from investors including Shasta Ventures and the Mozilla Corporation, then announced a $21 million Series A in 2022 led by Sequoia Capital — putting its total disclosed funding at roughly $26 million. None of that history was mentioned in either company's acquisition post; it comes from Deno's own earlier funding announcements and public company records, not from the October 9 posts, and it's included here as background on the scale of the company Cloudflare has absorbed, not as part of what either company said about the deal itself.

What next

Both companies say more detail is coming. Varda wrote that Cloudflare will "have more announcements about this work in the coming months," specifically around merging celld into workerd and making self-hosted Workers-style deployments more practical. Until that detail lands, the two dates that matter are the ones already published: roughly a year of maintenance-only updates for the standalone Deno runtime, and a six-month runway before Deno Deploy shuts down with migration help for paying customers moving to Cloudflare Workers. Anything beyond those two windows — an exact Deno Deploy shutdown date, what "welcoming outside contributors" to the runtime will look like in practice, or further terms of the acquisition — has not been published by either company as of this writing, and should be treated as unconfirmed until they say otherwise.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage