Deno Deploy 2 — A Field Guide

Deno Deploy is Deno's globally distributed hosting platform: push a script or a full Deno 2 project and it runs at the edge, close to the request, without you managing a server or a container fleet. The second-generation platform (often called Deploy EA / early access build on Deno's new architecture) narrowed the gap between "works on my machine" and "works at the edge" by running the same V8 isolate model that Cloudflare Workers popularized, but with Deno's npm compatibility and permissions model underneath it.

How Deploy actually runs code

Each request is handled by a V8 isolate rather than a container or a VM. Isolates start in single-digit milliseconds because there's no OS boot, no filesystem to mount — just a fresh JavaScript context loaded with your bundled code. Deno Deploy replicates your project to edge regions worldwide and routes each incoming request to the nearest one, so latency for a user in Nairobi and a user in Amsterdam both stay low without you configuring any region logic yourself.

What doesn't run at the edge

Isolates are not full servers. There is no arbitrary subprocess spawning, no native Node addons that need compilation, and no long-lived filesystem you can write to and expect to persist between requests. This rules out some npm packages outright — anything depending on native bindings (think image-processing libraries that shell out to ImageMagick, or database drivers built on native TCP sockets in ways the isolate can't support) needs a different home, typically a traditional server or serverless function running in a full runtime.

State: Deno KV

Because isolates are ephemeral and distributed, Deploy pairs with Deno KV, a key-value store built on FoundationDB that Deno exposes through a simple `Deno.openKv()` API. It supports atomic transactions and is globally replicated, which makes it a reasonable fit for session data, feature flags, or counters accessed from edge functions — the kind of small, latency-sensitive state that would otherwise force you to make a round trip back to a origin database on every request.

const kv = await Deno.openKv();

Deno.serve(async (req) => {
  const url = new URL(req.url);
  if (url.pathname === "/api/visits") {
    const key = ["visits", url.searchParams.get("page") ?? "home"];
    const current = (await kv.get(key)).value ?? 0;
    await kv.set(key, current + 1);
    return Response.json({ visits: current + 1 });
  }
  return new Response("not found", { status: 404 });
});

Deploying and environment separation

A typical setup connects a GitHub repository to a Deploy project; every push to main promotes to production, and every pull request gets its own preview URL running the branch's code against the same edge network — useful for reviewing an actual behavior change rather than just a diff. Environment variables and secrets are scoped per project through the Deploy dashboard or the `deployctl` CLI, kept separate from anything committed to the repo.

When Deploy is the right fit

Deploy is a strong match for latency-sensitive HTTP handlers, API routes, auth middleware, A/B testing logic, and personalization that needs to happen before a request reaches your main application — the same category of work Cloudflare Workers and Vercel Edge Functions target. It's a poor fit for CPU-heavy batch jobs, anything needing a large in-memory dataset, or workloads with native dependencies. Most production setups end up hybrid: Deploy in front for routing and light logic, a conventional server or serverless backend behind it for the heavy lifting.

Wrapping up

Deno Deploy's pitch is the same as every edge platform's: push code, skip the infrastructure. What sets it apart is that it's the same Deno runtime you develop against locally, with the same permissions model and npm compatibility, so the gap between local testing and production behavior is smaller than with most edge platforms.