Vercel Edge Middleware Builder

Vercel Edge Middleware runs before a request is processed at the edge (CDN layer), enabling you to modify requests/responses without hitting your origin server. Common uses include authentication checks, geolocation redirects, A/B testing, bot protection, header manipulation, and rewriting paths. It's written in TypeScript, runs on the V8 edge runtime, and is defined in middleware.ts at the project root.

The matcher config restricts which routes trigger your middleware. Without a matcher, middleware runs on every request (including static files, _next/, and API routes). Use matcher to target specific paths: `['/api/:path*']` for all API routes, `['/((?!_next|favicon).*)']` to exclude Next.js internals, or `['/dashboard/:path*', '/profile']` for specific sections. Matchers support regex via (?regex) syntax.

No. Edge Middleware runs on the V8 edge runtime (not Node.js), which means no Node.js built-ins (no fs, no crypto module from Node.js, no net). You get Web APIs: fetch(), Request, Response, URL, Headers, crypto.subtle (Web Crypto), TextEncoder/Decoder, and Vercel-specific helpers like geolocation. Use next/server's NextRequest and NextResponse for Vercel-specific functionality.

Common pattern: read the session cookie or Authorization header, verify a JWT using Web Crypto (crypto.subtle.verify), and either continue with NextResponse.next() or redirect to login with NextResponse.redirect(). For complex auth, call a lightweight auth API endpoint from middleware. Avoid database calls in middleware — too slow and complex for the edge runtime.

middleware.ts runs at the edge before routing occurs — it's for fast, lightweight operations (auth checks, redirects, header manipulation) with no cold starts. API routes (/api/*) run in Node.js serverless functions after routing, supporting full Node.js capabilities, database connections, and heavier compute. Use middleware for gating/redirecting; use API routes for business logic.