Next.js middleware.ts to proxy.ts: What Changes and Why It Matters

Next.js 16 quietly renamed middleware.ts to proxy.ts. Most changelogs bury it next to Cache Components and Turbopack updates, but it deserves its own conversation.

What Actually Changes

1. Filename: middleware.ts becomes proxy.ts
2. Export: named export middleware becomes default export proxy
3. Default runtime: Edge becomes Node.js

That third point is the one worth sitting with. Edge runtime gave you global low latency distribution but a restricted API surface, so you were often stuck finding Edge compatible forks of packages or writing workarounds. Node.js runtime removes most of that friction since proxy.ts now has full Node API access by default.

Do You Need to Migrate Right Now?

middleware.ts still works. It's deprecated, not removed, so nothing breaks on upgrade.

• If your middleware just checks cookies, headers, or does basic redirects: migrate now, it's roughly a five minute rename and retest.
• If you're leaning on Edge specific geo distribution or Edge only APIs: branch it, benchmark proxy.ts under real traffic patterns first, then decide.

What's in the Full Guide

The full writeup covers a real auth check example migrated step by step, a compatibility table for what breaks (and what doesn't) under the Node.js runtime, and a free tool that rewrites your middleware file for you automatically.

Read the full guide: https://devencyclopedia.com/blog/nextjs-middleware-to-proxy

Curious what others are seeing here, has anyone hit compatibility issues moving from Edge to Node.js runtime in production?