Deno Deploy Alternatives: Where to Move Before It Shuts Down

The main Deno Deploy alternatives are Cloudflare Workers, the path Deno itself names, Netlify and Supabase, whose edge functions run on Deno-based runtimes, and Render or Railway if you would rather run your app as a container. Deno's announcement of 9 October 2026 says "Deno Deploy will continue operating for six months before shutting down." It gives no calendar date, so pick a host, test your app there and move your Deno KV data before you are pushed.

Disclosure: ZeroRaised publishes this guide and the free tiers dataset it draws on, and appears in the final section. Every free plan limit below comes from that dataset, built only from each vendor's own pricing, docs and terms pages and checked 22 Oct 2026. Each vendor fact links to the vendor page it came from, fetched again on 22 Oct 2026. Technical points about runtimes link to the vendor's own documentation. ZeroRaised has no affiliate deal with any company named here.

TL;DR#

Where a Deno Deploy app can go, from each vendor's own pages, checked 22 Oct 2026:

If your app earns money, the free plan is only half the question: see the commercial-use section before you pick.

What happened: Deno is joining Cloudflare, 9 October 2026#

On 9 October 2026 (the post shows "October 9, 2026"; its machine timestamp is 15:00 UTC), Ryan Dahl published Deno is joining Cloudflare. It says "the entire Deno team is joining Cloudflare", and that Deno has "decided to put our future development work into this shared platform rather than continuing to develop a separate runtime and hosting service." Dahl calls it "a consequential change for people who have built on Deno."

What the announcement says, in its own words:

Three things follow, and nothing more should be read into it. First, the post gives no shutdown date; it says six months and stops. This guide does not turn that into a calendar date, and you should be wary of anyone who does without a newer statement from Deno.

Second, the migration support is for "paying customers moving to Cloudflare Workers." On the Free plan, or heading somewhere other than Workers, you are doing the move yourself.

Third, the runtime and the hosting service are on different clocks. The runtime keeps getting releases for another year and stays open source, so a Deno app can keep running on Deno elsewhere. What goes after six months is Deno Deploy, and the parts of your app that only exist there.

When checked on 22 Oct 2026, the Deno Deploy pricing page still listed the Free plan under a banner reading "Deno is joining Cloudflare!", with no closing date.

What your Deno Deploy app uses today#

Start by writing down what the app leans on. The Deno Deploy Free plan, "For personal use and smaller projects", gives 1M requests/month, Active CPU 10 hr, memory time 150 GiB-hr and 20GiB egress / month, and its idle apps shut down after ~20-30 seconds (Deno Deploy pricing). Deno KV on Free gets 1 GiB storage, 1,000,000 read units/mo and 500,000 write units/mo (Deno Deploy pricing).

Two things make the move harder than a redeploy. The Deno KV docs describe KV as "a key-value database built directly into the Deno runtime", and say "In production, Deno KV is backed by FoundationDB" on Deno Deploy. Your data lives on Deno's infrastructure and has to come out before the service closes. And Deno Deploy runs scheduled work for you: it "discovers your Deno.cron() definitions at deployment time, schedules and invokes them, handles retries" (Deno cron docs). On a new host something else has to do that.

The rest is usually simpler: environment variables, custom domains and a build step. List all of it, including anything set up in the dashboard and never written down.

Deno Deploy alternatives compared: free plan limits#

The ZeroRaised free tiers dataset covers 14 hosting, serverless and database platforms. These are the ones that can run JavaScript or TypeScript server code on a free plan. Figures are as each vendor writes them, checked 22 Oct 2026.

The units do not line up and the dataset does not convert them, so neither does this guide. Deno Deploy counts requests per month; Cloudflare counts them per day and caps CPU per invocation; Netlify spends credits; Render and Railway measure RAM, hours and dollars. Take your own figures from the Deno Deploy dashboard and check them against each vendor's page.

Cloudflare and Netlify stop serving at the limit rather than billing you. Render and Supabase put idle things to sleep or pause them, on a far longer timescale than Deno Deploy's idle shutdown. Railway is a paid platform with a small free on-ramp, and two vendors in the dataset have no free server compute at all: Fly.io and Firebase Spark, covered below.

Cloudflare Workers: the route Deno names#

Workers is the obvious first look, because Deno points there. It promises "migration support for paying customers moving to Cloudflare Workers" and describes celld, the project the team is taking to Cloudflare, as "Building on the Cloudflare Workers programming model" (Deno announcement). If you pay for Deno Deploy, ask Deno what that support covers before you start.

Cloudflare's Workers limits page caps Workers Free at 100,000 requests per day, "resetting at midnight UTC", and says "When a Worker exceeds this limit, Cloudflare returns Error 1027." The same page lists 10 ms of CPU time per HTTP request and 128 MB of memory. For data, Workers Free includes Workers KV with 1 GB stored data (Workers pricing), and D1, Cloudflare's SQL database, with 5 GB (total) storage, 5 million rows read/day and 100,000 rows written/day (D1 pricing). The free egress limit is not published.

The CPU model is the big difference. Deno's Free plan gives a monthly pool of Active CPU 10 hr (Deno Deploy pricing); Workers Free sets "10 milliseconds of CPU time per invocation" (Workers pricing). A route that does heavy work in one request, such as rendering a large page or parsing an upload, may fit one model and not the other. Test your slowest routes first.

What changes in your code#

Workers is not Deno, so code that calls Deno APIs has to change:

• npm packages. "Cloudflare Workers provides a subset of Node.js APIs" (Workers Node.js compatibility). For compatibility dates of 2026-08-04 or later, nodejs_compat is on by default. Check each package your app imports.
• Scheduled jobs. "Cron Triggers allow users to map a cron expression to a Worker using a scheduled() handler" (Cron Triggers docs). Each Deno.cron() job becomes a cron expression plus a handler.
• Storage. Deno.openKv() calls need replacing with Workers KV, D1 or an external database, and the data copying across.

The catch is the hard stop. Once the request cap is hit, visitors get Error 1027 until midnight UTC (Workers limits), and a launch can use a day's allowance in an afternoon. If the app earns money, budget for Workers Paid.

Netlify and Supabase: edge functions that already run on Deno#

If your app is built around Deno APIs, two vendors in the dataset run functions on Deno-based runtimes. Neither is a copy of Deno Deploy, so test before you commit.

Netlify Edge Functions#

Netlify's Edge Functions overview says the processing "happens in a secure runtime based on Deno", and that Edge Functions support frameworks "allowing your entire app to run at the edge".

The Free plan is $0 forever with a "300 credit limit / month" shared across deploys, compute, form submissions, bandwidth and web requests (Netlify pricing). Bandwidth costs "20 credits per GB" and production deploys "15 credits each". The catch: "if one project exceeds its limits, all projects on your account will be paused" (Netlify pricing). Move several small Deno Deploy apps onto one account and one busy app can pause the rest.

Supabase Edge Functions#

Supabase's Edge Functions docs say "Edge Functions are developed using Deno", and that "Supabase Edge Functions run locally, and on any other Deno-compatible platform (including self-hosted infrastructure)." The runtime is "Supabase Edge Runtime (Deno compatible runtime with TypeScript first)".

The Free plan includes Edge Functions 500,000 invocations, 500 MB database size and 1 GB file storage (Supabase pricing). It is the one free option here that bundles functions, Postgres and auth, which helps if Deno KV was your only database and the data needs a new home at the same time. The catch: "Free projects are paused after 1 week of inactivity. Limit of 2 active projects." (Supabase pricing).

Render, Railway and Fly.io: run Deno as a server#

The other way out is to run your app as an ordinary server process. Deno's Docker docs say "Deno provides official Docker files and images" and that "Docker is a common way to package and ship a Deno app: you build a reproducible image once and run it the same way everywhere." A host that runs containers can run that image. This keeps your code closest to what it is now; you give up Deno Deploy's per-request, scale-to-zero model, and the free plans are thin.

Render#

A Free web service on Render gets 512 MB RAM, and the Hobby workspace includes 5 GB of bandwidth (Render pricing). Render grants 750 Free instance hours to each workspace per calendar month (Render free docs).

The same docs list the catches. "Render spins down a Free web service that goes 15 minutes without receiving any inbound traffic", and spinning up again "takes about one minute." Free web services "have an ephemeral filesystem". And Render says of Free instances: "Do not use them for production applications." Deno Deploy's idle apps shut down after ~20-30 seconds and wake on the next request (Deno Deploy pricing); a one-minute cold start is a different experience for a customer.

Railway#

Railway offers a "30-day free trial with $5 credits, then $1 per month", with "Up to 1 vCPU / 0.5 GB RAM per service", "0.5 GB of volume storage" and egress at "$0.05 per GB" from the same credit (Railway pricing). One dollar a month that does not roll over is enough to see whether your Deno container runs, not to host a product. Read it as a paid host with a free way to test.

Fly.io#

"New organizations don’t have a free tier or a monthly free usage allowance" (Fly.io pricing). The trial lasts "up to 2 hours of Machine runtime or 7 days, whichever comes first", then a card is needed. Choose Fly.io as a paid host or not at all.

Vercel and Firebase: weak free landing spots#

Vercel Hobby lists Function Invocations 1M / month and Fast Data Transfer 100 GB / month, but the same pricing page says "Our Hobby plan is for personal, non-commercial use" and that free accounts "cannot purchase additional usage." There is no database in the plan table, so Deno KV data needs a home elsewhere. Fine for a personal project; not for anything that charges.

Firebase Spark is free ("No payment method needed"), but Cloud Functions and App Hosting are listed as "Not applicable" on Spark (Firebase pricing); their no-cost quotas apply only on the pay-as-you-go Blaze plan. A Deno Deploy app that does anything on the server has nowhere to run on Spark.

Commercial use: check before you move a paid app#

Deno described its own Free plan as "For personal use and smaller projects" (Deno Deploy pricing), so many paid apps are already on a paid Deno plan and should compare paid plans. For the free plans, the dataset's findings from 22 Oct 2026:

Not published means the terms, acceptable use and fair use pages checked did not state a rule. It does not mean allowed. The vendor-by-vendor detail, with the pages checked, is in the free tiers dataset. If revenue depends on the answer, ask the vendor in writing and keep the reply.

Mapping Deno Deploy pieces to other platforms#

Work through this with your own app open. Each row is a piece of Deno Deploy and what replaces it, as far as the dataset and the vendors' docs go. Where the dataset has no figure, the cell says so.

Where Deno KV data can go#

Deno KV is the piece most likely to slow a move down. It "is available in the Deno CLI and on Deno Deploy", and by default Deno.openKv() "creates or opens a persistent store based on the path from which the script that invoked it was run" (Deno KV docs). So an app still running on Deno, on Render for example, can keep the KV API against a local store, though the same page warns that Deno KV "is still in development and may change" and needs the --unstable-kv flag. But Render's free web services have "an ephemeral filesystem" (Render free docs), so local KV data would not survive a restart there.

For most moves, the data goes into a separate store. Free options in the dataset:

Turso's pricing page shows a "Turso is joining Supabase" banner, and the dataset notes the plan may change (Turso pricing). For free plans that cover hosting and a Postgres database together, see free startup perks without VC.

Whichever you pick, the job is the same: list every key prefix, map each to a table or namespace, export while Deno Deploy is still running, and check record counts on the other side.

A move plan for a Deno Deploy app#

Six months with no date is enough to move calmly if you start now. A plan that suits most small apps:

1. Take an inventory. Requests, CPU time and egress from the dashboard; every Deno KV key prefix; every Deno.cron() job; environment variables; custom domains; deploy triggers.
2. Decide whether you are staying on Deno. If yes, look at Netlify or Supabase Edge Functions, or a Deno container on Render or Railway. Workers is a port to a different runtime; plan time for it. Deno's own runtime support runs for "another year" (Deno announcement), so staying on Deno is a medium-term choice unless others continue its development.
3. Find the Deno-only calls. Search for Deno.openKv, Deno.cron and other Deno namespace calls. "Deno.cron() is a Deno runtime API" (Deno cron docs), so a non-Deno host needs a replacement for each.
4. Move the data before the code goes live. Export KV data, load it into the new store and run the app against a copy. Keep Deno Deploy serving until the new host has handled real traffic.
5. Switch DNS last. Lower the TTL a few days before so you can revert quickly.
6. Price the paid plan. A hard stop at Error 1027 on Workers (Workers limits), an account-wide pause on Netlify or a one-minute cold start on Render are all reasons to budget for paid hosting once people rely on the app.

Do not launch and move in the same week. Move first, let it run quietly, then launch; how to handle traffic spikes covers what to check before a spike, which matters more on a plan with a hard cap. If the app was built quickly with AI tools, run the vibe coded app security checklist during the move, since that is when secrets get copied around.

And do not start a new project on Deno Deploy now. Its own announcement says it will shut down, whatever the allowances say.

Where ZeroRaised fits#

Hosting is one of the first bills a bootstrapped product meets, and a forced move is one of the less welcome ones. ZeroRaised keeps the free tiers dataset for that reason: free plans for 14 hosting, serverless and database platforms, each figure linked to the vendor's own page with a visible check date. You can download it as a CSV from the same page, and the ZeroRaised data hub lists it with the other datasets. If a vendor's page has changed since 22 Oct 2026, the vendor's page wins.

ZeroRaised is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. Once your app is settled on its new host, you can submit it for review. The maker perks page lists separate offers for eligible makers, some of which cut hosting and running costs.

So, Deno Deploy alternatives in one line: Cloudflare Workers is the route Deno names, Netlify and Supabase keep you on Deno-based runtimes, Render and Railway can run a Deno container, and whichever you choose, move your Deno KV data and scheduled jobs early because the announcement gives six months and no date.