# OpenNext vs. Vercel: how to run Next.js anywhere (AWS, Cloudflare, Netlify) — and when to stick with Vercel
kouta222

kouta222 @kouta222

About: Software engineer mainly frontend developing / seek for an engineer position in usa

Location:
Tokyo,japan
Joined:
Jan 21, 2024

# OpenNext vs. Vercel: how to run Next.js anywhere (AWS, Cloudflare, Netlify) — and when to stick with Vercel

Publish Date: Aug 13
1 0

TL;DR

Vercel is the "it just works" home for Next.js with zero-config deploys, Edge/Serverless runtimes, preview deployments, and first-class cache/revalidation features.

OpenNext is an open-source adapter that repackages your Next.js build so you can deploy it on AWS, Cloudflare Workers, or Netlify with behavior close to Vercel's runtime — without vendor lock-in.

  • If you want control, portability, or lower infra cost at scale, OpenNext is compelling. If you want speed, DX, and batteries-included features, Vercel remains the fastest path.

What OpenNext is (in one minute)

OpenNext is a community project that consumes the output of next build and converts it into deployable packages for multiple targets. Concretely, it splits your app into server handlers, image optimization, middleware, and caches, then emits artifacts your IaC (SST, CDK, Terraform) can wire up behind CloudFront, Lambda, Workers, etc.

It's not a hosting platform; it's a build adapter + runtime glue. The docs highlight wide production use and a goal of supporting "all Next.js features."

Where OpenNext runs

How OpenNext works on AWS (architecture tour)

OpenNext's AWS docs describe the default architecture and the folders it generates under .open-next/:

  • Assets: hashed (_next/**) vs. unhashed (public/**) with recommended cache headers. Serve directly via CDN.
  • Server Lambda: wraps Next's NextServer (standalone build) for SSR, ISR, SSG, and API routes.
  • Image optimization backend: ships with sharp, compiled for the target arch.
  • Revalidation backend: consumes a FIFO queue to perform on-demand revalidation.
  • Warmer backend (optional): invokes your server function periodically to reduce cold-starts; costs are small and can be pre-warmed on deploy.

OpenNext does not create infrastructure; you wire these pieces up using SST/CDK/etc. The docs even compare OpenNext, Vercel, Amplify, and Docker across features like function splitting, ISR, and on-demand revalidation.

Quick start on AWS with SST (serverless path)

SST's "Next.js on AWS" guide shows a Serverless (OpenNext) flow and a Containers (ECS/Fargate) flow. For the serverless option, you initialize SST in your Next app, add AWS resources (like an S3 bucket), link them to the Nextjs component, and sst deploy. sst.dev

How OpenNext works on Cloudflare

The @opennextjs/cloudflare adapter builds your app and transforms the output to run inside the Cloudflare Workers runtime with Node.js compatibility. It supports Next.js 15 minors and the latest 14 minor, and a broad set of features (App Router, SSR, ISR, PPR, Middleware, <Image> via Cloudflare Images, etc.).

  • Scaffold a new project (pre-configured for Workers):
  npm create cloudflare@latest -- my-next-app --framework=next --platform=workers
Enter fullscreen mode Exit fullscreen mode

opennext.js.org

  • Cloudflare's own guide points to the OpenNext adapter for Workers deployments.
    Cloudflare Docs

  • Heads-up: Worker bundle size is 3 MiB (free) or 10 MiB (paid) compressed; OpenNext docs call this out and show Wrangler's size reporting.

  • Use Wrangler v3.99.0+ for the current adapter.
    opennext.js.org

And where Vercel fits

Vercel is the first-class home for Next.js: zero-config deploys, CI-connected preview URLs, and native support for Serverless/Edge Functions and the Next.js Data Cache with on-demand/tag-based revalidation (propagates globally in ~300 ms).

  • Edge Functions: set runtime: 'edge' or default the app to Edge; ideal for latency-sensitive work at the network edge.
  • ISR: straightforward with export const revalidate = ... (App Router) or fetch(..., { next: { revalidate }}).

When to choose which

Choose Vercel if you want:

  • The fastest path to reliable production deploys with minimal ops.
  • Platform features (Data Cache, fast global revalidation, preview deployments) tightly integrated with Next.js.

Choose OpenNext if you want:

  • Portability (multi-cloud or need to run on AWS/Cloudflare/Netlify).
  • Infra control & cost tuning (e.g., mix ECS + Lambda; bring your own cache/CDN layers).
  • Deeper integration with your stack (VPCs, private services, custom middleware outside the Next process).

Comments 0 total

    Add comment