Run code at the edge—middleware, edge API routes, and when edge makes sense for your app.
Edge runs your code close to users. Here’s how Next.js and Vercel use it and when to adopt it.
Edge and serverless
What is edge
Location — Code runs in many regions; the request is handled by a node near the user. Lower latency than a single origin.
Runtime — Lightweight (e.g. V8 isolates). No full Node.js; limited APIs and execution time. Good for redirects, auth checks, and small responses.
Next.js — Middleware runs at the edge. Edge Runtime for API routes and Server Components when configured. Vercel deploys these to their edge network.
Use cases
Middleware — Redirects, rewrites, A/B tests, auth checks. Run before the request hits the page. Keep it fast and small.
Edge API routes — Simple APIs that need low latency (e.g. geo, feature flags). No heavy DB or long compute.
Static + edge — Serve static assets from the edge (CDN); run middleware or a few edge routes for dynamic bits. Hybrid is common.
Edge adoption (Next.js apps):
Next.js apps using edge (%)
Limits
No Node APIs (fs, long-running). Cold starts are small but exist. Prefer edge for request/response and lightweight logic; keep heavy work in serverless or origin.
Edge in Next.js:
Takeaway
Use edge for middleware and low-latency, simple APIs. Don’t force everything to the edge; use it where proximity and speed matter. Next.js and Vercel make it easy to try.
