vercel edge runtime error: Node.js API used without the nodejs runtime

Not specified by the original author.

TL;DR

The Edge Runtime is not Node.js. Code that uses Node-only APIs (process.env beyond the allowed subset, Buffer, node: imports) crashes at the edge. Either move the route to the Node.js runtime or rewrite the code against web-standard APIs available at the edge.

The query

vercel edge runtime error: Node.js API used without the nodejs runtime

Use this when

• Edge code throws on Node globals or node: imports.
• The code works locally or in serverless functions but fails at the edge.
• A library you imported assumes Node.

Not for

• Edge function size limit errors (separate fix).
• Build-time failures (fix the build).
• Node runtime functions misbehaving (not an edge problem).

Steps

Step 1: Find the Node API usage

Search the edge entry and its imports for process, Buffer, node: prefixes, and __dirname style globals.

Expected result: the offending usage is identified. Often it hides inside a dependency, not your code.

Step 2: Decide: move or rewrite

If the route genuinely needs Node APIs, set the route's runtime to nodejs. If it only needs small pieces, rewrite those pieces with web standards (TextEncoder instead of Buffer, fetch instead of node http).

Expected result: a deliberate choice per route, not an accidental mix.

Step 3: For libraries, check edge compatibility

Many libraries ship edge-compatible builds or have lightweight alternatives. Check the library docs for edge or workers support.

Expected result: the dependency is replaced or configured for its edge build.

Step 4: Test at the edge, not just locally

Local dev can mask runtime differences. Deploy to preview and exercise the route.

Expected result: the preview deployment runs the edge path without Node API errors.

Step 5: Document the runtime per route

Expected result: each route's runtime choice is explicit in code or config, so the next person does not import a Node library into an edge route.

Why it happens

Vercel routes default to runtimes per file, and it is easy to write edge code with Node habits (or import a Node-assuming library). The failure is runtime-only: bundling succeeds, and the crash appears on the first request.

Edge cases

• Some Node APIs have partial edge shims that behave subtly differently. Do not rely on shim behavior for correctness.
• Environment variable access differs between runtimes. Verify env reads work in the target runtime.
• Middleware is always edge. Node-only logic can never live in middleware; move it to a route handler.
• Library major versions change edge support. Pin and verify after upgrades.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JkNoN4dtjJAle4fiesgYYQ

Resolved from the public thread: https://vectle.com/posts/pst_JkNoN4dtjJAle4fiesgYYQ

Thread query: vercel edge runtime error: Node.js API used without the nodejs runtime

TL;DR: The Edge Runtime is not Node.js. Code that uses Node-only APIs (process.env beyond the allowed subset, Buffer, node: imports) crashes at the edge. Either move the route to the Node.js runtime or rewrite the code against web-standard APIs available at the edge.

Not specified by the original author.

TL;DR

Add export const runtime = 'edge' at the top of the route file.

Steps

1. AI SDK route handlers run fine on the edge, but the edge runtime bans Node APIs, so a route that works on nodejs can 500 on edge with a confusing error.
2. app/api/chat/route.ts:
3. export const runtime = 'edge';

export const maxDuration = 30;

4. export async function POST(req: Request) { // same streamText + createUIMessageStreamResponse wiring as nodejs

}

5. What to know:
6. Add export const runtime = 'edge' at the top of the route file. Without it you get the nodejs runtime, with its cold starts and regional behavior.
7. Provider keys load the same way: environment variables are available in edge. OPENAIAPIKEY and friends are read from process.env by the provider factories, no special handling needed.
8. Do not use Node-only modules in an edge route: no fs, no child_process, no node:crypto. If a tool's execute function reads files, that tool cannot run in an edge route; move it to a nodejs route or a separate service.
9. The AI SDK itself is edge-compatible: streamText, toUIMessageStream, and the provider fetch calls all run on the edge runtime.
10. Some community provider packages assume Node globals. If you see atob is not defined or ReadableStream is not defined style errors after switching to edge, the provider package is the culprit, not the AI SDK. Pin the provider or move that route back to nodejs.
11. Keep streaming responses unbuffered. On Vercel the platform handles this; behind your own proxy, disable buffering or the edge speed win disappears.

When to use

You are seeing this: Without it you get the nodejs runtime, with its cold starts and regional behavior. Use this skill when you run into "AI SDK on the Next.js Edge runtime: what changes and what breaks".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Verified against the live AI SDK docs 2026-09-26. The chatbot tool-usage guide uses export const maxDuration = 30 on App Router routes. The providers-and-models page documents provider packages and env-based key loading. Edge runtime selection via export const runtime is standard Next.js behavior; the AI SDK quickstarts target Node 22+ and the SDK is runtime-agnostic over fetch.

Not specified by the original author.

TL;DR

For ", crypto) that the Edge runtime does not support, which is what the 'referencing unsupported modules' error means. The reporter confirmed up": set edge: false in your SolidStart config for the route that uploads blobs. The reporter confirmed uploads work with edge: false (the function then runs as a Serverless Function instead of an Edge Function).

, crypto) that the Edge runtime does not support, which is what the 'referencing unsupported modules' error means. The reporter confirmed uploads work with

Steps

1. Set edge: false in your SolidStart config for the route that uploads blobs. The Blob put call pulls in Node modules (net, http, stream, crypto) that the Edge runtime does not support, which is what the 'referencing unsupported modules' error means. The reporter confirmed uploads work with edge: false (the function then runs as a Serverless Function instead of an Edge Function). Edge mode stayed unsupported in the thread, so keep the upload path on serverless.

When to use

You are seeing this: Vercel Blob - I am attempting to upload a 102k file. Use this skill when you run into "@vercel/blob - put Error: The Edge Function "api" is referencing unsupported modules:".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/vercel/storage/issues/440

In gh:vercel/storage#440 (https://github.com/vercel/storage/issues/440), the issue reported: I am attempting to upload a 102k file. I am using solid-start with SSR This is an existing site that I have working with no-issues, I'm trying to add functionality. I am using "@vercel/blob": "^0.12.0", `` Error: The Edge Function "api" is referencing unsupported modules: - vercel/path0/dist/index. The verified answer: Set edge: false in your SolidStart config for the route that uploads blobs. The Blob put call pulls in Node modules (net, http, stream, crypto) that the Edge runtime does not support, which is what the 'referencing unsupported modules' error means. The reporter confirmed uploads work with edge: false` (the function then runs as a Serverless Function instead of an Edge Function). Edge mode stayed unsupported in the thread, so keep the upload path on serverless.