Does Amplify Hosting Support Next.js 16?

I can install Next.js 16 faster than AWS can update a hosting support page. That timing does not make the version supported. Amplify Hosting support for Next.js 16 remains a documentation question, while a branch canary answers whether this application's static, SSR, API, image, and authenticated routes survive the upgrade. The release record names the package versions, Node runtime, commit, and observed responses. Production keeps a tested downgrade path until someone accepts the documented support gap.

Start with the documented gap

This project's lockfile resolves Next.js 16.2.11. Check npm's current latest tag before starting the canary. Next.js marks the 16.x major as Active LTS, while AWS currently documents Amplify Hosting managed SSR support through Next.js 15.

The Next.js 16.3 release notes describes the framework changes. The AWS Amplify Hosting Next.js support page defines the hosting boundary I plan around. A build that happens to deploy does not extend the provider's support promise.

Separate documented support from observed compatibility

I pin Next.js, React, Node, the package manager, and the lockfile on a branch. Amplify supports Node 20, 22, and 24, so local checks and the hosted build use one major version. Floating versions make a failed deployment hard to reproduce.

The production baseline records build output, deployed routes, runtime logs, cache headers, image responses, and a signed-in request. Those facts describe the current application rather than the provider's support policy.

Build a feature compatibility matrix

A home page proves little. Build the canary around the routes most likely to expose a hosting mismatch: one static page, one SSR page, a Route Handler, an optimized image, and an authenticated Amplify Data request. Add the 404 and error boundary because routine browsing may not reach them.

Each check records status, headers, visible result, and the deployed commit. Compare the canary with production instead of treating any HTTP 200 as a pass.

Record observed compatibility

Inspect warnings about unsupported output, runtime selection, Proxy, and missing dependencies. A green build can still package a route incorrectly. Runtime logs show whether the first live request loads the same modules that the build accepted.

Keep experimental Next.js flags off unless the matrix tests one flag on purpose. Several experiments in one branch leave no clean cause when the server fails.

Choose a production posture

The release branch keeps the prior lockfile and package versions one revert away. Data schema changes remain backward compatible during the test, so a frontend rollback does not require a database repair.

Promote only after repeated cold and warm requests pass and someone accepts the support gap. If Amplify buffers, rejects, or misroutes a feature that works under next start, remove that feature or return to the documented version range.

State what the result proves

A successful canary proves that one application, commit, region, runtime, and route set worked on that date. It does not prove support for every Next.js 16 feature. I keep the AWS support link and test date in the release note so another developer can recheck the boundary.

My broader AWS Amplify vs. Vercel for Next.js comparison explains why host capability and operational ownership belong in the framework decision.

Need a Next.js compatibility review?

I can review an Amplify branch, representative server routes, and the rollback evidence before production changes. Send the versions and sanitized build output through the contact page, or see my AWS development services.