The Deno team is joining Cloudflare, according to the October 9 announcement on deno.com. The runtime will get one year of continued support before it ends. Deno Deploy, the hosting platform, has a shorter runway: six months. Anyone running Deno in a production pipeline, cron job, or edge function now has a countdown attached to it, whether they noticed the announcement or not.
The announcement confirms the team move and the two support windows. It does not specify what happens to open issues, security patches, or paid support contracts during that year, nor does it say whether Cloudflare will offer a migration path for Deploy workloads. Those gaps matter more than the headline. A team joining a company is a personnel fact. A support end date is an operational one, and the two are not guaranteed to move in lockstep if priorities shift inside Cloudflare over the next twelve months.
For on-call engineers, the immediate task is inventory, not migration. Find every service that depends on the Deno runtime or Deno Deploy specifically, including build steps, test runners, and edge middleware that might have been added by a contractor two years ago and forgotten. Six months sounds generous until a Deploy-hosted function sits upstream of a billing API and nobody owns the ticket to move it. The failure mode here is not a dramatic outage. It is a quiet expiration: patches stop, a dependency drifts, and the break shows up as a mystery incident months after the deadline passed.
Context matters here because runtime deprecations rarely announce themselves with a single clean date. Node and Python end-of-life cycles tend to get buried in release notes that few teams read until a CVE forces the issue. Deno's case is unusual in that the deadline is explicit and public, which is useful, but it still requires someone to connect the calendar date to the specific services running the software. If an organization has no internal registry of which workloads run on Deno versus Deploy versus a self-hosted equivalent, that registry needs to exist before the six-month Deploy clock becomes a problem.
The open question is what Cloudflare does with the technology after the support windows close. The announcement does not say whether Deno becomes a Cloudflare product, gets folded into Workers, or is left to the open-source community without a formal maintainer. That ambiguity is the real planning risk, more than the dates themselves. A team deciding whether to migrate off Deno now or wait for clarity is making a bet on Cloudflare's roadmap, not on the current announcement, and that roadmap has not been published.
Six months is the number to put on a calendar today, specifically for anything running on Deno Deploy.