Cloudflare acquired Deno: what changes for developers

Cloudflare announced its acquisition of Deno on October 9. The entire Deno team is joining Cloudflare, with future development moving toward a shared platform with Workers and Durable Objects.

For developers already using Deno, the timelines matter:

• Deno Deploy: the service will run for six more months, then shut down. Deno says paying customers will get help migrating to Cloudflare Workers.
• Deno runtime: the team plans monthly bug and security fixes for one more year, then will end its development of the runtime. Deno remains open source, so that is a maintenance commitment from the current team, rather than a claim that community development must stop.
• JSR: the package registry will continue operating, with its infrastructure moving to Cloudflare.

The infrastructure angle goes beyond a hosting migration. Cloudflare plans to combine Deno's celld with workerd, the open-source runtime behind Workers, to make distributed Workers and Durable Objects easier to run on your own infrastructure.

Durable Objects give each object an address, execution context, SQLite database and WebSocket support. That is useful for workloads with persistent state and live connections, including chat rooms and agent harnesses. Cloudflare's announcement says self-hosted workerd currently supports Durable Objects within a single instance; coordinating them across machines is the gap the combined work aims to close. Deno's celld already handles distributed placement and durable storage using object storage as its external dependency.

That portability is a stated direction for the combined platform. Teams running Deno Deploy still need a migration plan within the announced window.

Sources: Deno's announcement and Cloudflare's explanation of celld, workerd and Durable Objects.

If you're using Deno Deploy, what part of moving to Workers would need the most work: runtime compatibility, deployment tooling, or state and storage?