Next.js on Vercel vs Netlify

Next.js is a full-stack React framework created and maintained by Vercel, and it runs well on both Vercel and Netlify. Your application code remains largely the same on both platforms. What changes are the server runtime underneath it, the depth of framework feature support, how you configure and deploy the project, and which storage and background-processing services you connect to.

On Vercel, Next.js runs natively on Vercel Functions with Fluid compute, the native platform built by the team that maintains the framework. On Netlify, the OpenNext Netlify adapter translates your build output at deploy time: it provisions a Netlify Function on AWS Lambda for server rendering and a Netlify Edge Function on Deno for middleware. This guide breaks down how the two platforms differ so you can decide which one fits your project.

In this comparison guide, you'll learn:

• How Next.js deploys and runs on Vercel and Netlify
• Which Next.js features each platform supports, and where support is partial
• How the Vercel Functions and Netlify Functions runtimes differ
• How storage and background processing map across the two platforms
• How each platform prices computing
• When to choose Vercel or Netlify for your project

Both platforms build the same Next.js app, deploy from Git with zero configuration, and create a preview URL for every pull request. The differences begin at the server runtime and extend to feature support, configuration, scaling, and pricing.

Both platforms run your Next.js server code on Node.js, so npm packages that depend on Node.js APIs work on either one without compatibility flags. The most consequential differences are request duration, middleware execution, and concurrency.

Netlify caps synchronous function execution at 60 seconds, and the limit is not configurable. Vercel Functions run up to 300s of wall-clock time on Hobby and 800s on Pro and Enterprise, configurable per route with maxDuration. Netlify offers Background Functions that run up to 15 minutes, but they return an empty 202 response immediately, so they can't stream or return results to the visitor who triggered them.

Middleware runs in different environments. On Vercel, Next.js middleware runs on Vercel Functions, including middleware that uses the Node.js runtime. On Netlify, the adapter deploys middleware to Netlify Edge Functions, a Deno-based runtime with a 50ms CPU time limit per request and a 20 MB compressed bundle size. Netlify supports Node.js middleware but not C++ add-ons or filesystem access, and it evaluates headers and redirects after middleware, which differs from the standalone Next.js behavior.

Netlify also buffers request and response payloads at 6 MB (about 4.5 MB for binary payloads after Base64 encoding) and caps streamed responses at 20 MB. Memory tops out at 4 GB on both platforms, though Netlify's per-function memory configuration requires a credit-based plan.

Vercel maintains Next.js, so the framework runs with full feature support, and new capabilities land on Vercel first. Netlify's support depends on the OpenNext Netlify adapter, which Netlify maintains as open source and tests against each Next.js release. Current adapter coverage is broad, and Netlify's feature support table lists the App Router, ISR, Server Components, Server Actions, streaming, and Cache Components as fully supported.

Two adapter caveats are worth knowing before you commit to a routing design on Netlify. Rewrites in your Next.js configuration can't point to static files in the public directory, and pages that set export const runtime = 'edge' run in the functions region on Node.js rather than at edge locations, with no functionality missing.

What matters most for content-heavy sites is caching, and the two platforms handle it differently:

• Vercel manages Cache-Control for ISR pages automatically on its CDN, and on-demand or tag-based revalidation purges content globally in about 300ms with request collapsing and durable storage. See Incremental Static Regeneration on Vercel.
• Netlify wires the Next.js Full Route Cache and Data Cache into its fine-grained caching primitives, using headers such as Netlify-CDN-Cache-Control and Netlify-Cache-Tag. Cacheable Next.js responses automatically use Netlify's durable cache starting with adapter 5.5.0, and on-demand purges take a few seconds to propagate.

Vercel Functions run in the region you choose, with multi-region support on Pro and Enterprise plans. Netlify Functions run in a single region per function, cmh (US East, Ohio) by default, and changing the region requires a Pro or Enterprise plan, with 12 self-serve regions available. On both platforms, static assets are served from a global CDN; the regional question applies to your server-rendered routes. Netlify additionally runs middleware at global edge locations through Netlify Edge Functions, while your rendering still happens in the functions region.

For most full-stack apps, proximity to your data matters more than proximity to the user. A server function that makes three database round trips from a region far from the database pays that latency three times, while a user-facing response pays the user-to-region latency once. Edge execution helps short, compute-light responses such as redirects and personalization, which is exactly the slice Netlify serves from its edge runtime.

Vercel detects Next.js on import and requires no configuration file, adapter, or build settings. An optional vercel.json covers advanced cases such as cron schedules or per-function regions. Environment variables are read from process.env and are available at build time and runtime. Deploys come from Git pushes (GitHub, GitLab, and Bitbucket) or the vercel CLI, and every pull request gets its own preview URL.

Netlify is also zero-config for Next.js: connect a repository, and Netlify applies the OpenNext Netlify adapter automatically, with next build as the build command and .next as the publish directory. The netlify.toml file is only needed for customizations such as pinning the adapter version:

[build]
  command = "next build"
  publish = ".next"

# Only needed if you pin the adapter version
[[plugins]]
  package = "@netlify/plugin-nextjs"

Netlify integrates with GitHub, GitLab, Bitbucket, and Azure DevOps and builds Deploy Previews for pull requests. Two Netlify-specific gotchas apply to Next.js projects. With pnpm, you must set the PNPM_FLAGS environment variable to --shamefully-hoist (or add public-hoist-pattern[]=* to .npmrc). And Netlify Forms requires a workaround with Next.js: because pages aren't written as static HTML files, you must add a hidden static form file under public/ and submit to it with a client-side fetch, and Server Actions can't handle the submission.

Both platforms expose storage to your code through SDKs and environment variables rather than runtime bindings, so storage code ports between them with package-level changes. Netlify provisions its first-party stores automatically and wires credentials into its packages (@netlify/blobs, @netlify/database) when code runs inside Netlify Functions. On Vercel, Vercel Blob is first-party, and provisioning a Marketplace database wires its credentials into environment variables automatically.

Netlify Blobs is a key-value object store built for frequent reads and infrequent writes, with last-write-wins semantics. Netlify Database is a managed Postgres built into credit-based plans, with a database branch created for each Deploy Preview; its compute and bandwidth consume plan credits, and storage space is free until July 1, 2026, per Netlify's documentation.

Both platforms cover scheduled and background work with first-party features, though the shapes differ: Netlify builds these into its functions model plus an extension, while Vercel ships them as separate products.

Vercel Workflows run durable steps that pause, resume, and retain state from minutes to months, which suits processes such as onboarding sequences, payment retries, and AI agent loops. Netlify's Async Workloads is installed as a platform extension and runs on your site's own serverless functions and blobs, so its usage bills as regular compute; it supports event triggers, multi-step workloads with per-step retries, and scheduled sleeps. Netlify Background Functions respond with an empty 202 immediately, retry twice on failure (after one minute, then two), and can't stream responses, so results go to a database or webhook rather than back to the client.

Both platforms have a free tier and usage-based paid plans, but they meter compute in different units. Netlify condenses all usage into credits, with compute measured in GB-hours: memory allocation multiplied by wall-clock execution time. Vercel bills for CPU and memory separately, only when they're actually used.

On Vercel, Fluid compute bills Active CPU at $0.128 per hour, Provisioned Memory at $0.0106 per GB-hour, plus a per-invocation charge. CPU is billed only while your code runs, memory only while a request is in flight, and nothing between requests. Because one function instance handles multiple concurrent requests, idle time waiting on a database or model API isn't billed as CPU. The Hobby plan includes a free usage allotment, and Pro and Enterprise bill usage beyond their included allotments.

On Netlify's credit-based plans, the Free plan includes 300 credits per month with a hard cap, Personal costs $9 per month with 1,000 credits, and Pro costs $20 per month with 3,000 credits and unlimited team members. Credits meter usage across five dimensions: compute at 10 credits per GB-hour, bandwidth at 20 credits per GB, web requests at 2 credits per 10,000, production deploys at 15 credits each (Deploy Previews and branch deploys are free), and AI inference at 180 credits per dollar of model usage. Add-on packs cost $10 for 1,500 credits on Pro, and when a team runs out of credits without auto recharge, all of its projects pause until the next billing cycle. Netlify adjusted these plans in April 2026, so check the Netlify pricing page for current figures.

The execution limits also measure different things, which matters when you compare them.

The billing units deserve the same scrutiny. A Netlify GB-hour accrues for the entire time a function runs, including time spent waiting for a database query or an LLM response, because it multiplies the allocated memory by the wall-clock duration. On Vercel, that same waiting time bills as Provisioned Memory at $0.0106 per GB-hour, but not as CPU, so I/O-heavy workloads pay for compute only while code executes. For a route that spends 30 seconds awaiting a model API and 200ms processing the result, Netlify meters the full 30 seconds against your credits, while Vercel meters 200ms of Active CPU plus memory for the duration of the request.

The day-to-day workflow is similar on both platforms. You connect a Git repository, push to deploy, get a preview URL for every pull request, and roll back instantly when something breaks. Both detect Next.js without configuration, and both provide a CLI with a local development mode (vercel dev and netlify dev).

Vercel bundles more framework-aware capability around that flow. ISR, Image Optimization, and Draft Mode work without configuration because the platform is built against the framework's internals, and Observability and the Vercel Firewall are part of every deployment rather than add-ons.

Netlify has genuine strengths of its own. Its platform primitives are unusually integrated:

• Netlify Database creates an isolated database branch for every Deploy Preview, with schema migrations applied automatically throughout the deploy lifecycle, making it safer to preview data-dependent changes than to point previews at production data.
• Netlify Forms handles form submissions with spam filtering at no credit cost, though Next.js requires the static-file workaround described earlier.
• Netlify also integrates with Azure DevOps and self-hosted Git repositories (GitHub Enterprise Server, GitLab self-managed, and Bitbucket Data Center), and its extension marketplace offers integrations ranging from queues to CMS providers.

The framework is the same on both platforms, so the decision comes down to feature support, runtime behavior, where your code needs to run, and how the app fits your wider stack.

Many teams successfully run Next.js on either platform.

Choose Vercel when your app depends on the full Next.js feature set, long-running or AI-heavy server routes, fast cache invalidation, and first-party background processing.

Choose Netlify when flat-rate team pricing, Azure DevOps or self-hosted Git support, built-in forms, or per-preview database branching matter more to your team than native framework depth.

• Next.js on Vercel
• Vercel Functions and Fluid compute
• Incremental Static Regeneration on Vercel
• Storage on the Vercel Marketplace and Vercel Blob
• Functions usage and pricing