The Netlify Next.js Runtime v5 is the latest iteration of Netlify’s specialized runtime for Next.js applications, designed to bring the full power of Next.js’s App Router to Netlify’s edge infrastructure.
Let’s see it in action. Imagine you have a simple Next.js 13+ app with the App Router enabled, structured like this:
my-next-app/
├── app/
│ ├── page.js
│ └── layout.js
├── public/
│ └── favicon.ico
└── next.config.js
The app/page.js might look like this:
export default function Page() {
return (
<div>
<h1>Welcome to the App Router!</h1>
<p>This is a server component.</p>
</div>
);
}
And app/layout.js:
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
</html>
);
}
When you deploy this to Netlify with the Next.js Runtime v5 configured (typically automatically detected if next.config.js is present and output: 'standalone' or output: 'export' is not set), Netlify transforms your Next.js App Router application into a series of edge functions and static assets.
The core problem this runtime solves is bridging the gap between Next.js’s sophisticated server-side rendering (SSR), server components, and incremental static regeneration (ISR) capabilities, and Netlify’s globally distributed edge network. Before this, running App Router features reliably on Netlify often required complex workarounds or a full server. Runtime v5 allows you to leverage these powerful Next.js features without managing your own servers, benefiting from Netlify’s performance and scalability.
Internally, Netlify analyzes your Next.js project during the build process. It identifies different route types: static pages, dynamic pages that require server-side rendering, and API routes. For dynamic routes and server components, Netlify compiles them into individual Netlify Edge Functions. These functions are deployed to Netlify’s edge locations worldwide. When a user requests a dynamic page, the closest edge function executes the Next.js rendering logic for that specific page, returning the HTML to the user. Static assets are served directly from Netlify’s CDN.
The exact levers you control are primarily within your next.config.js file. For example, to enable the standalone output, which Netlify Runtime v5 fully supports and optimizes for, you’d set:
/** @type {import('next').NextConfig} */
const nextConfig = {
output: 'standalone',
};
module.exports = nextConfig;
This standalone output is crucial because it bundles only the necessary files for your Next.js application to run, making it highly efficient for deployment on serverless platforms like Netlify. Netlify’s runtime then takes this standalone output and intelligently deploys its server-side components as edge functions.
For routes that can be statically generated at build time, Netlify will pre-render them into static HTML files. When you use features like getStaticProps (though less common in App Router compared to Pages Router, it still exists for certain migration scenarios or specific patterns) or when a server component is rendered to static HTML, these become static assets on Netlify’s CDN. This hybrid approach ensures that static content is delivered with maximum speed, while dynamic content is handled by the nearest edge function.
The ability to run server components directly on the edge is a significant advantage. Unlike traditional serverless functions that might have cold starts or regional limitations, Netlify’s edge functions are distributed globally. This means a server component rendering request for a user in Tokyo will be handled by an edge function in or near Tokyo, minimizing latency.
One aspect that often surprises developers is how Netlify handles Incremental Static Regeneration (ISR) with the App Router. While revalidate props on server components or route handlers are the mechanism, Netlify’s runtime intercepts these revalidation requests. Instead of a traditional server process, Netlify triggers a background re-fetch and re-generation of the specific static page or component, updating the CDN cache. This process is managed by Netlify’s infrastructure, ensuring that your ISR content stays fresh without you needing to manage a dedicated revalidation server.
The next challenge you’ll likely encounter is optimizing the performance of your dynamic server components and API routes deployed as edge functions, particularly concerning their execution time and memory footprint.