7 Best Deno Deploy Alternatives in 2026

Picking a home for TypeScript functions used to be a question of latency and price. The harder question turns out to be whether the runtime under your code still has a team behind it in two years.

On October 9, 2026, Ryan Dahl announced that the entire Deno team is joining Cloudflare, and that Deno Deploy shuts down in six months. The Deno runtime gets one more year of monthly bug-fix and security releases, after which Deno Land ends its development. Paying customers get migration help moving to Cloudflare Workers.

If you run anything on Deploy, from a Fresh site to an AI agent endpoint, you have until roughly April 2027 to move it. How hard the move is depends almost entirely on which Deno-only APIs your code touches.

What Shuts Down, and What Keeps Running

Deno's announcement lists four commitments. Deno Deploy keeps operating for six months, then shuts down. The runtime, MIT licensed today, gets monthly bug-fix and security releases for one year and remains open source. JSR, the package registry, keeps running, with its infrastructure moving to Cloudflare. And rusty_v8 keeps getting support while the team works toward integrating it into workerd.

Deno's pricing page bills Deno Sandbox and Deno Subhosting under the same Deploy plans (Free, Pro at $20 a month, Builder at $200), and the announcement gives them no separate timeline.

Cloudflare's side of the announcement, co-written by Kenton Varda and Ryan Dahl, explains the bet: celld, Deno's self-hostable implementation of Workers and Durable Objects released in August 2026, gets merged into workerd, the open-source runtime Cloudflare runs in production. In Deno's post, Dahl singles out AI: Durable Objects give agent harnesses cheap serverless execution, persistent state and WebSockets in one primitive.

How We Measured the Move

Most migration pain on Deploy comes from five things: Deno KV, Deno.cron, KV queues, Deno.* filesystem calls and jsr: imports. This script counts them in any project:

js
Copy
// deno-api-audit.mjs: count the Deno-only APIs a move off Deno Deploy has to replace.
// usage: node deno-api-audit.mjs <project-dir>
import { readdirSync, readFileSync, statSync } from "node:fs"
import { join, extname } from "node:path"

const CHECKS = [
  ["Deno.openKv()", /Deno\.openKv\(/g],
  ["KV atomic / watch / listenQueue", /\.atomic\(\)|\.watch\(\s*\[|\.listenQueue\(/g],
  ["Deno.cron", /Deno\.cron\(/g],
  ["BroadcastChannel", /new BroadcastChannel\(/g],
  ["Deno.serve", /Deno\.serve\(/g],
  ["Deno.env", /Deno\.env\.(get|toObject|has)\(/g],
  ["Deno filesystem calls", /Deno\.(readTextFile|readFile|writeTextFile|writeFile|open|stat|readDir)\(/g],
  ["jsr: imports", /["']jsr:@[^"']+["']/g],
  ["npm: imports", /["']npm:[^"']+["']/g],
  ["https:// URL imports", /from\s+["']https:\/\/[^"']+["']/g],
]
const files = []
const walk = (dir) => {
  for (const name of readdirSync(dir)) {
    if (name === ".git" || name === "node_modules" || name === "_fresh") continue
    const p = join(dir, name)
    if (statSync(p).isDirectory()) walk(p)
    else if ([".ts", ".tsx", ".js", ".jsx", ".json", ".jsonc"].includes(extname(p))) files.push(p)
  }
}
walk(process.argv[2])
const totals = CHECKS.map(([label]) => ({ label, hits: 0, files: new Set() }))
for (const f of files) {
  const src = readFileSync(f, "utf8")
  CHECKS.forEach(([, re], i) => {
    const n = (src.match(re) || []).length
    if (n) { totals[i].hits += n; totals[i].files.add(f) }
  })
}
console.log(`${files.length} source files scanned`)
for (const t of totals) console.log(`${t.label.padEnd(36)} ${String(t.hits).padStart(4)} hits in ${String(t.files.size).padStart(3)} files`)

We ran it on SaaSKit, Deno's own Fresh SaaS template built for Deploy (archived, last commit February 9, 2026), on October 17, 2026:

text
Copy
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 useful finding is where the KV code lives. Every runtime call to Deno KV sits in one 483-line module, utils/db.ts, which makes 15 KV calls (5 get, 4 list, 1 getMany, 5 atomic) and is imported by 22 files. On a platform without Deno KV, porting SaaSKit means rewriting that one module. The filesystem hits are a blog loader reading Markdown from ./posts and a license-header task that never runs in production.

That is the worked example for every section below: an app shaped like SaaSKit, with an AI chat endpoint, Deno KV for users and sessions, and about 3 million requests a month on Deploy Pro.

Cloudflare Workers: The Official Migration Path

Cloudflare Workers is where the Deno team now works and the only target named in Deno's migration support for paying Deploy customers.

Workers runs on workerd, the same open-source runtime Cloudflare uses in production. Deno KV maps to Workers KV, D1 or Durable Objects, which give each object its own SQLite database, WebSockets and single-threaded execution, the shape Dahl describes for AI agent harnesses. Deno.cron becomes a Cron Trigger with up to 15 minutes of CPU per run on Paid (30 seconds if it runs more often than hourly), and Node.js compatibility is on by default for compatibility dates from August 4, 2026.

There is no Deno namespace, so SaaSKit's utils/db.ts and every Deno.env call get rewritten, and the Free plan allows only 10 ms of CPU per invocation.

Pricing: Free 100,000 requests/day · Paid $5/month minimum including 10M requests ($0.30 per extra million) and 30M CPU milliseconds ($0.02 per extra million). At 5 ms of CPU per request, with Workers KV under its included 10 million reads and 1 million writes a month, the worked example stays at $5.

Supabase Edge Functions: Deno-Compatible With a Database Attached

Supabase Edge Functions run on Supabase Edge Runtime, which Supabase describes as Deno compatible and portable to "any other Deno-compatible platform (including self-hosted infrastructure)."

Most Deploy handler code moves with little change, and Postgres sits next to your functions to replace Deno KV. Scheduled jobs use the pg_cron and pg_net extensions. The runtime is MIT licensed, with 993 stars and v1.77.4 released October 1, 2026.

There is no Deno KV, so utils/db.ts becomes SQL. Hosted functions cap at 256 MB of memory and 2 seconds of CPU per request, and its Deno base depends on a runtime whose upstream development ends around October 2027.

Pricing: Free 500,000 invocations · Pro $25/month including 2M invocations ($2 per extra million). The worked example costs $27.

workerd + celld: Workers Without Cloudflare

workerd is the open-source Workers runtime, Apache 2.0 with about 9,000 GitHub stars and a v1.20261017.1 release on October 17, 2026, and celld is Deno's self-hosted, distributed Durable Objects server, Apache 2.0 with about 5,800 stars.

Code written for Workers runs on your own machines, so you migrate once and keep an exit. celld is one Rust binary whose only external dependency is an object storage bucket, and Ryan Dahl and Bert Belder will lead merging it into workerd.

Today workerd's own Durable Objects run on a single instance, and the merge is announced work, not a release. You operate everything yourself, and it needs the same rewrite of Deno APIs as Workers.

Pricing: Free and open source. You pay for the servers and the bucket.

Netlify Edge Functions: A Deno-Based Runtime You Do Not Operate

Netlify Edge Functions run "in a secure runtime based on Deno," so handler code written for Deploy usually needs only small changes.

State goes through Netlify Blobs, and edge function requests are billed only as web requests, at 2 credits per 10,000, not as compute. Netlify's edge functions originally ran on Deno Subhosting, but its current docs describe only the runtime, and neither company had said anything about Netlify customers as of October 17, 2026.

Each request gets 50 ms of CPU, too little for heavy AI post-processing, and Deno KV is not part of the platform.

Pricing: Free (300 credits) · Personal $9/month (1,000 credits) · Pro $20/month (3,000 credits and up). The worked example's 3M requests use 600 credits, leaving Personal's other 400 for bandwidth (20 credits per GB) and production deploys (15 credits each).

Fly.io: Keep Running Deno Itself

Fly.io runs containers on small VMs called Machines, so you can keep Deno, your Fresh app and even Deno KV exactly as they are.

Run the official Deno image, and point Deno.openKv("http://...") at denokv, Deno's self-hosted KV server (MIT, 651 stars), with its SQLite file on a Fly volume and a DENO_KV_ACCESS_TOKEN. SaaSKit's utils/db.ts does not change at all.

This buys time, not a future: Deno's development ends after the final year, and you now run a server and a single-region KV store.

Pricing: shared-cpu-1x with 512 MB $3.69/month, volumes $0.15/GB/month, billed by the second.

Val Town: Deno-Powered Functions for Small Agents

Val Town runs TypeScript "vals" on Deno 2.9.6, which makes it the closest hosted feel to Deploy for webhooks, bots and small AI agents.

Every val gets a private SQLite database, powered by Turso, and cron triggers run every minute on Pro. The free plan allows 100,000 runs a day.

SQLite storage caps at 10 MB on Free and 1 GB on paid plans, runs stop at 1 minute of wall clock on Free, and the runtime carries the same Deno lineage question as Supabase and Netlify.

Pricing: Free · Pro $25/month, or $21 billed yearly (1M runs/day, 10-minute runs) · Business from $200/month ($167 yearly).

Vercel Functions: A Clean Break to Node.js or Bun

Vercel Functions officially support Node.js, Bun, Python, Rust, Go, Ruby, Wasm and Edge, plus a Container runtime in beta. Deno runs only through the community vercel-deno runtime, so for most apps this is a port rather than a move.

Fluid compute bills CPU only while code runs, "not idle resources," though memory still bills during the wait, which suits an AI endpoint that spends most of each request waiting on a model. If the app is moving to Next.js anyway, it lands on the platform Next.js is built for.

Every jsr: import, Deno.env call and Deno KV call changes, and data lives in a separate store.

Pricing: Hobby $0 (4 hours of Fluid Active CPU included) · Pro $20/month including $20 of usage credit, with Active CPU billed from the first hour at $0.128 per hour in Washington, D.C. (iad1).

How to Choose Without Migrating Twice

1. Run the audit script first. Zero KV and cron hits means any host works, and you can pick on price and latency.
2. Decide whether Deno itself must survive. Fly.io keeps it unchanged; Supabase, Netlify and Val Town keep Deno-style code on their own runtimes; Workers and Vercel need a port.
3. Find your KV module. If it is one file like SaaSKit's utils/db.ts, rewriting it for Durable Objects or Postgres is a day, not a quarter.
4. Check the CPU ceiling against your heaviest request, especially AI post-processing: 10 ms on Workers Free, 50 ms on Netlify, 2 seconds on Supabase.
5. Migrate before the last month. Deploy's shutdown arrives around April 2027, and the announced migration support covers Workers only.

Which One Should You Actually Use?

You want the least long-term risk: Cloudflare Workers, with workerd as the exit if you ever leave.

Your app already uses Postgres or Supabase Auth: Supabase Edge Functions, where your KV data becomes tables.

You need to ship this week and fix it later: Fly.io with denokv, which needs no code changes.

Small agents, bots and webhooks: Val Town.

The app is becoming a Next.js app anyway: Vercel.

Conclusion

Deno did not lose on technology. Its team picked one runtime to build on, and it is Cloudflare's. The deadline is real, but the work is usually smaller than it looks, because it is concentrated in a KV module and a cron job. Before choosing anything, run the audit and ask: which three files actually depend on Deno?

Related DevToolLab Tools

• Cron Expression Generator - rebuild a Deno.cron schedule as a Cron Trigger or pg_cron expression.
• TypeScript to JavaScript - check what a handler compiles to before porting it to Node.js.
• HTTP Cache Header Analyzer - confirm edge caching still behaves after the move.
• WASM to WAT Converter - inspect a .wasm module before deploying it to Workers or Supabase.

Related Guides

• Bun vs Node.js vs Deno - how the three runtimes compare for new projects.
• Best Serverless Postgres - where Deno KV data can go if it becomes tables.
• Best AI Code Execution Sandboxes - replacements for Deno Sandbox.
• Best Heroku Alternatives - container hosts if you would rather run a server.