Cloudflare bought Deno and gave customers six months. What is your vendor lock-in exit plan?

On 9 October 2026, Deno announced that it is joining Cloudflare and that Deno Deploy will continue running for another six months before shutting down. Your platform could do the same to you. A vendor lock-in exit plan should account for four layers before a shutdown deadline is announced: code, data, configuration, and identity. Standard request-handling code is relatively easy to move. Proprietary data and platform-specific bindings are harder to replace, so reducing those dependencies should come first.

Key facts

In this article

• What did Deno announce, and what does six months cover?
• Why is lock-in worse on a managed platform than on a server?
• What makes a platform hard to leave?
• How do you score your own lock-in?
• What do past platform shutdowns tell you about notice periods?
• What should a vendor lock-in exit plan cut now, before anyone gives you a deadline?
• If you are on Deno Deploy today, what is the order of work?
• Where RocketDevs fits
• Conclusion: your exit plan is part of your architecture
• Frequently asked questions

What did Deno announce, and what does six months cover?

Deno Deploy, Deno’s hosted serverless platform, will continue operating for six months before shutting down. Deno will provide migration support to paying customers moving to Cloudflare Workers. The Deno runtime will receive maintenance releases for another year before development ends.

In its announcement on 9 October 2026, Deno confirmed that Deploy would operate for six more months and that paying customers moving to Cloudflare Workers would receive migration support. The company also committed to monthly runtime releases containing bug fixes and security updates for another year. After that, Deno will stop developing the runtime. It will remain open source, and Deno welcomes others who want to continue maintaining it. JSR, Deno’s package registry, will continue operating, with its infrastructure moving to Cloudflare.

Deno has not published exact calendar dates for either cutoff. Based on the announcement date, the six-month deadline falls around 9 April 2027, while the runtime’s maintenance period ends around October 2027. These are calculated estimates, not dates confirmed by Deno. Plan against the earliest plausible deadline rather than assuming you will have the full period available.

The table highlights an important distinction: what Deno has confirmed is not the same as what customers can safely assume. Its announcement names Deploy, the runtime, JSR and rusty_v8, but does not explain what will happen to every product or customer group.

Deno’s pricing page lists four plans: Free at $0 per month, Pro at $20, Builder at $200 and a custom Enterprise tier. The pricing page also says its pricing covers Deno Deploy products and usage, including Deno Sandbox and Deno Subhosting. Yet the announcement does not explain what happens to free users, Deno KV data, Subhosting customers running other people’s code, or Sandbox users.

If your application depends on any of these services, treat the outcome as unresolved rather than assuming the service will continue or shut down. Ask Deno for written clarification about your specific products, data, migration options and deadlines. Getting those answers now gives you more time to plan before the shutdown affects your operations.

The financial terms of the acquisition have not been disclosed. TechCrunch and The New Stack both reported that Deno had raised $26 million.

The announcement also attracted considerable attention. By 07:25 UTC on 11 October, the Hacker News discussion had reached 1,348 points and 700 comments. English Wikipedia user pageviews for Deno rose from 69 on 8 October to 1,051 on 9 October and 1,279 on 10 October. These figures suggest that many people were reassessing a technology they might depend on.

There is a telling detail in the history of the two companies. In June 2022, TechCrunch reported that Deno creator Ryan Dahl saw Cloudflare Workers as Deno Deploy’s closest competitor. Four years later, Cloudflare has acquired Deno, and Deploy customers are being directed towards Workers.

The lesson for founders is not that every platform will shut down. It is that a vendor’s future plans can change in ways you cannot predict. You may not know which acquisition, shutdown or pricing change will affect your business, but you can prepare for the possibility. The cost of an exit depends on how easily you can move your code, data, configuration and identity systems when the time comes.

Why is lock-in worse on a managed platform than on a server?

The more work a platform handles for you, the more your application depends on its specific tools and features. This makes it harder to move elsewhere. Research into cloud migration has found that vendor lock-in becomes more challenging as businesses move from their own servers to managed cloud services.

A peer-reviewed survey of 114 UK IT professionals and decision-makers by Opara-Martins, Sahandi and Tian found that moving computing resources from on-premises systems to the cloud can worsen vendor lock-in. Published in the Journal of Cloud Computing, the study also found that 35.1% of respondents identified loss of control and over-dependence on one provider as core barriers.

Research by Zhao, Benomar, Pfandzelter and Georgantas examines the same problem in serverless computing. Their preprint argues that the higher level of abstraction makes vendor lock-in inherent to serverless computing, raising more concerns than earlier cloud models.

The difference comes down to how much of your application depends on the platform. A virtual machine leaves most of the application’s behaviour under your control, so moving to another provider is largely an infrastructure and operations task. A serverless platform may also provide your database, message queue, scheduled jobs and secrets management. Building with these services can speed up development, but replacing them later means finding alternatives and adapting the code that depends on them.

This does not mean you should avoid managed platforms. For a seed-stage startup, spending three weeks building portable infrastructure instead of getting a product to market can be the more expensive decision. The goal is to understand your potential exit costs, keep them manageable and avoid dependencies that would be relatively easy to prevent or replace. The next step is to identify which parts of your application would be most expensive to move.

What makes a platform hard to leave?

Four layers determine how difficult and expensive it is to leave a platform: request-handling code, data and platform APIs, deployment configuration, and identity and secrets. On modern JavaScript runtimes, the first layer is often relatively cheap to move. The other three usually account for more of the migration effort.

The move from Deno Deploy to Cloudflare Workers is a useful example because the platforms have much in common. Both run JavaScript and TypeScript request handlers using web standards, and the team behind Deno is now joining Cloudflare. If migration still involves substantial work between two closely related platforms, moving between less compatible systems can be even more expensive.

The cheap layer: code that speaks web standards

Request-handling code that accepts a standard Request object and returns a Response object is among the most portable parts of an application. Deno's HTTP server documentation explains that Deno.serve uses these web-standard objects and that a server can also be created by exporting a default fetch function. Cloudflare Workers uses the same approach: incoming requests reach a fetch() handler as Request objects, and the handler returns a Response.

This compatibility reflects a wider effort to standardise JavaScript runtime environments. In December 2025, Ecma International's TC55 committee, known as WinterTC, published ECMA-429, the Minimum Common Web API. The standard defines a minimum set of capabilities shared by browser and web-server environments based on ECMAScript.

When TechCrunch covered the initiative in 2022, it described the goal as allowing applications to move between Workers, Deno and Node.js without a rewrite. That goal is now much more achievable for request-handling code, although compatibility still depends on which APIs an application uses.

Node.js compatibility has narrowed the gap further. Cloudflare states that Workers projects using compatibility dates of 4 August 2026 or later enable nodejs_compat and nodejs_compat_v2 by default. This reduces the configuration needed to use Node.js built-in modules in new projects.

The practical test is to search your codebase for platform-specific namespaces and imports. Look for Deno. references, cloudflare: imports and equivalent platform-specific APIs used by Vercel, Netlify or Supabase. If these appear throughout your application, migration will require changes across multiple files. If they are concentrated in one adapter, you have already limited the work involved.

The expensive layers: data, platform APIs and bindings

Data is often where migrations slow down. Two platforms can offer services with the same name without providing the same behaviour or guarantees. Deno KV and Cloudflare Workers KV are both key-value stores, but their consistency models differ.

Deno documents that its production KV service is backed by FoundationDB and provides strongly consistent writes. Its documentation also describes Deno KV as a feature still in development that may change and requires the --unstable-kv flag. Cloudflare Workers KV, by contrast, is eventually consistent. Changes made in one location can take 60 seconds or longer to become visible elsewhere.

That difference matters when application code reads a value immediately after writing it. An operation that works reliably with Deno KV may return stale data when moved to Workers KV. Fixing the problem could require redesigning the affected code rather than simply changing a database connection.

Cloudflare offers other storage options with different characteristics. D1 is a managed serverless database with SQLite's SQL semantics. Durable Objects provide strongly consistent storage associated with individual objects. For Deno KV data that requires strong consistency, either may be a more suitable migration target than Workers KV. The right choice depends on how the application uses its data, so this decision requires architectural work rather than a simple migration script.

Deno's own migration history illustrates the problem. On 20 July 2026, Deno shut down Deploy Classic and the Subhosting v1 API. Its migration guide explained that the newer Deno Deploy did not support Deno KV queues through Deno.Kv.enqueue() and Deno.Kv.listenQueue(). Affected teams needed an external message queue or a database-backed job queue. Existing KV data also did not migrate automatically.

This was a move between two products from the same vendor, yet the data and queue layers still required separate work. Teams that completed that migration in July now face another platform change following the acquisition.

Scheduled jobs and storage bindings create similar problems. Deno providesDeno.cron() for scheduled tasks, while Cloudflare uses Cron Triggers configured for Workers. Neither mechanism is necessarily difficult to replace, but each dependency must be identified, adapted and tested before the shutdown deadline.

The configuration and identity layers

Configuration and identity are easy to overlook because they often sit outside the application code. Custom domains, DNS records, environment variables, edge caching rules, preview environments, continuous integration and deployment steps, and webhook endpoints may be spread across a vendor's dashboard and configuration files. Without a complete inventory, teams can discover missing pieces only when they attempt to move.

Secrets present a particularly sharp problem. Cloudflare explains that secret values cannot be viewed through Wrangler or the dashboard after they have been defined. This protects credentials from exposure, but it also means the platform cannot serve as your only source of truth.

If an API key exists only in a vendor's secret store, migration may require rotating that key and updating the systems that use it. If a third-party service must approve or process the change, the work may also depend on someone else's response time. A migration plan should therefore record where credentials are managed and how they can be replaced without interrupting production.

Why a self-hostable runtime changes the calculation

A runtime that you can operate yourself changes the nature of vendor lock-in. If a managed platform closes, an open-source runtime that supports your application may offer another way to keep it running. Self-hosting can still be expensive, but it gives you an alternative to rebuilding everything on a different platform.

This is relevant to the Deno acquisition. In its announcement, Cloudflare said Ryan Dahl and Bert Belder would lead an effort to make workerd self-hosting a first-class, supported way to build and run applications using the Workers programming model. The plan includes merging code and ideas from celld back into workerd.

Both projects are available for inspection. Workerd is Cloudflare's Apache-2.0-licensed Workers runtime. Its documentation describes how it can serve as an application server for self-hosting applications designed for Cloudflare Workers. However, its README warns that workerd is not a hardened sandbox, so teams must not assume it provides the security isolation required for every production workload.

Celld is an Apache-2.0-licensed project created in April 2025. Its website lists support for Workers, Durable Objects, KV, Queues, D1, R2, Workflows, Cron Triggers and static assets. It also states that application data can live in a bucket the operator owns, while identifying services that require Cloudflare's network, GPUs or browser infrastructure as outside its scope.

There is an important limitation. Cloudflare acknowledges that workerd implements Durable Objects in a single-instance form suitable for local testing but unable to scale in the same way as the managed service. Celld is also labelled beta. These projects show a possible path towards greater portability, but they are not yet a complete, proven replacement for every production dependency on Cloudflare.

Cloudflare argues that open-sourcing its runtime was a response to customer demand. In his account of the company's Workers for Platforms offering, Kenton Varda explained that customers such as Shopify needed the runtime to be open source before they could build on it with confidence. Cloudflare also says some former customers have migrated away using workerd.

Those claims come from Cloudflare, which has a commercial interest in presenting its platform as a low-risk choice. They should be considered in that context. Nevertheless, the underlying principle is sound: when you have a credible way to run your application independently, staying with a provider becomes more of a choice than a necessity.

Deno's decision to end runtime development reinforces the same lesson from another direction. In a Hacker News comment quoted by Simon Willison, Ryan Dahl explained that Deno had been pulled towards Node.js compatibility and that he no longer believed this was where he could do his most important work.

For founders, the implication is straightforward. A vendor's roadmap reflects its own priorities, which may change even when customers still depend on its products. Portability does not mean avoiding every platform-specific feature. It means understanding which dependencies you are accepting, how difficult they would be to replace and whether you have a credible alternative if the vendor's priorities change.

How do you score your own lock-in?

Score each of the four layers by asking one question: if you had to move to another platform within 90 days, what would you need to rewrite, export or recreate manually? Anything you cannot answer in an afternoon is a gap in your migration plan.

Use the table below as a checklist. The questions apply to any managed platform, not just Deno or Cloudflare. The final column shows what you can do now to make a future move cheaper.

Score each layer honestly and estimate how many engineer-days a migration would require. Request-handling code may take days to adapt, while deployment configuration and identity can each require a week of careful work. Data is the biggest uncertainty because the cost depends on how deeply your application relies on one provider's storage guarantees.

A useful estimate should include the work required to test the migration, not just rewrite the code. Record your assumptions and identify what needs to be verified. An export that has never been tested is not a reliable exit plan.

The developer ecosystem can also indicate how much migration guidance you are likely to find. In the 30 days to 9 October 2026, npm recorded108,790,988 downloads of wrangler, Cloudflare's Workers CLI, compared with 988,858 downloads of the deno package and 19,237 downloads of @deno/kv. These figures include automated installations and mirrors, so they measure package download activity rather than the number of teams using each platform. They nevertheless show a substantial difference in tooling activity, which can affect how much community support is available.

The 2025 Stack Overflow Developer Survey offers another indication of the difference in ecosystem reach. Of the 24,473 respondents who answered the cloud-platform question, 20.1% reported extensive work with Cloudflare. Of the 23,678 respondents who answered the web-framework question, 4% reported the same for Deno. Because these figures come from different questions, they should not be treated as a direct comparison of market share.

Stack Overflow's tagged questions show a similar gap in publicly documented troubleshooting. On 11 October 2026, per the Stack Exchange API, 21 questions carried the deno-deploy tag, compared with 462 tagged cloudflare-workers. There was no deno-kv tag.

If your application depends on Deno KV, expect to find less community guidance for migrating that data layer. Document your data model, consistency requirements and export process now, while you still have time to test alternatives.

What do past platform shutdowns tell you about notice periods?

Notice periods for platform shutdowns have ranged from roughly ten weeks to a year. The vendor sets the deadline, not the customer, and six months falls somewhere in the middle. But the length of the notice period is only part of the story. What matters just as much is whether customers can take the software with them.

Heroku is a useful example for small teams. On 25 August 2022, Heroku announced that it would stop offering free product plans from 28 November and begin shutting down free dynos and data services, as TechCrunch reported the same day. It also planned to start deleting long-inactive accounts from 26 October. Customers had roughly three months to prepare, with paid dynos starting at $7 per month as an alternative.

The lesson is that a shutdown does not always mean a product becomes unavailable to everyone. Sometimes the vendor ends a free tier rather than the underlying service. However, customers who built their products around the free offering still had to find the money for a replacement or migrate elsewhere.

Parse shows what a more customer-friendly exit can look like. On 28 January 2016, Facebook announced that Parse would shut down exactly one year later, per Wikipedia's entry on Parse and CODE Magazine's account at the time. It also open-sourced Parse Server on the announcement date, allowing customers to run the software themselves.

The Parse Server repository was created that day and continued receiving commits as of 11 October 2026. Giving customers a year to prepare while providing software they could operate independently turned the shutdown into an infrastructure migration rather than a forced rewrite of the entire application.

Fauna is the example to remember when someone argues that six months is too short. Its shutdown announcement was published on 19 March 2025 and reached Hacker News that day. According to InfoQ, the service was scheduled to end on 30 May, with customer accounts deleted. That left roughly ten weeks to migrate from a serverless database.

Fauna also indicated, per The Register, that its core technology would be open-sourced. However, an open-source codebase is not the same as a ready-to-use replacement for a hosted service. Customers still need to deploy and operate the software, migrate their data and test that the replacement behaves as expected.

Bun provides a different perspective. When Anthropic acquired the runtime in December 2025, Bun and Anthropic both said it would remain open source under the MIT licence, and Bun said the existing team would continue working on it. No shutdown was announced.

An acquisition, therefore, does not automatically mean customers must migrate. The outcome depends on what the acquiring company intends to do with the product. A company might continue developing it, incorporate its technology into another service or eventually discontinue it.

Across these examples, the pattern is clear: you cannot control how much notice a vendor gives you, but you can control how prepared you are when that notice arrives. Keeping your code portable, maintaining independent data exports and documenting your configuration gives you a head start regardless of whether you receive ten weeks, six months or a full year.

What should a vendor lock-in exit plan cut now, before anyone gives you a deadline?

Start by removing the dependencies that are cheap to fix and estimating the cost of those that are not. Put platform-specific calls behind one adapter, export data continuously to storage you control, move dashboard settings into your repository, keep secrets in an independent source of truth, and prove you can deploy to a second target. Each task is manageable during a normal working week but can become a crisis when a shutdown deadline is approaching.

The export test comes first because it reveals the risks that can be hardest to estimate. Do not simply check whether your vendor offers an export feature. Run the export, restore the data somewhere else and test whether the application still behaves correctly.

Deno Deploy, for example, supports continuous backups of KV databases to S3-compatible storage that you control. Deno explains that these backups can support a read-only data replica independent of Deploy. If your application uses Deno Deploy and you have not configured backups, make that a priority. Cloudflare D1 also supports exporting databases to SQL files, giving you a way to preserve the data independently of the managed service.

Secrets are another relatively inexpensive problem to address before a deadline. Some platforms do not let you view a secret again after you save it. Keeping an independent source of truth means you can supply credentials to a replacement platform without having to reconstruct every secret from scratch. You may still need to rotate credentials for security reasons, but you avoid making rotation the only way to recover missing values.

Configuration belongs in your repository for the same reason. A new engineer should be able to recreate your production setup from documented files and instructions. If the only person who knows how the caching rules work is the person who configured them in a dashboard, your exit plan depends on that person's memory.

The adapter is a small code change with potentially significant benefits. Instead of rewriting platform-specific calls throughout your application, you can concentrate the changes in one place. The amount of time saved depends on the application, but separating provider-specific code makes the migration scope easier to understand and test.

A second deployment target helps keep that separation intact. Without automated testing against another environment, platform-specific calls can gradually spread back into the codebase. A second build target can expose those dependencies while they are still easy to fix, rather than during an emergency migration.

There is also a contractual consideration for businesses that buy cloud services in the EU. The EU Data Act has applied since 12 September 2025 and includes provisions intended to make switching between data-processing services easier. These include a maximum two-month notice period for initiating the switching process, a mandatory transitional period of up to 30 calendar days with reasonable assistance, and the removal of switching charges from 12 January 2027.

These provisions concern switching initiated by the customer. They do not guarantee that a vendor shutting down a product will give you the same notice period. Check your contracts for data-export provisions, assistance with migration and any relevant exceptions rather than assuming the legislation eliminates your risk.

The goal is not to make every part of your stack interchangeable. It is to identify what you would lose control over if a vendor changed direction, then reduce the cost of replacing those dependencies while you still have time to do it properly.

If you are on Deno Deploy today, what is the order of work?

Inventory first, then get your data out, then choose a target, then run both in parallel before you cut over. Deno has said Deploy runs six months and that migration support is for paying customers moving to Workers, so if you are on the free plan, assume you are doing this yourself.

Where RocketDevs fits

A vendor exit plan is mostly unglamorous engineering. It means building an adapter so platform-specific code can be replaced without rewriting the entire application. It means automating data exports and testing that the data can be restored elsewhere. It means adding a second deployment target to your CI pipeline and keeping configuration and secrets under your control.

For a small team, this work is easy to postpone. It rarely blocks the next release, brings an immediate new feature to customers or produces a visible improvement to the product. Yet when a provider announces a shutdown, those unfinished tasks can quickly become urgent. The team must migrate its infrastructure while keeping the existing product running, supporting customers and continuing to deliver planned work.

The challenge is not simply finding someone who can write the code. It is finding an engineer who can understand an unfamiliar system, identify its dependencies and turn a broad migration into a sequence of manageable tasks. Experience with previous migrations can help, particularly when an engineer understands how seemingly small differences in data consistency, authentication or deployment configuration can create larger problems during a move.

RocketDevs helps companies add engineering capacity through developers who have completed 6-8 hours of technical assessment. The platform accepts the top 2% of applicants and rejects 98%+, giving businesses access to a vetted pool of engineering talent.

For a team facing a platform deadline, an additional engineer can take ownership of the migration work while the core team continues building and maintaining the product. Depending on the application and the engineer's experience, that work could include documenting platform dependencies, implementing an export and recovery process, separating vendor-specific calls from application logic, or preparing and testing a deployment on the replacement platform.

The appropriate level of experience depends on the migration. An Associate developer may be suitable for well-defined implementation and testing tasks under senior supervision. A Mid-senior developer can take on more independent delivery work. A Senior developer may be better suited to leading the technical assessment, evaluating replacement architectures and making decisions about data migration and production cutover.

RocketDevs rates are $9.99/hr for Associate engineers, $21.99/hr for Mid-senior engineers and $30.99/hr for Senior engineers. The service also offers a 14-day risk-free trial with a money-back guarantee, honoured 100% of the time. These options give teams a way to add capacity without treating every migration task as a permanent hiring commitment.

The key is to bring in help before the deadline becomes an emergency. Start with a clear inventory of your dependencies, identify the data and services that will be hardest to replace, and assign someone responsibility for testing the exit plan. Your core team can then keep shipping while the migration work progresses alongside product development.

If a vendor deadline has started the clock on your infrastructure, explore RocketDevs to find vetted engineering support before the remaining time becomes your biggest constraint.

Conclusion: your exit plan is part of your architecture

Deno's decision to join Cloudflare is a reminder that the future of your infrastructure is not entirely yours to control. A platform that works perfectly today can become a migration project tomorrow. You may get six months to move, a year of maintenance releases, or much less time than your team needs. By the time the announcement arrives, the negotiation is over. You are working to someone else's deadline.

You cannot prevent a vendor from changing direction. You can control how expensive that decision becomes for your business.

That starts with knowing what you depend on. Keep your application code as portable as practical. Export your data before you need it. Keep configuration and secrets under your control. Put provider-specific functionality behind clear boundaries, and test that your application can run somewhere else. These are not distractions from building your product. They are what allow you to keep building it when the infrastructure underneath it changes.

You do not need to make every component interchangeable or pay to maintain a complete duplicate of your production environment. You need to know where the real dependencies are, what it would take to replace them, and whether your team has the capacity to do so before the clock runs out.

That last part matters. An exit plan that exists only in a document is an assumption, not a capability. Someone must implement it, test it and keep it current. If your core team is already stretched between customer commitments and product delivery, bring in the engineering capacity to tackle that work before it becomes an emergency.

The best time to plan your exit is while you still have the freedom to choose when to leave. The next vendor announcement may give you six months. Your architecture should not need all six just to find the door.

If your team needs experienced engineering support to reduce platform dependencies, test a migration path or prepare for a forced move, RocketDevs can help you find vetted developers to get the work moving while your core team keeps shipping.

Frequently asked questions

When does Deno Deploy shut down?

Deno announced on 9 October 2026 that Deno Deploy will continue operating for six months before shutting down. It has not published an exact calendar date. Counting six months from the announcement gives approximately 9 April 2027, but that is an estimate, not a confirmed deadline. Plan to complete your migration earlier so you have time to test the replacement and resolve unexpected problems.

Will the Deno runtime keep working?

Yes. Deno has committed to monthly bug-fix and security releases for another year, after which it will stop developing the runtime. The runtime will remain open source, so developers can continue using it or maintain their own versions. However, Deno will no longer be committed to fixing new bugs or security vulnerabilities after its maintenance period ends. Running Deno in a container elsewhere can provide a temporary alternative to Deploy, but you should have a longer-term maintenance plan.

Can I move Deno code to Cloudflare Workers without rewriting it?

Much of the request-handling code may transfer with relatively little change. Both platforms support web-standard Request and Response objects, which makes it easier to move code that uses these interfaces. However, code that relies on Deno-specific APIs, including Deno KV and Deno Queues, needs additional work. The data layer may require a more substantial redesign because Deno KV and Cloudflare's storage services do not necessarily behave the same way. For example, Workers KV is eventually consistent, so changes may take time to appear across locations. Test your application's data requirements before choosing the replacement architecture.

Will Deno help me migrate from Deno Deploy?

Deno has said it will provide migration support to paying customers moving to Cloudflare Workers. The announcement does not clearly establish what assistance will be available to free-plan users, or mention the arrangements for Deno KV data and Subhosting customers. If your application depends on these services, ask Deno in writing what applies to your account, what migration assistance you can access, and how you can export your data. Do not assume that migration support means your application and its data will transfer automatically.

How can I reduce vendor lock-in without slowing down development?

Focus first on dependencies that are relatively inexpensive to make portable. Put platform-specific calls behind an adapter, export data regularly to storage you control, and keep configuration and secrets in systems you can access independently of your hosting provider. Add a second deployment target to your continuous integration pipeline so you can test whether the application runs elsewhere. You do not need to make every component interchangeable. You need to understand which dependencies would be difficult to replace and test your ability to move before a deadline forces you to do so.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Deno, Deno is joining Cloudflare, Ryan Dahl, 9 October 2026
• Cloudflare, Deno is joining Cloudflare, Kenton Varda and Ryan Dahl, 9 October 2026
• Deno, Deno Deploy pricing, read 11 October 2026
• Deno docs, Writing an HTTP server, read 11 October 2026
• Deno docs, Deno KV quick start, read 11 October 2026
• Deno docs, Deno KV backups, read 11 October 2026
• Deno docs, Migrating from Deploy Classic to Deno Deploy, read 11 October 2026
• Cloudflare docs, Workers fetch handler, read 11 October 2026
• Cloudflare docs, Node.js compatibility, read 11 October 2026
• Cloudflare docs, How KV works, read 11 October 2026
• Cloudflare docs, D1 overview, read 11 October 2026
• Deno docs, Cron, read 11 October 2026
• Cloudflare docs, Cron Triggers, read 11 October 2026
• Cloudflare docs, D1 import and export, read 11 October 2026
• Cloudflare docs, Workers secrets, read 11 October 2026
• celld, project site, read 11 October 2026
• workerd README, GitHub, read 11 October 2026
• GitHub API, cloudflare/workerd, read 07:25 UTC 11 October 2026
• GitHub API, denoland/celld, read 07:25 UTC 11 October 2026
• GitHub API, denoland/deno, read 07:25 UTC 11 October 2026
• GitHub API, parse-community/parse-server, read 07:25 UTC 11 October 2026
• Ecma International, ECMA-429 Minimum common web API, 1st edition, December 2025
• Hacker News thread, story 50019911, read 07:25 UTC 11 October 2026
• Hacker News, Fauna Service Winding Down, item 43414742
• Wikimedia pageviews API, Deno (software), read 11 October 2026
• npm downloads API, wrangler, read 11 October 2026
• Stack Overflow, 2025 Developer Survey, technology
• Stack Exchange API, deno-deploy tag, read 11 October 2026
• TechCrunch, Cloudflare acquires Deno to improve its Workers programming model, 10 October 2026
• The New Stack, Cloudflare acquires Node.js creator's startup that copied its serverless playbook, Paul Sawers, 9 October 2026
• Simon Willison, Deno is joining Cloudflare, 9 October 2026
• TechCrunch, Deno raises $21M to launch a fully managed runtime service, 21 June 2022
• Opara-Martins, Sahandi and Tian, Critical analysis of vendor lock-in and its impact on cloud computing migration, Journal of Cloud Computing, 2016
• Zhao, Benomar, Pfandzelter and Georgantas, Supporting Multi-Cloud in Serverless Computing, arXiv 2209.09367
• European Union, Regulation (EU) 2023/2854, the Data Act, Official Journal text
• Heroku, Heroku's next chapter, Bob Wise, 25 August 2022
• TechCrunch, Heroku announces plans to eliminate free plans, Kyle Wiggers, 25 August 2022
• RedMonk, The end of Heroku's free tier, Kate Holterhoff, 1 December 2022
• Wikipedia, Parse, Inc., read 11 October 2026
• CODE Magazine, Parse is set to shut down. Now what?
• InfoQ, Fauna shutting down: is the future open source?, Renato Losio, March 2025
• The Register, FaunaDB shutters but hints at open source future, Lindsay Clark, 24 March 2025
• Bun, Bun is joining Anthropic, Jarred Sumner, 2 December 2025
• Anthropic, Anthropic acquires Bun as Claude Code reaches $1B milestone, 3 December 2025