Next.js runtime
If you've read older Next.js material, you likely came across a real, meaningful choice here: render this segment on Node.js, or on the leaner, faster-cold-start Edge Runtime. That choice, as of the current version this project runs, no longer really exists — and this short reference is worth reading precisely because it's short: the option remains in the type system, but one of its two historical values is now deprecated, and understanding why matters more than the syntax itself.
The Option
export const runtime = "nodejs";
Two values exist in the type:
'nodejs'— the default, and now effectively the only supported choice going forward.'edge'— deprecated.
The Deprecation, Stated Plainly
The current guidance is direct and unambiguous: remove the runtime export from your route files if it's set to 'edge'. The Edge Runtime itself is deprecated — this isn't a case where the config option changed shape while the underlying capability persisted; the runtime this option used to let you opt into is itself being phased out. The official Edge Runtime Deprecated message is the canonical source for the full rationale and timeline, but the practical instruction for anyone maintaining an existing route is simple: if you see export const runtime = 'edge' (or the even older 'experimental-edge' string), that line needs to come out.
If you're migrating from the older 'experimental-edge' value specifically, a dedicated codemod exists to handle the mechanical rename to 'edge' first — worth running that before then removing the export entirely as part of a broader move off Edge Runtime altogether, rather than trying to hand-edit every occurrence across a large codebase.
One Restriction Worth Knowing Regardless of Deprecation Status
This option cannot be used inside Proxy files at all. Proxy has its own separate runtime story — it defaults to the Node.js runtime as a matter of Proxy's own architecture, not something configured through this route-segment-config export — and attempting to set runtime inside a proxy.ts file throws an error rather than being silently ignored. If you need runtime-specific branching inside Proxy logic, the pattern is checking process.env.NEXT_RUNTIME at runtime within your Proxy function itself, not exporting a runtime config the way a page or Route Handler would.
What This Means Practically Going Forward
For new code, there's genuinely nothing to decide here anymore — omit the runtime export entirely and you get Node.js, which is the only path forward that isn't actively being deprecated. For existing code still carrying runtime = 'edge' or runtime = 'experimental-edge' from an earlier phase of the project, treat removing it as part of your broader upgrade work when moving to a current Next.js version, not as an optional cleanup task to defer indefinitely — the runtime the export used to select is going away, and the config option along with it is really only documented today to help you find and remove it correctly.
Version History
| Version | Changes |
|---|---|
| Current | Edge Runtime deprecated; 'edge' value should be removed from route files |
v15.0.0-RC | 'experimental-edge' deprecated in favor of 'edge'; a codemod is available for the rename |
Key Takeaways
| Value | Status |
|---|---|
'nodejs' (default) | Supported — effectively the only path forward |
'edge' | Deprecated — remove from route files |
'experimental-edge' | Older deprecated string; codemod-migrate to 'edge' first, then remove entirely |
| Usable in Proxy? | No — throws an error; Proxy has its own separate, non-configurable Node.js default |
This is one of the rarer cases in the App Router's configuration surface where the right answer for new code is simply "don't touch this option at all" — the meaningful choice it used to represent has been retired, and the reference itself now exists mainly to help teams still carrying the old export find it and remove it correctly during an upgrade.
