Next.js 15.5: Release Notes and Upgrade Checklist
Next.js 15.5 moves Turbopack production builds into beta and stabilizes the Node.js middleware runtime. Teams should validate build compatibility, route types, linting changes, and Next.js 16 deprecation warnings before rollout.
- Published
- Coverage
- Frontend
- Desk
- OpenStack Daily Editorial

Release overview
Next.js 15.5 focuses on production build reliability, middleware runtime support, and stronger TypeScript tooling. Turbopack production builds entered beta, making this release a practical point for teams to begin controlled compatibility testing.
The Node.js middleware runtime became stable. Middleware that depends on Node.js APIs or existing server SDKs can now use a supported runtime without being constrained to the Edge Runtime.
The release also introduced a standalone next typegen command. Projects can generate route-aware types before running TypeScript checks, without starting a development server or completing a production build.
Finally, next lint entered its deprecation path and Next.js 16 warnings became more visible. Next.js 15.5 is therefore a useful migration checkpoint rather than a routine patch-only upgrade.
Breaking changes and migration
This is a minor release in the Next.js 15 line, but it includes tooling changes that require attention. Projects should stop treating next lint as a permanent framework command and move toward the ESLint CLI.
Before
{
"scripts": {
"lint": "next lint"
}
}
After
{
"scripts": {
"lint": "eslint ."
}
}
Keep linting, type checking, and production builds as separate CI stages. This makes failures easier to diagnose and prevents one successful command from hiding a problem in another stage.
Key changes
Turbopack production builds enter beta
Turbopack can now be evaluated more seriously in production build pipelines. Critical applications should keep the existing Webpack build available until custom loaders, aliases, styling, and third-party packages have been verified.
{
"scripts": {
"build": "next build",
"build:turbopack": "next build --turbopack"
}
}
Node.js middleware runtime becomes stable
The stable Node.js runtime expands the packages and platform APIs that middleware can use. It does not make middleware a suitable place for slow database queries or large SDK operations, because that work still runs before the request reaches the route.
// middleware.ts
export const config = {
matcher: ["/dashboard/:path*"],
runtime: "nodejs",
};
Route types can be generated independently
next typegen gives CI pipelines an explicit way to generate framework-owned route types before tsc --noEmit runs.
{
"scripts": {
"typecheck": "next typegen && tsc --noEmit"
}
}
Upgrade checklist
- Capture the current build output and critical route behavior.
- Upgrade only Next.js first and keep the existing production bundler.
- Replace
next lintand validate the ESLint configuration separately. - Add a parallel Turbopack build before changing the primary pipeline.
- Review middleware latency, route matching, and Node.js dependencies.
- Resolve Next.js 16 deprecation warnings while still on 15.5.
Frequently asked questions
Can Turbopack production builds be used immediately?
They can be evaluated in production-like CI, but the feature is marked beta in this release. Compare route output and critical flows before replacing a proven build pipeline.
Does stable Node.js middleware replace the Edge Runtime?
No. Node.js middleware is useful when existing Node.js APIs or SDKs are required. The Edge Runtime remains appropriate for smaller, latency-sensitive logic with compatible dependencies.
Why should projects move away from next lint?
next lint is being deprecated. Calling ESLint directly provides a clearer configuration and upgrade path while keeping linting independent from framework build commands.
Where should next typegen run in CI?
Run it before tsc --noEmit. This ensures generated route types are available when the TypeScript compiler checks application code.