Rename middleware.ts in NextJs 16 Beta

[paulvanbrenk]

Why? This feels like a case of change for the sake of change.

[haroonmaqbool]

The rename from middleware.ts to proxy.ts in Next.js 16 Beta is meant to clarify its role at the network boundary, focusing on request routing and proxying rather than traditional app-level middleware logic. The goal is to reduce confusion since Next.js middleware now primarily handles edge-level routing and rewrites not in-app logic like Express-style middleware.

[paulvanbrenk]

So where would auth and request logging live in the future?

[haroonmaqbool]

The auth and request logging would likely move into Route Handlers or server actions since they provide more granular control over individual routes. The new proxy.ts is mainly for handling network-level rewrites, redirects, and headers at the edge while per-route logic like authentication, logging, or validation will be better handled within the app’s server functions.

[paulvanbrenk]

However things like auth, are generally not just per route, but per folder?

e.g.
the root of the app, sign-in, and sign-up pages are anonymous
the app requires auth per user
potential admin pages requires auth per role

So I would have to add authentication for each page in each of these scenarios. That's a lot more error-prone that being able to handle that centralized in a single file.

[haroonmaqbool]

Yeah, that’s true but you can still keep auth or role checks centralized by creating a shared helper and calling it inside your route handlers or server actions. It’s a bit more manual than the old middleware setup, but gives better control and avoids edge-level side effects.

[DanielSalazarLoaiza]

While the rename might look unnecessary at first, it actually aligns with the new network boundary model introduced in Next.js 16.
The term “proxy” better reflects the role this file now plays — handling routing, edge requests, and network interactions rather than just middleware logic.
In that sense, it’s not just a rename for the sake of change, but a clarification of intent in the evolving App Router architecture.