# 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:

```ts
// 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](https://www.devya.dev/blogs/vercel-edge-runtime-migration-nodejs-fluid-compute-field-notes). Also on [eng-ahmed.com](https://www.eng-ahmed.com/blog/vercel-edge-runtime-migration-nodejs-fluid-compute-field-notes). Built by [Devya Solutions](https://www.devya.dev/)