The usual questions about where to run TypeScript functions are latency and cost. Deno Deploy users now have a blunter one: the platform is going away. On October 9, 2026, Ryan Dahl said the whole Deno team is moving to Cloudflare and that Deploy will shut down six months later, which puts the deadline around April 2027.
I spent a day sizing the migration on a real codebase and pricing the main destinations. This is the condensed version; the complete guide on DevToolLab has the audit script, every pricing line and screenshots of each platform.
What Ends and What Survives
Per Deno's announcement, Deploy runs for six more months and then closes. Deno Land will keep shipping runtime patches, bug and security fixes once a month, for a year and then stop working on the runtime; the code stays open source, MIT licensed as it is today. JSR keeps operating while its infrastructure moves to Cloudflare, and rusty_v8 stays supported while the team plans to fold it into workerd.
Paying customers get migration help, but the announcement only mentions moving to Cloudflare Workers. Deno Sandbox and Subhosting share Deploy's plans ($0 Free, $20 Pro, $200 Builder), and nobody has said what happens to them.
Most of the Pain Lives in a Few Files
Five kinds of Deno-only code make a Deploy app hard to move: KV reads and writes, KV queues, Deno.cron jobs, Deno.* file access and jsr: package imports. I wrote a small Node script that counts those patterns in a project, then ran it against SaaSKit, Deno's own Fresh SaaS starter built for Deploy (now archived, last commit February 9, 2026):
69 source files scanned
Deno.openKv() 1 hits in 1 files
KV atomic / watch / listenQueue 5 hits in 1 files
Deno.cron 0 hits in 0 files
BroadcastChannel 0 hits in 0 files
Deno.serve 0 hits in 0 files
Deno.env 5 hits in 3 files
Deno filesystem calls 5 hits in 2 files
jsr: imports 10 hits in 2 files
npm: imports 8 hits in 2 files
https:// URL imports 1 hits in 1 files
The interesting part is concentration. All of SaaSKit's KV usage sits in utils/db.ts, a 483-line module with 15 KV calls that 22 other files import. Swapping storage means rewriting that one module, not the app. The script itself is about 40 lines and is in the original post if you want to point it at your own repo.
Seven Places to Go
The worked example throughout: a SaaSKit-shaped app with an AI chat endpoint, KV for users and sessions, and roughly 3 million requests a month.
| Platform | Deno code unchanged? | KV replacement | Example month |
|---|---|---|---|
| Cloudflare Workers | No | Workers KV, D1, Durable Objects | $5 |
| Supabase Edge Functions | Mostly | Postgres | $27 |
| workerd + celld | No | Durable Objects | your servers |
| Netlify Edge Functions | Mostly | Netlify Blobs | $9 |
| Fly.io | Yes, it runs Deno | self-hosted denokv | about $4 |
| Val Town | Mostly | per-val SQLite | $25 |
| Vercel Functions | Community runtime only | Blob or a database | $20 and up |
Cloudflare Workers
The Deno engineers now work on this platform, and it is the one target the migration offer names. Durable Objects give each object its own SQLite database plus WebSockets, a good fit for agent-style workloads, and Deno.cron maps to Cron Triggers.
There is no Deno global here, so SaaSKit's database module needs rewriting, as does each Deno.env lookup. The Paid plan is $5 a month with 10M requests and 30M CPU milliseconds included; at 5 ms of CPU per request and KV inside its included reads and writes, the example stays at $5. The free plan caps CPU at 10 ms per invocation.
Supabase Edge Functions
Supabase's Edge Runtime is Deno-compatible and MIT licensed, so most handler code moves with light edits, and Postgres replaces KV with pg_cron for schedules. Each hosted invocation is limited to 2 seconds of CPU time and 256 MB of RAM. Pro is $25 a month with 2M invocations, then $2 per million, so the example lands at $27.
workerd and celld, Self-Hosted
workerd is the Apache 2.0 runtime under Workers, and celld is Deno's self-hosted Durable Objects server, a single Rust binary whose only dependency is an object storage bucket. Write for Workers once and you keep an exit. The catch: the planned merge of celld into workerd is announced work, not shipped code, and you operate everything yourself.
Netlify Edge Functions
Netlify built its edge runtime on Deno and charges edge traffic as plain web requests, 2 credits for every 10,000. The example's 3M requests use 600 of the Personal plan's 1,000 monthly credits ($9), leaving 400 for bandwidth at 20 credits per GB and production deploys at 15 credits each. Each request gets 50 ms of CPU, which is tight for heavy AI post-processing.
Fly.io
Fly runs containers on small VMs, so you can keep Deno, Fresh and even KV: run Deno's self-hosted denokv server with its SQLite file on a volume and point Deno.openKv() at it. SaaSKit reads its KV path from an environment variable, so utils/db.ts needs no edits.
A shared-cpu-1x machine with 512 MB is $3.69 a month and volumes are $0.15 per GB. It buys time rather than a future, though, since Deno's own development ends after the final year.
Val Town
Val Town executes TypeScript snippets it calls vals on Deno 2.9.6; for webhooks, bots and small agents, nothing else here feels as close to Deploy. Each val gets a private SQLite database, and Pro is $25 a month ($21 billed yearly) with 1M runs a day and 10-minute runs. The free plan stops runs at 1 minute of wall clock and SQLite at 10 MB.
Vercel Functions
Vercel's official runtimes cover Node.js, Bun, Python, Rust, Go, Ruby, Wasm and Edge, while Deno only works through the community-maintained vercel-deno runtime, which means most teams will be porting code rather than moving it. Fluid compute bills CPU only while your code runs, though memory keeps billing during a wait. Pro is $20 a month with $20 of usage credit, and Active CPU is charged from minute one at $0.128 an hour in the iad1 (Washington, D.C.) region; the 4 free hours are a Hobby perk.
Choosing Without Migrating Twice
- Count before you choose. An app with zero KV and cron hits can go anywhere.
- Ask whether you need Deno to keep running. Fly.io runs it as is; Supabase, Netlify and Val Town run code written for it; Workers and Vercel mean porting.
- Locate the KV code. When it lives in a single module, as in SaaSKit, moving it to Durable Objects or Postgres takes about a day.
- Compare your slowest request with each CPU ceiling: 10 ms (Workers Free), 50 ms (Netlify), 2 s (Supabase).
- Start early, since the migration help on offer only targets Workers.
If you are translating Deno.cron schedules, the Cron Expression Generator builds the expression for a Cron Trigger or pg_cron, and TypeScript to JavaScript shows what a handler compiles to before you port it to Node.js.
My Short List
- Safest bet for the next few years: Workers, with self-hosted workerd as a fallback.
- Already using Postgres or Supabase Auth: Supabase Edge Functions.
- Need it running this week: Fly.io plus denokv, with zero code edits.
- Bots, webhooks and small agents: Val Town.
- Heading to Next.js anyway: Vercel.
April 2027 is close, yet for most apps the real work sits in one storage module and maybe a scheduled job. Count the files that truly depend on Deno before committing to a host. The full DevToolLab write-up covers everything this version skips.
Top comments (0)