Vercel Edge

• CategoryV8 isolate
• LanguageV8 / TS
• PricingFreemium
• LicenseProprietary
• Created2021
• GitHub starsclosed
• Cold startinstant
• PoPs~50
• Node-compatYes

Vercel Edge is the V8-isolate Edge runtime on the Vercel platform, used for Edge Middleware, edge API routes, and streaming responses for AI apps. In June 2025 Vercel deprecated the standalone Edge Functions product and moved the Edge runtime onto Vercel Functions, unifying pricing across all compute. You now pick the Edge or Node runtime per function. Smaller global PoP network than Cloudflare; the value is in the Next.js integration.

• Vercel Edge in 2026: what it is and what changed →

• Next.js apps using Edge Middleware + streaming responses
• Teams already on Vercel who want one vendor and one bill
• AI products that need streaming token responses with low TTFB

Skip the Edge runtime for cost-sensitive workloads at scale, where Cloudflare Workers is cheaper, or for heavy dependencies that need the Node runtime. Skip Vercel entirely if you are not on the platform; the value is in the integration.

Vercel Edge is the right pick for Next.js teams who prioritise DX and integration over raw cost. Since the 2025 fluid-compute move, the edge-vs-serverless split is gone: you choose a runtime per function. Cloudflare Workers still wins on price and PoP count; Vercel wins on Next.js ergonomics.

In June 2025 Vercel retired Edge Functions as a separate product and folded the Edge runtime into Vercel Functions. The practical effect is that you no longer pick between two billing products with two mental models. You choose a runtime per function, Edge or Node, and both bill through the same compute model. Edge stopped being a deployment tier and became a runtime characteristic. Middleware still defaults to Edge, because it sits in front of every matched request and has to stay small and fast. If you inherited a codebase written before the change, migration is mostly deleting stale assumptions rather than rewriting handlers. What has not improved is documentation drift. Plenty of tutorials, and some older guidance, still describe the two-product split, so check anything you read against the current docs before you copy it into a project.

The Edge runtime gives you instant start, web-standard APIs, small bundle limits, and no native modules. The Node runtime gives you full npm and heavier dependencies at the cost of a real start time. A workable rule: Edge for middleware, auth gates, geolocation and locale routing, redirects, and token streaming where time to first byte is what users feel. Node for anything touching a Postgres driver, image processing, or a fat vendor SDK. Because the point-of-presence network is a fraction of the size of Cloudflare's, the geographic advantage of picking Edge is thinner than the name suggests; often you are choosing it for start time, not distance. On lock-in, handler code ports to Workers or Deno Deploy with modest effort. The platform glue does not: middleware conventions, incremental regeneration, and image optimisation are Vercel-shaped, and they are the actual reason teams stay.

• Official homepage →

The 30-min call is where your edge runtime choice becomes a real architecture, an integration plan with your data layer + auth + build pipeline, and a price range you can take to your stakeholders.