Deno is joining Cloudflare and Deno Deploy shuts down in about six months. Check where your webhooks and scripts run

Small hosted scripts are the forgotten part of most automation stacks. One platform just gave its users a shutdown date.

What happened

On October 9, Deno announced that its entire team is joining Cloudflare. Cloudflare's blog says the goal is to merge its open source Workers runtime, workerd, with celld, Deno's open source implementation of the Durable Objects pattern, so developers can self host the Workers programming model on their own infrastructure. Deno creator Ryan Dahl describes celld as one Rust binary whose only external dependency is object storage.

The changes for existing users, from Deno's own post:

• The Deno runtime gets one more year of monthly releases with bug fixes and security updates. After that, Deno will end development, though the runtime stays open source.
• Deno Deploy, the hosting service, will keep operating for six months and then shut down. Paying customers moving to Cloudflare get migration support.
• JSR, the package registry, continues operating.

Dahl also wrote that Durable Objects suit agent harnesses because they combine cheap serverless execution, persistent state, WebSockets and a simple JavaScript interface.

My take

Most businesses I work with have a layer nobody tracks: the little webhook receiver, the cron script that syncs a spreadsheet, the endpoint that cleans form data before it hits the CRM. They were set up once, they work, and they live on whatever free or cheap host the builder liked that year.

When a host closes, those break quietly. Leads stop flowing, and nobody notices until a sales rep asks why the pipeline is empty.

If you or your developer used Deno Deploy, you have roughly six months. Even if you did not, this is a good prompt to do a short inventory:

1. List every script, webhook and scheduled job outside your main tools like Zapier, Make, n8n or your CRM.
2. Note where each one runs, who owns the account and where its secrets are stored.
3. Flag anything on a platform with an announced end date and plan the move early.
4. Add a simple health check, so a dead endpoint raises an alert instead of silence.

Hosting choices should be boring and documented. That is what lets the automations on top of them stay reliable.