Deno Deploy Production Sizing — which one?
Choose whether to keep edge workloads on Deno Deploy free, shard projects, or move to paid capacity now that GA plan limits are explicit and billable overages matter.
Blockers
- breaking_change_in: runtime/deno-deploy-ga-free → runtime/deno-deploy-free
- breaking_change_in: runtime/deno-deploy-free → runtime/deno-deploy-pro
Who this is for
- serverless
- cost-sensitive
- low-ops
- small-team
Candidates
Keep a single production org on Deno Deploy Free
As of 2026-04-09, the live Deno Deploy pricing page lists the Free plan at 1M requests per month, 20GB egress bandwidth, 15 CPU hours, 350 GB-h memory time, 20 active apps, and 50 custom domains per organization. Deno's GA announcement said the free plan offered 1M requests, 100GB egress, and 15 CPU hours, so the GA-era 100GB figure is not the current live quota. The current free plan remains viable for low-traffic APIs, thin edge routing, and cache-heavy workloads where bandwidth and CPU stay comfortably below the org-level caps. Metering is enabled, and free organizations that exceed requests, bandwidth, CPU, or memory time have their applications paused until the next billing cycle.
When to choose
Use this when the workload is truly small, burst-tolerant, and cost-sensitive, and when a monthly pause on quota exhaustion is acceptable. The decisive factor is whether your real production profile fits inside 1M requests, 20GB egress, 15 CPU hours, and 350 GB-h with margin.
Tradeoffs
Lowest direct cost and lowest operational overhead, but capacity is hard-capped and overage does not degrade gracefully on Free.
Cautions
Do not size from the GA blog alone. As of 2026-04-09, the pricing page shows 20GB free egress, not 100GB. Also note that CPU and memory-time quotas on the pricing page explicitly do not apply to Deno Deploy Classic.
Shard workloads across multiple Deno Deploy organizations
As of 2026-04-09, Deno Deploy lists requests, egress bandwidth, CPU time, memory time, apps, and custom domains as organization-level limits on the pricing page. Splitting unrelated services into separate organizations therefore changes which quota bucket each service consumes. This can delay a paid upgrade if each service independently fits within a free org's limits, but it does not remove the hard-stop behavior of the Free plan. The changelog also states that all organizations default to Free and that organizations only get restricted Free plan limits until they verify by linking a credit card.
When to choose
Use this only as a temporary containment tactic for truly separate apps or customers that can live with separate organizations, separate quotas, and separate admin surfaces. The decisive factor is organizational isolation, not scale, because each free org still pauses apps when it exceeds requests, bandwidth, CPU, or memory time.
Tradeoffs
Can postpone direct hosting spend, but adds operational fragmentation across domains, deployments, billing verification, and team access.
Cautions
This is not a clean scaling path for a single growing production service. Quotas are still hard caps per organization, wildcard subdomains are not included on Free, and free-plan exhaustion pauses applications until the next billing cycle.
Move production workloads to Deno Deploy Pro now
As of 2026-04-09, Deno Deploy Pro costs $20 per month and includes 5M requests, 200GB egress, 40 CPU hours, 1,000 GB-h memory time, 100 active apps, 100 custom domains per organization, wildcard subdomains, and 10 team members. The pricing page lists overages at $2 per million requests, $0.50 per GB egress, $0.05 per CPU hour, and $0.016 per GB-h memory time. The changelog says Pro organizations are billed for overage at the end of the month instead of being paused. This is the cleanest path once workloads are customer-facing and unpredictable enough that hard free-tier pauses become unacceptable.
When to choose
Use this when the service is production-critical, traffic or bandwidth is variable, or the cost of an outage is higher than a small fixed monthly fee. The decisive factor is whether you need predictable continuity under overage rather than a hard stop at quota boundaries.
Tradeoffs
More predictable production behavior and higher included limits, but it introduces recurring spend and variable overage exposure.
Cautions
Watch both egress and memory-time, not just requests. If your workload is mostly idle I/O, CPU may stay low while bandwidth or memory-time still drives the decision.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Deno Deploy Production Sizing — which one?"