Vercel's Edge runtime runs npm packages only if they ship as ES modules and avoid native Node.js APIs, the file system, and dynamic code execution such as eval. Most libraries that lean on Node.js built-ins will not load. Check each dependency against that list before it reaches an edge route.
What the runtime is
Vercel documents the Edge runtime as built on the V8 engine, running in isolated execution environments that do not need a container or virtual machine. It exposes a subset of Web APIs such as fetch, Request and Response, plus a short list of Node.js modules: async_hooks, events, buffer, assert and util.
One note before you build on it: the same page says Vercel recommends migrating from edge to Node.js for performance and reliability, and that starting in Next.js 16.3, setting runtime to edge is no longer supported, so routes and pages run on Node.js. Check the current page for your framework version before choosing the edge runtime for new work.
The compatibility rules for dependencies
From Vercel's documentation:
| Rule | What it means for a package |
|---|---|
| node_modules can be used if they implement ES Modules | CommonJS-only packages fail |
| Packages must not use native Node.js APIs | No file system reads or writes |
| Calling require directly is not allowed | Use import |
| eval and new Function are disabled | Packages that build code from strings fail |
| WebAssembly.compile and instantiate from a buffer are disabled | Wasm must come from an import statement |
A five minute test before adding a package
- Open the package manifest. Look for an ES module entry. If it only has a CommonJS main, expect trouble.
- Search the source for Node built-ins. Imports of fs, path, net, child_process or crypto from Node are warning signs.
- Search for dynamic code. eval and new Function inside a dependency fail at runtime.
- Build and run on a preview deployment. Vercel says libraries that rely on dynamic code execution produce a runtime error, so do not assume a local test is enough.
- Record the result next to the dependency so the next upgrade is checked the same way.
Why this helps security reviews
The restrictions are a side benefit for risk. A package that cannot touch the file system or build code from strings has fewer ways to misbehave. That is not a guarantee, and it does not cover a package that sends your data to a remote host using fetch. Still, a short allowed API list gives reviewers something concrete to check.
It also means a minor version bump can break an edge route. If a dependency adds a Node built-in in a new release, the route can fail at deploy time or run time. Pin versions, read changelogs for edge routes, and test upgrades on a preview before production.
Size matters too
Vercel documents a code size limit after gzip compression for the Edge runtime: 1 MB on Hobby, 2 MB on Pro and 4 MB on Enterprise, counting your code, imported libraries and bundled files. We cover the trade in edge bundle size limits and dependency choices.
Where Safeguard fits
Safeguard's dependency scanning reads your lockfile and flags known vulnerable versions, and reachability analysis helps show which findings your code can actually call. It does not replace the compatibility test above. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Can an edge route use a CommonJS package?
Vercel says node_modules can be used as long as they implement ES Modules, and calling require directly is not allowed. A CommonJS-only package is likely to fail.
Why does a library fail only after deployment?
The edge runtime disables eval and new Function and offers a subset of Node.js APIs. A library that needs them can pass a local run on Node.js and fail at the edge.
Sources
Last reviewed: 19 October 2026.
