Lesson 26 of 81

Runtimes: Node.js vs Edge

Q: You're reviewing a pull request that upgrades a Next.js app from an older major version to the current one. The old proxy.ts (formerly middleware.ts) has `export const runtime = 'edge'` at the top. What do you flag in review, and why?

A strong answer covers: Identifies that proxy.ts cannot set the runtime config option at all in the current version — this line will throw, not silently degrade; Explains that Proxy now defaults to the Node.js runtime as of v16, a real change from the earlier Edge-Runtime default for Middleware; Recommends simply deleting the runtime export rather than trying to set it to 'nodejs' explicitly, since the option isn't allowed in that file at all; Distinguishes this proxy.ts-specific hard restriction from the general 'edge' deprecation on ordinary route segments, which still runs (deprecated) rather than throwing.

"Should this route run on Edge or Node?" used to be a real, live architecture decision. As of Next.js 16 it's mostly a historical question — and the answer for proxy.ts specifically was taken out of your hands entirely.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

In the current version of Next.js, what is the actual status of the Edge Runtime as a `runtime` route segment config value?

It's deprecated — the docs mark it as such and recommend removing the runtime export entirely rather than choosing between the twoIt was removed entirely — setting runtime = 'edge' anywhere in the app now fails the buildIt's the recommended default for any route that doesn't need filesystem access, to minimize cold starts

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Runtimes: Node.js vs Edge

What interviewers actually ask about this, and what a strong answer has to cover.

You're reviewing a pull request that upgrades a Next.js app from an older major version to the current one. The old proxy.ts (formerly middleware.ts) has `export const runtime = 'edge'` at the top. What do you flag in review, and why?

A strong answer covers

Identifies that proxy.ts cannot set the runtime config option at all in the current version — this line will throw, not silently degrade
Explains that Proxy now defaults to the Node.js runtime as of v16, a real change from the earlier Edge-Runtime default for Middleware
Recommends simply deleting the runtime export rather than trying to set it to 'nodejs' explicitly, since the option isn't allowed in that file at all
Distinguishes this proxy.ts-specific hard restriction from the general 'edge' deprecation on ordinary route segments, which still runs (deprecated) rather than throwing

Likely follow-ups

If this same app also has a route.ts file somewhere with runtime = 'edge', is that the same problem, or does it fail differently?
Why might a team have chosen Edge Runtime for their proxy/middleware in the first place, back when it was the default — what was the actual tradeoff they were making?

Practice these with the AI interviewer →

The plain-language idea

The runtime route segment config option selects which JavaScript environment a route renders in:

'nodejs' (the default) — the full Node.js runtime, with access to the complete Node API surface: the filesystem, native modules, everything a normal Node process can do.
'edge' — a stripped-down, V8-isolate-based environment with a much smaller API surface (Web-standard APIs like fetch, Request/Response, crypto — no filesystem, no native Node APIs), historically valued for smaller cold starts and the ability to run geographically closer to a user on platforms that support that kind of distribution.

That tradeoff — full Node capability versus a lighter, faster-starting, more geographically distributable runtime — is why this used to be presented as a real per-route decision. It no longer is, in this version. The Edge Runtime is now deprecated. The runtime option's own reference doc lists 'edge' with a (deprecated) tag and instructs removing the runtime export from route files entirely rather than choosing between the two going forward.

See it in a real thing: what's still actually configurable

// app/api/report/route.ts
export const runtime = "nodejs"; // the default — explicit here only for clarity

export async function GET() {
  // full Node API access: fs, native modules, everything
}

Setting runtime = 'nodejs' on a route is really just naming the default — it's the right instinct if you're reading an unfamiliar codebase and want to confirm what a route can access, but it isn't doing anything a route wouldn't already do unconfigured. Setting runtime = 'edge' still runs, for now, but is a deprecated pattern the docs are actively steering codebases away from, not a live architectural choice to reach for on a new route.

proxy.ts never had this choice to begin with, and that's a deliberate v16 change. Proxy defaults to the Node.js runtime, and the runtime config option cannot be used in proxy.ts at all — exporting one from that file throws an error, full stop, not a warning.

// proxy.ts
export const runtime = "edge"; // throws — runtime cannot be set in Proxy files

What people usually miss

Watch out

The Edge Runtime is deprecated in current Next.js, not just "one of two valid choices." Code (and training data, and older tutorials) that frames 'edge' as a live performance optimization to reach for is describing an earlier era of the framework, not this one.
proxy.ts defaulting to Node.js is a v16 change, not how it's always worked. Earlier versions ran Middleware on the Edge Runtime; v16 renamed the file to proxy.ts and switched its default runtime to Node.js at the same time.
You cannot set runtime in proxy.ts at all — not even to 'nodejs' explicitly. It's not that 'edge' specifically is disallowed; the whole config option throws in that file, because Proxy no longer has a runtime choice to make.
The Edge Runtime's limitations were never about missing features Next.js forgot to add — no filesystem access, no require, disabled eval/new Function are structural properties of running in a V8-isolate sandbox, not gaps expected to close over time.
'nodejs' being the default doesn't mean setting it explicitly is pointless everywhere — on a route where you're removing a legacy runtime = 'edge' export, setting 'nodejs' explicitly (or just deleting the line, since it's the default either way) communicates the migration happened on purpose.

Why this matters in interviews

"When would you use the Edge Runtime over Node.js for a route?" is a question that reveals whether a candidate's knowledge is current — the strong answer today isn't a tradeoff analysis, it's recognizing that Edge is deprecated in modern Next.js and that proxy.ts no longer has a runtime choice to make at all, which is exactly the kind of version-specific fact a shallow "I remember Edge being faster" answer misses.