Netlify Edge Functions

• CategoryV8 isolate
• LanguageDeno / TS
• PricingFreemium
• LicenseProprietary
• Created2022
• GitHub starsclosed
• Cold startinstant
• PoPs,
• Node-compatNo

Netlify Edge Functions run JavaScript or TypeScript on Deno at the network edge, close to the visitor. They expose web-standard APIs (fetch, Request, Response) rather than the full Node surface, and are built for middleware-style work: redirects, geolocation, locale routing, A/B tests, auth, and streaming. The free tier includes 1,000,000 edge function invocations a month, well above the 125,000 serverless function invocations.

• Netlify Edge Functions in 2026: what they are and how they differ from Functions →

• Redirects, geolocation, locale routing, and A/B tests at the edge
• Teams already deploying their site on Netlify
• Streaming and personalisation close to the user

Skip Netlify Edge Functions for API and backend work that needs npm packages or Node built-ins, where regular Netlify Functions fit better. Skip Netlify entirely if your site is not hosted there; the value is in the integration.

Netlify Edge Functions are the Deno-flavoured counterpart to Vercel Edge and Cloudflare Workers. If you are already on Netlify, the generous free edge allowance and the build integration make them an easy default for middleware. Cloudflare still wins on raw scale and PoP count.

Netlify Edge Functions run on Deno, so Request, Response, fetch, Web Streams, and URLPattern are the runtime rather than a shim over it. What you do not get is the Node built-in surface, and that boundary decides where a piece of code lives. The programming model is a handler plus a context object carrying geolocation, cookies, and the request chain, and you can pass control further down that chain or rewrite a response body as it streams past. For middleware work that surface is enough, and the restriction is doing you a favour: it keeps functions small and keeps slow dependencies out of the path every visitor takes. Where it bites is requirement creep. An edge redirect quietly grows into an API endpoint that wants a database driver, and the runtime will not carry it. Notice that early and move the code rather than fighting the runtime.

Netlify ships two compute products and picking wrong is the usual mistake. Edge Functions run Deno at the edge for work that must happen before the response and close to the visitor. Netlify Functions run Node in a region for API and backend work that needs npm, longer execution, or a database client. The decision rule is one question: can this be written against web standards, and does it need to be near the user? The difference matters commercially, because the free edge invocation allowance is substantially larger than the serverless one, so pushing routing and personalisation to the edge keeps you off the more expensive meter. Check the current limits before you plan around that gap. On portability, the handler is web-standard enough that moving to Deno Deploy is close to trivial. What ties you in is the netlify.toml routing config, the context object, and the build integration, which is also most of the value.

• 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.