Keeping Amplify Authentication Out of Next.js 16 Proxy

Next.js 16 Proxy can send a signed-out visitor away from an account page before the page renders. I keep that redirect optimistic. The destination still resolves the Amplify session, and the Data model still denies unauthorized reads or mutations. This split lets me use request-aware routing without putting slow account lookups in front of every asset and route matched by one file.

Give Proxy one small job

Next.js 16 renamed Middleware to Proxy and fixed the Proxy runtime to Node.js. I use it for request-aware redirects, header changes, and rewrites. AWS documents managed Amplify SSR support through Next.js 15, so the hosted Next.js 16 behavior needs a branch test.

The Next.js Proxy guide warns that Proxy is not a full session-management or authorization solution. Its decision improves navigation; server code and Amplify rules protect the resource.

Narrow the matcher

I match the account and admin route groups and exclude static assets, images, public API endpoints, and health checks. A broad matcher adds server work to requests that cannot benefit from an auth redirect. It can also interfere with the platform's handling of optimized images.

The matcher receives regression tests for public routes, a signed-out protected route, and the callback path used during sign-in. An auth callback loop can make every credential appear invalid.

Use an optimistic signal

Proxy may inspect the presence of the expected session cookie and redirect an obvious signed-out request. Cookie presence does not prove validity, group membership, or access to a record. I name the helper accordingly so later code does not treat it as verified identity.

If the signal is ambiguous, I let the request continue. The destination reads the session with the Amplify server adapter and renders a signed-out or forbidden state.

Enforce access at the destination

A Server Component, Server Action, or Route Handler resolves the current user before returning protected content. Amplify Data authorization still decides whether that identity may read or mutate the model. A hidden page and a redirect do not protect a GraphQL operation.

I request the protected endpoint without browser navigation and with a forged cookie. The backend must deny the data even if Proxy is bypassed or misconfigured.

Migrate without changing behavior

I run the official codemod or rename middleware.ts to proxy.ts, then inspect the export and renamed configuration flags. I avoid adding new auth logic during the rename. A mechanical migration should preserve the existing route behavior.

The Next.js 16 upgrade guide documents the filename and runtime change. Amplify lists Edge middleware as unsupported. Next.js 16 Proxy uses Node, but AWS's managed-SSR range still ends at Next.js 15, so the Proxy deployment remains a canary.

Keep failures visible

Proxy errors can affect a large part of the site. I log safe route categories rather than full URLs with private parameters, and I keep a configuration switch that removes the optimistic redirect while destination checks remain active.

The same boundary applies across the stack: redirects shape navigation, while backend authorization protects data. My hosting comparison covers the operational side of that choice.

Reviewing a Proxy and auth boundary?

I can review matchers, redirect behavior, destination checks, and Amplify authorization without turning Proxy into a second auth system. Send the sanitized route structure through the contact page, or see my Next.js services.