Platform routing middleware versus framework middleware
Routing middleware intercepts incoming web requests before they reach your application — handling auth checks, redirects, geolocation routing, A/B tests, and bot filtering at the fastest possible layer. In 2026, this exists at two levels: Vercel Routing Middleware (platform-wide, works with any framework) and Next.js proxy (framework-specific, renamed from middleware.ts in Next.js 16). Business owners should care because middleware decisions affect security, page speed, and how cleanly your team can add features like login walls or regional pricing without rewriting every page.
This topic connects to Next.js 16 and Partial Prerendering: What Business Owners Should Know, our Web Development capability, and teams in Education & Enterprise Training.
Why middleware exists
Every request to your site passes through a chain before a user sees content. Middleware sits at the front of that chain — before your page renders, before your API runs, and critically, before the CDN cache serves a response.
Without middleware, every page handles its own auth check, redirect logic, and locale detection. That means duplicated code, inconsistent behavior, and slower responses because checks happen deep in the application instead of at the edge.
With middleware, you define rules once: "If the user is not logged in and the path starts with /dashboard, redirect to /login." Every dashboard route inherits that protection automatically.
The business value is consistency and speed. Security rules apply uniformly. Redirects happen in milliseconds. Personalization can start before your server even wakes up.
Platform middleware vs. framework middleware
This distinction confuses teams because both are called "middleware." They operate at different layers:
Vercel Routing Middleware runs at the platform level — before the CDN cache. It works with any framework (Next.js, Astro, SvelteKit, static sites). You configure it via middleware.ts at the project root or through vercel.json rules. It supports Edge, Node.js, and Bun runtimes. Use it for global rules that apply regardless of how your app is built.
Next.js proxy (formerly middleware.ts, renamed in Next.js 16) runs at the framework level within your Next.js application. It uses the Node.js runtime by default and integrates directly with Next.js routing, cookies, and headers. Use it for app-specific logic tied to your Next.js route structure.
In practice, many Next.js projects on Vercel use the framework proxy for auth and routing, while platform middleware handles cross-project rules like custom domain redirects or WAF-adjacent bot filtering.
What belongs in middleware vs. your app
Getting this boundary wrong creates either slow pages (too much in middleware) or security gaps (too little).
Belongs in middleware:
- Authentication redirects (logged out → login page)
- Geolocation-based routing (EU visitors → GDPR consent flow)
- A/B test assignment (cookie-based variant selection)
- Bot and crawler filtering
- Custom domain and www/non-www redirects
- Security headers (CSP, HSTS)
Belongs in your application:
- Business logic (pricing calculations, approval workflows)
- Database queries and data fetching
- AI model calls and content generation
- Complex permission checks that need database lookups
- Form processing and validation
The rule of thumb: if it needs a database query or takes more than a few milliseconds, it probably belongs in a server component or API route — not middleware.
Next.js 16 changes business owners should know
The biggest naming change: Next.js renamed middleware.ts to proxy.ts with Node.js as the default runtime. If your team references "middleware" in Next.js docs from 2024, they may be describing patterns that have moved.
Why this matters for you:
- Existing projects need migration planning. A file rename sounds trivial but touches auth flows, redirect chains, and deployment configs.
- Node.js runtime in proxy means fewer edge limitations. Auth libraries that failed on edge runtimes now work in the proxy layer.
- Platform middleware still exists separately. Your Vercel-level rules do not automatically migrate — audit both layers.
Ask your team: "Have we migrated to proxy.ts? Do we have middleware rules at both the Vercel platform level and the Next.js framework level? Are they documented?"
Common middleware mistakes
Checking auth in every page instead of middleware. Results in inconsistent protection — one forgotten page becomes a security hole.
Running database queries in middleware. Slows every request and can hit edge runtime limits. Check tokens in middleware; validate permissions in the app.
Caching personalized responses. If middleware sets user-specific cookies or headers, the CDN may cache one user's version for everyone. Configure cache rules to exclude personalized routes.
No logging or monitoring. Middleware failures are silent — users see redirects or blank pages with no error in your app logs. Enable Vercel observability for middleware execution.
Workflow-first middleware planning
Before adding middleware rules, map the request journey for your key workflows:
- Anonymous visitor hits pricing page — no middleware needed, serve cached static content
- Visitor clicks "Start trial" — middleware checks if already logged in, redirects accordingly
- Logged-in user hits dashboard — middleware validates session token, app loads personalized data
- EU visitor hits any page — middleware checks geo, sets consent cookie, routes to appropriate variant
Document these flows. Each middleware rule should trace back to a specific user journey step — not "because the tutorial said to add middleware."
Related resources on this site
- Related articles: Next.js 16 and Partial Prerendering: What Business Owners Should Know · Supabase + Next.js for Startup MVPs in 2026
- Services: Web Development · Operational Systems — see the full services overview.
- Portfolio: Signal 5 Commercial & Product Creative — browse AI & systems work and design & creatives.
- Industries: Education & Enterprise Training · Government & Public Sector — explore industry guides.
- Case study: KAIA Site Migration
Sources & further reading
Ideas and frameworks in this article draw on the following external references:
Key takeaways
- Routing middleware intercepts requests before your app and cache — use it for auth redirects, geo-routing, A/B tests, and security headers.
- Vercel Routing Middleware is platform-level (any framework); Next.js proxy is framework-level (renamed from middleware.ts in Next.js 16).
- Keep middleware fast and stateless — no database queries, no AI calls, no business logic.
- Audit both platform and framework middleware layers; they serve different scopes and both need documentation.
- Map middleware rules to specific user journey steps, not generic best-practice checklists.