MENU

Other Platforms

Because Vercel is built by the Next.js team, it understands the framework's hybrid rendering output -- a mix of static files, prerendered pages with revalidation windows, edge functions, and serverless functions -- natively. Most other hosting platforms were not built with that model in mind, so deploying Next.js's full feature set to them usually means installing a platform-specific adapter or build plugin that translates Next.js's build output into whatever primitives that platform actually offers (their own edge functions, their own serverless runtime, and so on). Without one, you're generally limited to the parts of Next.js that behave like a plain static site or a plain Node.js server -- which is still a completely valid deployment, just a smaller one.

Netlify

Netlify auto-detects a Next.js project and builds it using its official @netlify/plugin-nextjs runtime, which maps ISR, Server Actions, Middleware, and Image Optimization onto Netlify Functions and Netlify's edge network. In most cases no manual configuration is required beyond connecting the repository -- the plugin is installed automatically when the framework is detected.

AWS Amplify / App Runner

AWS Amplify Hosting has built-in support for Next.js SSR: it detects the framework, runs the build, and deploys the server-rendered parts to AWS Lambda behind the scenes, similarly to how Netlify's plugin works. App Runner (along with plain ECS/Fargate) takes a different approach entirely -- there's no Next.js-specific integration, so you deploy it the same way you would to any container platform: build the app with Docker using output: 'standalone', push the image to a registry, and point the service at it.

Cloudflare Pages / Workers

Cloudflare's runtime is not Node.js, so Next.js does not run on it unmodified. Deploying there means building with a community-maintained adapter -- historically @cloudflare/next-on-pages, with the OpenNext project's Cloudflare adapter as a newer alternative -- that translates the Next.js build output into Cloudflare Pages Functions / Workers. Because the underlying runtime is different from Node.js, some Node-specific APIs and npm packages that assume a full Node environment may not be available, even once the adapter is in place.

Railway / Render

Platforms like Railway and Render are closer to a general-purpose container or VM host than a framework-aware platform: they don't need a Next.js-specific adapter at all, because they'll happily run whatever you give them. The straightforward path is to deploy the same way as Self-Hosting -- next build and next start behind their process supervisor -- or hand them the same multi-stage Dockerfile used for any other container platform. Both approaches get the full feature set (ISR, Middleware, Server Actions) working correctly, since it's just a normal Node.js server with no reduced runtime to work around.

The Common Thread: OpenNext

A number of these adapters build on OpenNext, a community project that transforms a standard Next.js build into deployable artifacts for infrastructure Vercel doesn't own -- AWS Lambda, Cloudflare Workers, and others -- while trying to preserve as much of the ISR/Server Actions/Middleware behavior as that target runtime allows. It's worth checking before assuming a feature is simply unsupported on a given platform; the gap is often closed by an adapter rather than being a hard limitation of Next.js itself.