Next.js
Next.js is an open-source React framework for building full-stack web applications, providing developers with tools for rendering, routing, data fetching, and API creation to create performant and scalable websites.[1] Created by the team at Vercel in 2016, it extends React's component-based architecture with built-in optimizations for production environments.[2] The framework supports multiple rendering strategies, including server-side rendering (SSR), where pages are generated on each request for dynamic content; static site generation (SSG), which pre-renders pages at build time for faster load times and improved SEO; and client-side rendering (CSR) for interactive elements.[3][4][5] Next.js also features file-system-based routing, allowing developers to define routes via directory structures, and includes API routes for handling serverless backend logic without a separate server.[1] It offers two routing paradigms: the Pages Router for traditional setups and the newer App Router, which leverages React Server Components for enhanced performance and streaming. Additional capabilities include image optimization, TypeScript support out of the box, and integration with modern tools like Turbopack for faster development builds.[6] Widely adopted for its developer experience and efficiency, Next.js powers applications for major companies and emphasizes hybrid rendering to balance speed, SEO, and interactivity.[7]Overview
Definition and Purpose
Next.js is an open-source React framework developed by Vercel for building full-stack web applications that are production-ready and performant.[1][2] It leverages React components to construct user interfaces while providing built-in support for multiple rendering paradigms, including server-side rendering (SSR), static site generation (SSG), and client-side rendering (CSR), enabling developers to select approaches that balance speed, SEO, and interactivity.[1] This framework automates much of the underlying tooling, such as bundling and compilation, allowing focus on application logic rather than setup.[8] The core purpose of Next.js is to empower developers to create scalable, SEO-optimized web applications by integrating essential features like routing, data fetching, and caching directly into the development workflow.[8] It addresses common challenges in React-based projects by offering a structured environment that handles optimizations out-of-the-box, thus bridging React's declarative component model with full-stack development needs for dynamic, content-rich sites.[1] For instance, its rendering strategies facilitate faster initial page loads and better search engine indexing, making it suitable for e-commerce, blogs, and interactive dashboards.[8] Next.js builds upon React and assumes familiarity with its fundamentals, such as components, hooks, HTML, CSS, and JavaScript, but does not require prior experience with other frameworks.[1] Developers can extend existing React code incrementally, adopting Next.js features as needed without a complete overhaul, which lowers the barrier to entry for enhancing client-side applications with server capabilities.[8]Key Advantages
Next.js provides significant advantages in search engine optimization (SEO) through its support for server-side rendering (SSR) and static site generation (SSG), which deliver pre-rendered HTML to browsers for faster indexing and improved crawlability compared to client-side rendering in plain React applications. Automatic code splitting ensures that only the necessary JavaScript is loaded for each page, reducing initial load times and enhancing performance, particularly for large-scale applications. Built-in API routes enable the creation of full-stack applications without requiring external servers like Express, allowing developers to handle backend logic directly within the framework.[9] Hybrid rendering combines SSR, SSG, and client-side rendering to offer flexible performance optimization tailored to different page needs. Compared to vanilla React, Next.js reduces boilerplate code by providing out-of-the-box routing, optimization, and deployment configurations, eliminating the need for additional libraries or manual server setup.[8] It includes native TypeScript support, automatically configuring necessary packages and enabling type safety to catch errors early and improve code maintainability. Next.js is particularly suited for e-commerce sites benefiting from fast initial loads via SSG, blogs leveraging static generation for content-heavy pages, and dashboards requiring dynamic data fetching for real-time updates. Developer productivity is boosted by features such as Fast Refresh, which provides hot module replacement for instantaneous feedback on component edits without full page reloads, and file-based routing conventions that simplify project organization by mapping file structures directly to URLs.[10] As of Next.js 16 released in 2025, Turbopack serves as the stable default bundler, delivering 2–5× faster production builds and up to 10× faster Fast Refresh compared to previous versions.[11]History
Origins and Development
Next.js was created in 2016 by Guillermo Rauch, founder and CEO of ZEIT (now Vercel), along with his engineering team, initially as an internal framework to enable server-side rendering for React applications.[12] The project emerged from ZEIT's efforts to address key limitations in React, particularly its client-side rendering approach, which often resulted in poor search engine optimization (SEO) and slower initial page loads for dynamic content.[13] Rauch envisioned a modernized take on traditional server-side rendering models, drawing inspiration from early web paradigms like those in PHP, but adapted for JavaScript's component-based architecture to improve performance and accessibility.[12] The framework was publicly released as open-source on GitHub on October 25, 2016, marking its transition from an internal tool to a community-driven project.[13] Early adoption was rapid, fueled by React's growing popularity and the need for production-ready solutions for universal applications; by May 2018, the repository had amassed over 25,000 stars, reflecting strong developer interest and contributions.[14] This traction positioned Next.js as a go-to option for building SEO-friendly, performant web apps without extensive configuration. In April 2020, ZEIT rebranded to Vercel to better align with its evolving focus on frontend cloud infrastructure, including edge computing capabilities that enhance global deployment and delivery of Next.js applications.[15] This shift, accompanied by a $21 million Series A funding round, allowed the company to deepen integration between Next.js and Vercel's platform, accelerating its development and ecosystem growth.[15]Major Releases and Evolution
Next.js was initially released on October 25, 2016, as version 1.0, introducing fundamental server-side rendering (SSR) capabilities for React applications to enable faster initial page loads and improved SEO.[16] Subsequent major releases built upon this foundation, introducing optimizations and new paradigms. Version 9, released on July 8, 2019, added built-in support for dynamic imports vianext/dynamic, enabling automatic code splitting to reduce initial bundle sizes and improve performance.[17] Version 12, launched on October 26, 2021, integrated the Rust-based SWC compiler for up to 5x faster builds, added middleware support in beta, and provided native compatibility with React 18.[18]
Version 13, released on October 25, 2022, marked a pivotal shift by introducing the App Router in beta alongside React Server Components, allowing components to execute on the server by default for enhanced security and reduced client-side JavaScript. This version also stabilized Turbopack in development mode as an experimental successor to Webpack. Version 14, arriving on October 26, 2023, stabilized Server Actions for form handling and introduced Partial Prerendering in beta, which streams static shells while dynamically rendering interactive sections, thereby improving time-to-first-byte without increasing bundle sizes.[19]
Version 15, released on October 21, 2024, brought stable React 19 support, refined caching semantics with explicit revalidation APIs, and made Turbopack the default for development builds, achieving up to 76.7% faster server startup times compared to Webpack.[20] The most recent major update, version 16 on October 21, 2025, introduced Cache Components for declarative caching, stabilized Turbopack for production builds, added support for the React Compiler to automate memoization, and integrated AI-assisted tools like Next.js DevTools with Model Context Protocol for enhanced developer workflows.[11]
Over its evolution, Next.js transitioned from reliance on the Pages Router—dominant through version 12—for file-based routing and hybrid rendering, to establishing the App Router as the recommended default starting in version 13, which leverages React's concurrent rendering features like Suspense for more granular control over streaming and hydration. Recent releases have increasingly incorporated AI-assisted development, such as integrations with Vercel's AI SDK, to streamline code generation and debugging. Community contributions, often prototyped through Vercel Labs, have driven innovations like Turbopack and edge middleware.
These releases have collectively addressed scalability challenges; for instance, Partial Prerendering in version 14 enables dynamic content without full SSR overhead, reducing latency for interactive apps, while Turbopack enhancements across versions 15 and 16 have improved server startup times by up to 76.7% compared to Webpack, as measured in development and production builds.[20]
As of 2025, Next.js continues to emphasize edge runtime optimizations for global distribution, positioning it for full-stack applications with minimal latency.[11]
Architecture
Routing Systems
Next.js employs two primary routing systems: the legacy Pages Router and the modern App Router. The Pages Router, introduced in early versions of Next.js, relies on a file-system-based convention in the/pages directory, where each file directly maps to a specific route in the application. For instance, a file named about.js in the /pages directory automatically corresponds to the /about URL path, enabling straightforward navigation without explicit route definitions. This system also supports dynamic routing through bracketed filenames, such as [id].js, which captures URL parameters for routes like /post/1.[21]
In contrast, the App Router represents Next.js's evolved routing paradigm, introduced in version 13 on October 25, 2022, and utilizes the /app directory for more flexible, nested routing structures. Files like page.tsx within nested folders define route segments, while layout.tsx files facilitate shared layouts across routes, supporting features like streaming for improved loading performance. This approach promotes colocation, allowing components, data fetching logic, and route handlers to reside alongside their corresponding pages, which enhances modularity and maintainability. The App Router natively integrates with React Server Components, enabling server-side rendering of components by default, and includes proxy.ts (replacing the deprecated middleware.ts) for handling authentication, redirects, and other route-level logic at the edge.[22][23][24]
Key differences between the two systems underscore the App Router's advancements over the Pages Router. While the Pages Router offers a flat, intuitive structure suitable for simpler applications, it lacks built-in support for nested layouts and server components, requiring additional configurations for advanced patterns. The App Router, however, provides hierarchical routing with parallel and intercepting capabilities, allowing multiple route segments to render simultaneously within a layout—such as dashboards displaying analytics and team views side-by-side—or to intercept navigation for overlays like modals without disrupting the underlying page state. These features enable more dynamic user experiences, such as conditional rendering based on user roles or deep-linked modals that preserve navigation history.[25]
Migrating from the Pages Router to the App Router follows an incremental approach to minimize disruptions. Developers begin by creating an /app directory alongside the existing /pages, then progressively port individual pages by replicating their structure in page.tsx files and adapting layouts via layout.tsx. Essential steps include updating metadata handling (replacing next/head with metadata exports), refactoring API routes into route handlers, and ensuring compatibility with data fetching patterns. For advanced navigation, the migration incorporates parallel routes—defined using slot folders like @slot for concurrent rendering—and intercepting routes, which use parentheses in folder names (e.g., (modal)) to capture and render alternative content for specific URLs, often in tandem for modal implementations. This phased strategy allows hybrid operation until full transition, with official guidelines emphasizing testing for rendering behaviors and proxy integration.[26]
Component and Page Structure
Next.js projects follow a file-system-based convention for organizing components and pages, which varies slightly between the legacy Pages Router and the recommended App Router introduced in Next.js 13. In the App Router, the root directory typically includes anapp folder for routing and layout definitions, a components directory for reusable UI elements, and a public folder for static assets like images and favicons that are served directly. Special files such as layout.tsx in the root app directory provide a global template that wraps all pages, while page.tsx files define individual route content.[27][28]
Page components in Next.js are React functional components exported as the default from their respective files, enabling them to render dynamic content based on route parameters. For client-side navigation without full page reloads, the <Link> component from next/link is used, which prefetches linked routes in the background for faster transitions and integrates seamlessly with the router's state management. This approach ensures smooth user experiences in single-page application-like behavior while leveraging server-side rendering. In the Pages Router, pages are similarly defined in the pages directory with default-exported React components, and _app.js serves as a custom App component for global layouts, overriding the default rendering pipeline, while _document.js allows customization of the HTML document structure, such as adding meta tags or scripts outside the app.[29]
Layouts in the App Router support nested structures where parent layouts persist across child route changes, promoting code reuse and consistent UI elements like navigation bars or sidebars without re-rendering. For instance, a root layout.tsx might include a header and footer, while segment-specific layouts in subfolders handle route-grouped elements. Error handling is managed through error.tsx files colocated with routes, acting as React error boundaries to catch and display custom error UIs during rendering or data fetching. Loading states are handled via loading.tsx files, which integrate with React Suspense to show fallback content while asynchronous operations, such as data fetching, resolve. These conventions encourage colocating related files—pages, layouts, and utilities—within route folders to simplify maintenance and improve developer ergonomics.
Head management, which controls document metadata like titles and Open Graph tags, uses the metadata API in the App Router through exported generateMetadata functions or static metadata objects in layout.tsx or page.tsx files, allowing dynamic generation based on route data. In the legacy Pages Router, the <Head> component from next/head is imported and used within page components to inject elements into the <head> tag. Best practices recommend organizing components into dedicated folders outside routing directories to avoid clutter, using TypeScript for type-safe props in reusable components, and leveraging private folders (prefixed with underscores) in the App Router to group routes without affecting the URL structure. This structure facilitates scalable applications by separating concerns between routing logic, UI composition, and static resources.[30]
Core Features
Rendering Strategies
Next.js supports a hybrid rendering model that allows developers to choose from multiple strategies to balance performance, SEO, and dynamic content needs. These strategies leverage React's capabilities while optimizing for server-side and client-side execution, enabling pre-rendering at build time or request time, or rendering entirely in the browser. The choice depends on factors like content freshness, personalization, and interactivity, with static approaches generally prioritizing speed and SEO, while dynamic ones handle real-time data.[31] Static Site Generation (SSG) pre-renders pages at build time, generating HTML files that are served directly to users without server computation on each request. This strategy uses thegetStaticProps function to fetch data during the build process, making it ideal for static or infrequently changing content such as blog posts, marketing pages, or documentation sites. SSG delivers the fastest initial page loads and excellent SEO since search engines can crawl the fully rendered HTML immediately, without relying on JavaScript execution.[31][32]
To address the limitations of pure SSG for content that updates periodically, Next.js introduces Incremental Static Regeneration (ISR), which allows static pages to be regenerated in the background after deployment. ISR builds on getStaticProps by adding a revalidate option, specifying the number of seconds before a page can be regenerated on the next request; for example, setting revalidate: 10 updates the page every 10 seconds if traffic demands it. This approach scales to large sites with millions of pages while retaining SSG's performance benefits, suitable for e-commerce catalogs or news sites where data changes but not in real-time.[31][32]
Server-Side Rendering (SSR) generates HTML on each request, ensuring dynamic, up-to-date content for every user. Implemented via the getServerSideProps function, which runs on the server per request to fetch and inject data into the page, SSR is particularly effective for personalized experiences like user dashboards or pages with real-time data such as search results or authenticated profiles. While it provides strong SEO through server-generated HTML, SSR can increase server load and latency compared to static methods, as rendering occurs at runtime.[31][3]
Client-Side Rendering (CSR) defers rendering to the browser, where JavaScript hydrates a minimal initial HTML shell into a full interactive application. This is the default behavior for React components in Next.js, often used for highly interactive elements like forms or dashboards that load after the initial page. CSR suits non-SEO-critical sections, such as admin panels, but requires JavaScript to be enabled and can result in slower perceived performance until hydration completes, as users see a blank or loading state first. Data fetching in CSR typically occurs via client-side APIs like fetch, complementing server strategies for hybrid apps.[31][5]
In the App Router introduced in Next.js 13 and stabilized in later versions, advanced techniques like Streaming and Partial Prerendering enhance these strategies for better user experience. Streaming uses React's <Suspense> boundaries to progressively send HTML chunks from the server, allowing static parts of a page to load immediately while dynamic sections (e.g., API-dependent components) render asynchronously without blocking the entire response. Partial Prerendering (PPR), available experimentally from Next.js 14 and stable in subsequent releases, creates a static shell around a route at build time, with dynamic "holes" filled via streaming on request; this combines SSG speed for the shell with SSR flexibility for personalized content. PPR reduces Time to First Byte (TTFB) by serving cached static elements instantly from edge networks, improving metrics like Largest Contentful Paint (LCP) for complex pages.[19][33]
Data Fetching Methods
Next.js provides multiple methods for fetching data, tailored to its dual routing systems: the Pages Router and the App Router. In the Pages Router, data fetching occurs primarily through server-side functions that enable static generation or server-side rendering, while the App Router leverages asynchronous Server Components and an extended fetch API for more seamless integration. These approaches allow developers to acquire data from APIs, databases, or file systems, ensuring efficient rendering and hydration on the client. Client-side fetching complements server methods for interactive updates, often using libraries like SWR.[35] In the Pages Router,getStaticProps fetches data at build time for static generation, generating HTML pages that can be served from a CDN without further computation. This method suits content that changes infrequently, such as blog posts, by passing props to the page component for rendering. For instance, a page might fetch blog data from a CMS and export it as static JSON. Conversely, getServerSideProps runs on every request, fetching dynamic data server-side and rendering the page before sending it to the client, ideal for user-specific content like profiles. Both functions execute only on the server, preventing sensitive data exposure to the browser.[36][37]
The App Router shifts to React Server Components, where pages and components can be asynchronous, allowing direct data fetching within the component body using await. This eliminates the need for separate functions, as data is fetched during the server render pass. The native fetch API is extended with built-in caching: requests cache by default in the Data Cache for subsequent requests, but options like { cache: 'no-store' } ensure dynamic fetching per request, or { next: { revalidate: 3600 } } enables time-based revalidation similar to incremental static regeneration. For more granular control, unstable_cache wraps computations to persist results across requests.[38]
Client-side fetching in Next.js occurs in the browser after hydration, supporting real-time interactions without full page reloads. The framework recommends SWR (Stale-While-Revalidate), a React hook library that fetches data, caches it, and revalidates on focus, reconnect, or intervals, reducing latency for updates like notifications. Developers can integrate SWR in Client Components marked with 'use client', as shown in examples where useSWR('/api/user') retrieves and mutates user data. React Query offers similar capabilities for more complex state management, though it requires manual setup.[39]
Caching in Next.js ensures performance by storing fetched data persistently. In the App Router, the Data Cache holds fetch results across requests, while the Full Route Cache stores rendered routes. On-demand revalidation uses revalidatePath('/path') to invalidate and regenerate specific routes, or revalidateTag('tag') to target tagged fetches, enabling updates without rebuilding the entire site. With Next.js 16, Cache Components introduce explicit caching via the 'use cache' directive at the file or function level, marking computations as cacheable during pre-render, and cacheTag for selective invalidation. This consolidates prior experimental features, allowing database queries or API calls to be cached alongside static UI, with support for Incremental Static Regeneration and draft mode for previews. For example, a component might use 'use cache' to cache a query result, revalidated via tags on content updates.[11][40]
API routes in Next.js create backend endpoints via files in the /api directory, handling data fetching and processing server-side. Each /api/route.js file exports a handler for HTTP methods like GET or POST, integrating with databases or external services. In the App Router, Route Handlers support the Edge Runtime for low-latency execution near users globally, using middleware like cookies() or headers(). This setup allows secure data operations, such as authentication checks before fetching user data, without exposing logic to the client.
Advanced Capabilities
Performance Optimizations
Next.js provides several built-in mechanisms for bundling and code splitting to reduce initial load times and improve runtime efficiency. By default, the framework automatically splits code by route segments in the App Router or by pages in the Pages Router, ensuring that only the JavaScript necessary for the current route is loaded on demand. This approach minimizes bundle sizes and enables faster navigation between pages. Additionally, developers can implement lazy loading using dynamic imports, such asimport('module'), to defer the loading of non-critical components or libraries until they are needed, further optimizing resource delivery.[41][42]
Image and font optimizations are handled through dedicated components that automate best practices for modern web performance. The <Image> component from next/image automatically resizes images, generates multiple formats including WebP and AVIF for better compression, and applies lazy loading to prevent unnecessary downloads, all while maintaining visual stability to avoid layout shifts. Similarly, the next/font module enables self-hosting of fonts by downloading and optimizing them at build time, eliminating external network requests and reducing layout shift through preload and display swap strategies. These features collectively enhance page load speeds and Core Web Vitals metrics like Largest Contentful Paint (LCP).[43]
Turbopack, a Rust-based incremental bundler integrated into Next.js since version 13 and stabilized as the default in version 16 (released in 2025), significantly accelerates development and production workflows. It delivers up to 5-10x faster Hot Module Replacement (HMR) during development and 2-5x quicker build times compared to the previous Webpack-based system, while supporting full JavaScript and TypeScript compilation without configuration changes. This shift enables larger-scale applications to iterate more rapidly, with Turbopack's architecture leveraging Rust's performance for tasks like module resolution and asset handling.[11]
For diagnosing and refining performance, Next.js includes analysis tools that provide insights into bundle composition and user experience metrics. The @next/bundle-analyzer plugin generates interactive visualizations of JavaScript bundle sizes, helping developers identify oversized dependencies or redundant code for targeted reductions. Integration with Core Web Vitals is facilitated through built-in optimizations and the useReportWebVitals hook, which allows reporting of metrics like Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP) to analytics services for ongoing monitoring. Caching strategies from data fetching methods can complement these tools by persisting responses to further boost subsequent loads.[44][45]
Styling and UI Integration
Next.js provides built-in support for CSS Modules, enabling developers to write scoped styles that prevent global namespace pollution by automatically generating unique class names for CSS selectors. Files with the.module.css extension are treated as modules, allowing imports like import styles from './Home.module.css'; in components, where class names become accessible as properties on the imported object, such as <div className={styles.title}>. This approach ensures styles are local to the component by default, though global selectors can be used with the :global() modifier for exceptions.
Global styles in Next.js are managed by importing a dedicated file, typically globals.css, into the root layout component within the app directory, ensuring they apply across the entire application without module scoping. This setup supports standard CSS imports and is recommended for site-wide resets or base styles, with the file placed in the app directory for automatic inclusion during builds.
For preprocessors, Next.js offers built-in support for Sass after installing the sass package, allowing the use of .scss and .sass files directly in components or pages with imports like import './styles.scss';, which compile to standard CSS during the build process. This integration handles features like nesting, variables, and mixins without additional configuration, though custom Sass options can be specified in next.config.js for advanced use cases such as include paths or functions. Less, however, lacks official built-in support and requires custom webpack configuration or plugins like next-less for integration, making Sass the preferred preprocessor for seamless adoption.[46]
Tailwind CSS integrates natively with Next.js via PostCSS, requiring installation of tailwindcss, postcss, and autoprefixer packages, followed by generating a tailwind.config.js and adding directives to a global CSS file like @tailwind base; @tailwind components; @tailwind utilities;. This setup enables utility-first styling with full compatibility for server-side rendering and purging unused styles in production, often combined with the app router for optimized class generation.[47]
Theming in Next.js leverages CSS custom properties (variables) for dynamic design systems, declared in root stylesheets like :root { --primary-color: #0070f3; } and accessed via var(--primary-color), facilitating consistent theming across components. Dark mode implementation typically involves media queries or class-based toggles, such as adding a dark class to the <html> element via client-side logic and defining variables like --background: white; in light mode and --background: #1a1a1a; in dark mode, ensuring responsive theme switching without JavaScript for media-driven preferences.
Styled-jsx, a CSS-in-JS solution included by default in Next.js, allows inline scoped styles within JSX using <style jsx>{...}</style>, where styles are automatically scoped to the component and support global rules via <style jsx global>. This enables encapsulated styling similar to CSS Modules but directly in markup, with features like dynamic props for conditional styles, making it suitable for component-specific designs without external files.[48]
Next.js is compatible with popular UI libraries, including Material-UI (MUI), which provides official integration guides for both the pages and app routers, involving wrapping the app with ThemeProvider and handling server-side rendering through custom _document.js or layout components to inject styles correctly. Chakra UI works seamlessly in the app directory by installing @chakra-ui/react and configuring ChakraProvider in the root layout, supporting theme customization and responsive components while respecting Next.js's server components by marking interactive elements as client-side. For styled-components, server-side rendering requires a style registry wrapper in layouts to collect and inject styles during hydration, addressing caveats like mismatched styles between server and client renders, though it may introduce hydration mismatches in the app router without proper 'use client' directives on styled components.[49][50][48]
Deployment and Ecosystem
Hosting and Deployment Options
Next.js applications can be deployed to various hosting platforms that support Node.js servers, static exports, or containerized environments, enabling flexibility for different scalability and performance needs. The framework's build process optimizes assets for production, generating a.next directory that contains compiled code, static files, and server-side bundles, which can then be served by the chosen host. Deployment typically involves running npm run build to create this output, followed by starting the server with npm run start for dynamic applications or exporting static HTML/CSS/JS files for simpler hosting setups.
Vercel, created by the same team behind Next.js, offers seamless one-click deployments with zero configuration, automatically detecting the framework and providing serverless functions for API routes and server-side rendering. It supports automatic scaling to handle traffic spikes, preview deployments for every pull request, and built-in optimizations like edge caching for global distribution. For instance, connecting a Git repository to Vercel triggers builds and deploys on commits, ensuring rapid iteration without manual setup.[51]
Other platforms accommodate Next.js through static exports or custom servers. Netlify excels for static exports by handling builds via its CLI or dashboard, supporting features like incremental static regeneration when configured, and providing edge functions for dynamic elements; users push code to Git, and Netlify automatically deploys the generated static assets from the .next folder. For full server capabilities, AWS (e.g., EC2 or Lambda) and Heroku allow deployment as Node.js applications by installing dependencies and running the production server, often requiring a Procfile for Heroku or EC2 instance configuration for AWS. Self-hosting with Docker involves creating a Dockerfile to bundle the application, building an image from the .next output, and deploying to container orchestrators like Kubernetes for isolated, scalable environments.[52]
Next.js supports two primary runtimes during deployment: the Node.js runtime, which provides full access to Node APIs for complex server logic and is the default for most server components, and the Edge runtime, a lightweight subset optimized for low-latency execution at the network edge with limited APIs, ideal for middleware and simple dynamic functions but unsuitable for file system access. Deployments can integrate CI/CD pipelines, such as with GitHub Actions, where workflows cache the .next/cache directory to speed up builds, run tests, and automate pushes to hosts like Vercel or Docker registries upon code changes.