Migrating Off the Vercel Edge Runtime: Field Notes 81edcb

Headline: Vercel's Edge Runtime is deprecated in favor of the default Node.js runtime on Fluid Compute, and removing export const runtime = 'edge' from a Next.js route hands back full Node.js APIs without losing streaming responses.

Key takeaways

• The Edge Runtime is a deprecated, isolate-based runtime with a restricted API surface — no fs, no native Node crypto module, a partial Buffer polyfill.
• Dropping runtime = 'edge' does not break streaming. ReadableStream, Server-Sent Events, and AI SDK token streaming all work on the default Node.js runtime with zero extra config.
• Fluid Compute reuses warm function instances across concurrent requests instead of spinning up one instance per request — that's the mechanism that replaced "Edge is faster to cold-start" as the main argument for picking it.
• Next.js Middleware on Vercel now runs on the full Node.js runtime too, so middleware code no longer has to be written against the Edge's restricted environment.
• The part of a migration most likely to break is a dependency with Edge-only assumptions baked in, not the runtime config line itself.

Why remove export const runtime = 'edge' from a Next.js route?

Because the Edge Runtime no longer buys you anything the default Node.js runtime doesn't also give you on Vercel. I went through a handful of routes in a side project that had runtime = 'edge' pinned from back when it was the only way to get low cold-start, globally distributed execution. That argument doesn't hold anymore: Fluid Compute gives the Node.js runtime the same distribution model, and it keeps the full Node.js API surface instead of the Edge's V8-isolate subset. Every route I migrated kept working after I deleted one line.

What capabilities does a route lose by staying on the Edge Runtime?

The Edge Runtime does not give you fs, does not give you Node's native crypto module, and only partially polyfills Buffer. Package size is also tightly constrained compared to the 5 GB limit Fluid Compute allows, which matters the moment a dependency pulls in a native binding or something like Playwright. On Edge, those dependencies fail at build time or silently misbehave at runtime — I hit this with a PDF-generation library that expected real Node Buffer semantics and produced subtly wrong output on Edge before I traced it back to the polyfill.

What's the first thing that breaks when migrating a route off Edge?

In my experience, it's never the handler body — it's a feature-detect or an import that assumed Edge. Code that checks for the EdgeRuntime global to branch behavior, auth or database client libraries that ship a separate edge-compatible entry point behind a conditional export, and middleware matchers written narrowly to avoid Edge's restrictions are the three places worth checking before touching the runtime export itself. The build usually still succeeds — the breakage shows up at request time instead.

Does streaming still work if I drop the Edge Runtime?

Yes, and this is the misconception that stops people from migrating. Streaming a response — ReadableStream, Server-Sent Events over text/event-stream, token-by-token AI output — is not an Edge-exclusive capability. The same handler works unchanged on the default Node.js runtime:

// Works identically with or without the edge runtime pinned
export async function GET() {
  const stream = new ReadableStream({
    start(controller) {
      controller.enqueue(new TextEncoder().encode('data: hello\n\n'));
      controller.close();
    },
  });
  return new Response(stream, {
    headers: { 'Content-Type': 'text/event-stream' },
  });
}

Delete export const runtime = 'edge'; above that handler and nothing about the streaming behavior changes. What changes is that fs, native crypto, and the rest of the Node.js standard library become available if the route ever needs them.

Edge Runtime vs. Node.js on Fluid Compute: what actually differs?

Capability	Edge Runtime	Node.js (Fluid Compute)
Node.js APIs (fs, crypto, net)	Restricted or polyfilled	Full access
npm package compatibility	Partial — native bindings often fail	Full, within the package size limit
Package size limit	Small, isolate-constrained	Up to 5 GB
Cold starts	Fast, isolate-based	Reduced via instance reuse across concurrent requests
Max execution duration	Short, isolate-based limit	Up to 300s by default
Streaming / SSE	Supported	Also supported — not Edge-exclusive
WebSockets	Not supported	Supported

How do I verify an Edge-to-Node migration before shipping it?

Delete the runtime export on one route at a time, not the whole app at once — it makes a regression trivial to bisect. Run the full test suite, specifically anything that touches the route's dependencies, since Edge-specific fallbacks can mask bugs that only Node's real APIs expose. Hit streaming endpoints manually with curl -N to confirm the response still flushes incrementally instead of buffering. Then check the function's logs for execution duration and invocation count after a day of real traffic — that's the number that tells you whether Fluid Compute's instance reuse is actually kicking in for that route.

FAQ

Q: Do I need the Edge Runtime to stream AI responses in Next.js? A: No. Streaming a ReadableStream or Server-Sent Events response works on the default Node.js runtime; the Edge Runtime is not required for token-by-token AI output.

Q: What happens to routes still pinned to runtime = 'edge' today? A: They keep running, but Vercel and Next.js are steering new code toward the Node.js runtime on Fluid Compute, so staying on Edge becomes a maintenance cost rather than a performance advantage.

Q: Does dropping the Edge Runtime hurt latency for globally distributed users? A: In practice the gap closes, because Fluid Compute reuses warm instances across concurrent requests instead of creating a new isolate per request — that was the main mechanism behind Edge feeling faster.

Q: Can Next.js Middleware run on Node.js instead of Edge? A: Yes. Middleware on Vercel supports the full Node.js runtime under Fluid Compute, so it no longer has to be written against the Edge's restricted API surface.

Q: What's the biggest risk in an Edge-to-Node migration? A: A dependency with Edge-only assumptions — a library with a separate edge entry point, or code that feature-detects the EdgeRuntime global — is more likely to break than the route handler itself.

---

Originally published on devya.dev. Also on eng-ahmed.com. Built by Devya Solutions