Deno Deploy

Overview

Deno Deploy is Deno Land’s serverless platform for running JavaScript and TypeScript applications—on their managed cloud or, for larger customers, with a self-host path via deployd. Primary job: push code (GitHub, CLI, or playground), get builds, TLS, scaling, logs/traces, and optional managed data (Deno KV, linked Postgres/Prisma) without operating your own edge fleet.

Product: deno.com/deploy. Console (current GA platform): console.deno.com. Pricing: deno.com/deploy/pricing. Docs: docs.deno.com/deploy. Status: denostatus.com.

In February 2026 Deno announced that the rewritten platform is generally available. It is not a thin rebrand of the old product: the GA system uses Deno 2 under the hood, full Node/npm paths, integrated builds, OpenTelemetry-style telemetry, PR “timelines,” and first-class framework detection (Next.js, Astro, Fresh, SvelteKit, and other JS/TS stacks). The older product—Deploy Classic at dash.deno.com—is on a hard sunset: official docs set shutdown for July 20, 2026, with no automatic project transfer. Anyone still on Classic must recreate apps, env vars, domains, and (for Subhosting) migrate from the v1 API to the v2 API.

Beyond plain hosting, Deno markets two adjacent products on the same pricing surface: Deno Sandbox (programmable Linux microVMs for safe untrusted/AI-generated code) and Deno Subhosting (multi-tenant “run customer code” for platforms—Netlify Edge Functions is a public case study; Slack’s Deno-based platform work is another ecosystem story).

Key features

• Any major JS/TS framework path — GA messaging emphasizes auto-detect builds and framework-aware commands so Next.js, Astro, SvelteKit, Fresh, and similar stacks deploy without proprietary adapter lock-in. Static sites are first-class on the new platform (they were not on Classic).
• Git-linked CI and PR timelines — Connect GitHub for continuous delivery: live previews per commit, PR timelines, promote/rollback in the UI. Optional pre-deploy commands (e.g. DB migrations per timeline). CLI path: deno deploy for terminal and CI; Classic-era deployctl and GitHub Action still appear in the ecosystem for older workflows.
• Deno runtime + Node/npm compatibility — Runs on Deno with permission model heritage, while the new execution environment claims full Deno apps (including capabilities Classic blocked: FFI, subprocesses, write) and full Node apps (native addons, better npm). “Like a free upgrade” positioning vs Classic’s limited Node path.
• V8 isolates and elastic scale — Code runs in lightweight isolates aimed at faster cold starts than classic VMs/Lambda-style containers. Free tier for small apps; paid tiers for higher request/CPU/memory/egress budgets.
• Built-in and linked data — Deno KV (key-value, multi-region options by plan). Provision/link databases from the dashboard; Prisma partnership for free Postgres-style provisioning. Per-PR isolated database clones on timelines so previews do not share production data. Env vars are context-aware (production vs development vs build).
• Cron in code — Deno.cron() jobs discovered at deploy time; dashboard Cron tab for history/status (changelog-documented). Note: Classic Queues are a known gap—new Deploy comparison table marks Queues as not supported while Cron is supported.
• Observability — Auto-captured logs, traces, and metrics without hand-instrumentation: console.log, fetch, HTTP, V8/GC/IO signals; logs correlated to requests. Log retention and analytics windows scale by plan (Free: short retention; Pro/Builder longer). OpenTelemetry export listed as work in progress on docs comparison tables.
• Local–prod parity with --tunnel — Dev commands can pull centrally managed env vars, expose a public shareable URL, and stream telemetry into the Deploy dashboard—reducing “works on my machine” drift.
• CDN / Cache APIs — HTTP edge cache and Web Cache API included on Free/Pro (pricing table marks them currently unavailable on Builder). Useful for static assets and response caching patterns.
• Deno Sandbox — MicroVMs that boot in under a second for programmatic safe compute (AI agent loops, untrusted user code). Separate from isolate deploys but billed under the Deploy pricing surface.
• Subhosting — API-driven multi-tenant hosting so other products can embed Deno’s isolate cloud (Netlify’s edge functions product is the flagship story). Builder plan is oriented at high app counts (up to 100,000 apps) and deploy rate.
• Security primitives — Sandboxed isolate separation; outbound connection allowlists on Free/Pro; Enterprise authenticated invocations and dedicated Anycast IPs. Deno has publicly announced SOC 2 for the company; pricing lists SOC 2 Type 1 and DPA on Enterprise.
• Ops integrations — Terraform management of Deploy resources; enterprise path mentions deploy-in-your-cloud and customizable runtimes as “coming soon” (not GA features to count on today).

Pricing

Deno Deploy is freemium + fixed subscription tiers + metered overages. Figures below follow the official pricing page (covers Deploy, Sandbox, and Subhosting usage). Always re-check live meters—GA blog copy and older third-party calculators sometimes still quote Classic-era free-tier egress (e.g. 100 GB) that does not match the current Free column (20 GB).

Plan	Price	Core included (headline)	Best for
Free	$0 / month	1M requests; 20 GB egress; 15 h CPU time; 350 GB-h memory; 20 apps; 60 deploys/hour; 50 custom domains/org; 1 GiB volume; 1 GiB KV; 450k KV read units; 300k KV write units; 5 team members; 1-day log retention; community (Discord) support	Personal / small projects, learning, prototypes
Pro	$20 / month	5M requests then ~$2/M; 200 GB egress then ~$0.50/GB; 40 h CPU then ~$0.05/h; 1,000 GB-h memory then ~$0.016/GB-h; 100 apps; wildcard subdomains; 100 domains/org; 5 GiB volume then ~$0.20/GiB-month; 5 GB KV then ~$0.75/GiB; higher KV units; 10 members then ~$20/member; 1-week logs; email support	Teams, commercial apps, higher traffic
Builder	$200 / month	20M requests then ~$2/M; 300 GB egress then ~$0.50/GB; up to 100,000 apps; 200 deploys/hour; 300 domains/org; 10 GiB KV base; Subhosting-oriented; 2-week logs; Web Cache / HTTP Edge Cache currently unavailable on this tier per pricing table	Platforms embedding Subhosting, multi-tenant fleets
Enterprise	Custom	Custom quotas; authenticated invocations; dedicated Anycast IP; 99.95% reliability SLA; SOC 2 Type 1; DPA; email SLA; onboarding support; unlimited custom domains; write-region selection	Procurement, compliance, large multi-tenant or regulated workloads

Overage mental model (Pro-style meters): Requests (~$2 per million after included), egress (~$0.50/GB), CPU time (~$0.05/hour), memory-time (~$0.016 per GB-hour), volume storage (~$0.20 per GiB-month), KV storage (~$0.75/GiB), KV reads (~$1 per million units), KV writes (~$2.50 per million units). Extra team seats ~$20 each after included count. Builder omits the Free/Pro-style CPU and memory-time rows in the public table (Subhosting-centric packaging)—confirm with sales or the dashboard for your workload shape.

Refunds: Fulfillment policy docs state refunds must be requested within 14 days of initial purchase or plan upgrade (contact deploy support).

Limits & gotchas

• Deploy Classic hard sunset (July 20, 2026) — Official migration guide: Classic dashboard and Subhosting v1 API shut down that day. Projects do not auto-transfer. Recreate org/app, reconnect GitHub, re-enter env vars (now split by context), re-point custom domains (DNS/CNAME can take time), and migrate KV/queues/API clients carefully. Community write-ups and deploy_feedback issues report painful migrations (silent API breaks, queues absent on new platform, KV help sometimes needing support).
• Fewer public regions on the new platform — Docs comparison: Deploy Classic listed 6 regions; new Deno Deploy lists 2 (with self-hostable regions as a differentiator). Reddit EA threads flagged the 6→2 change as a latency/geo concern. Self-host / Enterprise paths matter if you need broader footprint today.
• Queues gap — Classic supported Queues; the GA comparison table marks Queues not supported on new Deploy while Cron is supported. Architectures that depended on Deno Queues need a redesign (external queue, database-backed jobs, etc.).
• JS/TS-centric platform — Optimized for JavaScript/TypeScript (and Node interop), not a polyglot FaaS like Lambda. Heavy non-JS workers belong elsewhere.
• Builder cache caveats — Pricing table shows Web Cache API and HTTP Edge Cache “currently unavailable” on Builder while included on Free/Pro—counterintuitive for multi-tenant edge platforms; verify before choosing Builder solely for cache features.
• Usage-limit confusion — Independent blogs describe free-tier limit emails that are hard to map to actual CPU dashboards (e.g. milliseconds of CPU vs multi-hour monthly quotas). Read org analytics carefully and open support if meters look wrong.
• Compliance is Enterprise-gated — Public pricing: SOC 2 Type 1 and DPA on Enterprise, not Free/Pro. Company blog has announced SOC 2 compliance historically; procurement still needs the right contract tier for Type 1 attestation and DPAs.
• Not “cheapest edge at hyperscale” by default — Comparisons with Cloudflare Workers often favor Workers for global PoP density and unit cost at extreme volume; Deno wins on Deno-native DX, Subhosting, and TS/security story. Vercel still wins pure Next.js product surface for many teams even if Deploy can run Next.
• Maturity and operational history — Status page incidents (e.g. regional outages in 2026) exist; smaller vendor than AWS/Cloudflare means you should design for multi-region/self-host options if uptime is existential.

Community sentiment

On r/Deno, Hacker News, and Deno’s own Discord-linked support path, Deploy is praised as one of the cleanest ways to ship Deno (and increasingly Node) apps without YAML-heavy platforms—and criticized whenever the platform story changes under users’ feet.

Praise: Instant deploys and playgrounds; TypeScript-first DX; Deno KV for simple stateful edge apps; free tier that is usable for real hobby traffic; Subhosting as a credible B2B wedge (Netlify edge case study is frequently cited); GA features (framework auto-build, PR databases, tunnel, OTel-style traces) that close the gap with “frontend clouds”; Sandbox excitement for agent/untrusted code.

Criticism: Classic → new Deploy migration pain and deadline stress; reduction in managed regions during the rewrite; loss of Queues on the new platform; naming confusion (“new Deploy” vs Classic); occasional opaque limit emails; smaller ecosystem and ops polish versus Cloudflare or Vercel; enterprise/compliance features not visible enough on Free/Pro for mid-market buyers.

Independent comparison pieces (Bejamas, srvrlss, Medium hands-on writeups, daily.dev edge roundups) usually place Deno Deploy beside Cloudflare Workers and Vercel Edge: Workers for density and cost at scale, Vercel for Next-centric product velocity, Deploy for Deno-native security/runtime alignment and multi-tenant Subhosting.

Who should use it

• Deno-first and TypeScript-first teams that want production parity with local Deno (permissions, web standards APIs, KV) and minimal platform adapters.
• Indie builders and small products that fit Free or Pro quotas (≤1–5M requests, moderate egress) and want Git previews without a full Kubernetes story.
• Platform builders who need to run customer or plugin code securely—Subhosting and Sandbox are the differentiators versus plain static/hosting PaaS.
• Teams migrating off Classic who can complete cutover before July 20, 2026 and can live without Classic Queues (or will re-home that work).
• Enterprises that need SLA, SOC 2 Type 1 packaging, DPA, dedicated IPs, and authenticated invocations—and can budget custom contracts.

Who should pause: Workloads that need Classic-style multi-region density on managed Deploy alone; polyglot non-JS workers; teams that cannot afford a manual re-platform before the Classic deadline; pure “cheapest GB egress worldwide” shoppers who will likely prefer Cloudflare; orgs that need Queues as a first-party Deploy primitive today.

Alternatives

• Vercel — Strongest Next.js DX, PR previews, and frontend-cloud surface; higher seat/usage complexity; less Deno-native.
• Netlify — Jamstack/hosting + Edge Functions (Deno Subhosting under the hood for their edge runtime story); broader site/plugin ecosystem.
• Railway — Container/service PaaS with classic long-lived processes and databases; better when you need always-on servers, not only isolates.
• Render — Predictable web services + managed Postgres; more “traditional deploy units” than edge isolates.
• Cloudflare Workers / Pages — Usually denser edge network and aggressive pricing at volume; different runtime constraints than full Deno Node compatibility.
• Fly.io / self-host Deno (Docker on a VPS) — More control and multi-region machines; more ops. Official Deno docs also show Workers deployment paths for hybrid setups.
• AWS Lambda / containers — Polyglot and procurement-friendly at huge scale; cold starts and multi-tenant isolation are DIY compared to Subhosting.

Verdict

Deno Deploy in 2026 is a real GA platform again—rewritten around Deno 2, framework-aware builds, better Node support, PR-scoped data, tunnels, and observability—not just “edge snippets for Deno scripts.” Pricing is straightforward at Free $0 / Pro $20 / Builder $200 with clear overage meters, and Subhosting/Sandbox give Deno a lane that pure static hosts lack.

The honest caveats are operational: Classic dies July 20, 2026 without automatic migration; the new managed footprint lists fewer regions; Queues did not carry over; compliance and dedicated networking sit on Enterprise. For Deno-native products, multi-tenant code execution, and teams who want TypeScript edge hosting without inventing isolate infra, Deploy is a first-choice. For maximum global PoP density or Next-only product surface, benchmark Workers and Vercel on the same app before you commit.

Bottom line: ship greenfield on console.deno.com, migrate Classic early, set spend caps, and pick Subhosting/Builder only when multi-tenant app counts justify the package—not because the marketing page says “edge.”