In Next.js, runtime refers to the execution environment available to your code on the server. It determines which APIs and libraries your application can access, directly impacting performance, scalability, and functionality .
Next.js provides two primary server runtimes: the default Node.js Runtime and the lightweight Edge Runtime. The choice between them involves a fundamental trade-off: the Edge Runtime offers lower latency and global scalability by sacrificing access to full Node.js APIs and package ecosystem, while the Node.js Runtime provides complete Node.js capabilities but with higher latency and operational overhead .
You control the runtime for specific route segments by exporting a runtime variable from your layout.tsx, page.tsx, or route.ts file. If not specified, the default nodejs runtime is used . This per-segment configuration allows for a hybrid approach, where parts of your application (like a real-time dashboard) might run on the Edge, while heavier administrative sections use Node.js.
Node.js Runtime
The Node.js runtime is the default and most comprehensive environment. It provides access to all Node.js APIs and the entire npm ecosystem . This makes it the ideal choice for most applications, especially those that rely on heavy computation, database access via native drivers, or specific Node.js modules like fs, path, or crypto. However, this power comes at a cost: slower cold start times and more complex infrastructure management when compared to the Edge runtime .
When deployed to serverless platforms like Vercel, the Node.js runtime operates as serverless functions. These functions offer high scalability and can handle complex loads, with a typical code size limit of around 50MB. However, they can take hundreds of milliseconds to "warm up" (cold boot) before processing requests . Self-hosting on a Node.js server provides full control but requires managing, scaling, and securing the infrastructure yourself.
Edge Runtime
The Edge Runtime is a lightweight, V8-based environment that uses standard Web APIs (fetch, Request, Response) instead of Node.js APIs . It is designed for speed and low latency, as it can be deployed globally to Content Delivery Networks (CDNs), physically closer to users. This results in near-instant cold starts, making it ideal for personalization, geolocation-based routing, A/B testing, authentication, and basic rate limiting .
However, this speed comes with significant limitations. The Edge Runtime does not support all Node.js APIs, and many npm packages may not work as expected . Code size is also heavily restricted, typically between 1-4 MB on Vercel, which limits the use of large dependencies . Furthermore, it does not support Incremental Static Regeneration (ISR) and is incompatible with the revalidate option in route segment config .
Proxy Runtime (Replaces Middleware in Next.js 15+)
Starting with Next.js 15, the middleware.ts file has been renamed to proxy.ts. The functionality remains similar, acting as a request interceptor that runs before routes are rendered, but with a stronger emphasis on proxy and rewrite use cases. The Proxy runs by default on the Edge Runtime, but can be configured to use the Node.js runtime via the runtime config option.
Choose Node.js Runtime when: You need full access to Node.js APIs and npm packages, you are performing complex data processing or CPU-intensive tasks, you require native database drivers, or you are using libraries that rely on Node.js modules like 'fs', 'path', or 'crypto' .
Choose Edge Runtime when: You need to deliver personalized content with low latency, you are implementing authentication, geolocation routing, A/B testing, or rate limiting, and your logic is lightweight (< 1-4 MB code) .
Consider Hybrid Approach: Use per-segment runtime configuration to deploy parts of your app on the Edge and other parts on Node.js. For example, run a personalized dashboard on the Edge while keeping an admin panel on Node.js .
Proxy/Middleware Considerations: Use Edge Runtime for Proxy by default for performance, but switch to Node.js runtime if your Proxy logic requires Node.js-specific APIs, available from Next.js 15 .
Platform Support: While Vercel offers first-class support for both runtimes, self-hosting requires careful configuration. For example, Edge Runtime on Docker requires custom configuration .