Cloudflare Acquires Deno, and Deno Deploy Has Six Months Left

Cloudflare acquires Deno, and the runtime that was built as a hedge against platform lock-in now belongs to one platform. The two companies posted the deal on Friday and did not disclose terms. Deno had raised $26 million, including a Series A led by Sequoia.

The mechanism is a merge of two runtimes. Cloudflare Workers runs on workerd, the runtime Cloudflare open sourced and runs in production. In August, Deno shipped celld, a self-hostable implementation of the same Workers and Durable Objects model. Ryan Dahl and Bert Belder, who built Node and then Deno, will lead the work to make self-hosting the Workers model a supported path instead of an experiment.

What changes for people already running Deno software is spelled out on the Deno blog. The runtime gets twelve more months of monthly bug and security releases, then development ends and the code stays open. Deno Deploy keeps running for six months and then shuts down, with migration support for paying customers moving to Cloudflare Workers. JSR keeps running and moves onto Cloudflare infrastructure.

The clock starts for anyone who picked Deno as a hedge

Deno was the alternative to the npm center of gravity, and Deno Deploy sold the idea that your code could move. Anyone who chose it partly to stay off a hyperscaler now has a migration inside six months, to the company the choice was meant to avoid. Kenton Varda, who runs Workers at Cloudflare, rejects the theory that Workers was built differently to create lock-in and says that being open source and offering an escape hatch is good business. Buying the escape hatch and folding it into your own runtime is a harder test of that claim.

The self-hosted path is real today, because workerd is open source and the two runtimes are becoming one codebase. TechCrunch has the deal details. Decide whether you want that path now, rather than when the migration is compulsory. Our earlier piece on Cloudflare container isolation covers what you are trusting once the workload lands on someone else’s machine.

Three questions worth asking this week. Does anything you run sit on Deno Deploy? Who owns the migration if it does? And if portability was the reason you picked your runtime, what is the plan when its owner gets acquired?