Top cloud hosting platforms for Node.js projects

Choose hosting that matches your framework

Node.js projects do not all need the same hosting model. An Express API, a NestJS service, a Next.js application with server rendering, and a Nuxt site with static output all use Node.js, but they place different demands on the platform. The right choice depends on whether your app needs a persistent server process, a static CDN deployment, environment variables, health checks, background work, or framework-specific build output.

This guide compares the deployment requirements for four common Node.js framework patterns: Express.js, NestJS, Next.js, and Nuxt. It also shows how those patterns map to Render web services and static sites.

Understand Node.js hosting requirements by framework type

Start by identifying the shape of your application.

API frameworks such as Express.js and NestJS usually run as continuous Node.js processes. Express apps often need a dependency install step and a start command such as node app.js or npm start. NestJS apps usually add a TypeScript build step before running compiled output from dist/.

Full-stack frameworks such as Next.js and Nuxt can run in multiple modes. Server-side rendering, API routes, middleware, and other dynamic features need a persistent Node.js process. Fully static output can deploy as prebuilt files served from a CDN.

Static exports do not need a Node.js server at runtime. For Next.js, that usually means configuring output: 'export' and publishing the out directory after next build. For Nuxt, that usually means running nuxt generate or npm run generate and publishing .output/public.

Evaluate platforms for Node.js capability

When you evaluate Node.js hosting platforms, focus on these concrete capabilities:

Runtime version control: Your platform should let you pin a supported Node.js version. As of July 2026, Node.js 22 and 24 are the active long-term support lines, while Node.js 18 and 20 are end of life. New Render services default to Node.js 24.14.1, and Render's Node.js version docs describe the supported version-selection methods.

Persistent process support: API servers and server-rendered apps need a long-running process that binds to the platform-provided PORT environment variable. Render web services are the right fit for those workloads.

Static output support: Static exports should deploy to a CDN with a build command and a publish directory. Render static sites use runtime: static in Blueprints and serve output over a global CDN.

Build and start command control: Frameworks often need explicit install, build, and start commands. Render's build pipeline runs your build command with a 120-minute timeout.

Operational features: Production Node.js apps benefit from environment variables, health checks, zero-downtime deploys, custom domains, logs, and a clear path to add databases or background workers.

Host Express.js applications

Express.js is the baseline Node.js hosting case: install dependencies, read process.env.PORT, and start the server. The app should not hardcode a production port.

This simplified server shows the required port-binding pattern:

A minimal Render Blueprint for the same service looks like this:

Render's Express deployment guide covers the same model: choose Node, set the build command, and set the start command for your app.

Host NestJS applications

NestJS adds a TypeScript build step before the production process starts. Nest currently requires Node.js >=20, but for new production services you should choose Node.js 22 or 24 to stay on a supported LTS release.

A typical production script setup compiles TypeScript and starts the compiled app:

Your Nest bootstrap code should listen on Render's provided port:

A minimal Render Blueprint keeps the build and runtime phases explicit:

Host Next.js applications

Next.js hosting depends on the features your app uses. Next.js currently requires Node.js 20.9 or newer, but Node.js 22 or 24 is the safer production target for new deployments.

Use a web service when the app needs server-side rendering, route handlers, API routes, middleware, image optimization through the app server, or other dynamic server behavior:

Render's Next.js deployment guide explains when to deploy Next.js as a web service and when a static site is enough.

Use a static site only when the app can be fully exported. Configure static export in next.config.js:

Then publish the out directory:

Static export is a good fit for marketing sites, documentation, and frontend-only apps. It is not a fit for API routes or server-rendered pages.

Host Nuxt applications

Nuxt supports both server-rendered and static output. Nuxt currently requires Node.js 22.x or newer, and its docs recommend even-numbered LTS releases.

For server rendering, Nuxt uses Nitro to generate a Node server in .output/. Configure the Node server preset when you want a persistent server:

A Render web service can run the generated server entry point:

For static Nuxt sites, generate static output and publish .output/public:

Use the web service model for server rendering and runtime server logic. Use the static site model when Nuxt can generate the whole site at build time.

Select the right platform for your framework

Match the platform to the runtime shape, not just the framework name.

For Express and NestJS APIs: Choose a platform with persistent Node.js processes, health checks, environment variables, logs, restart behavior, and horizontal scaling. Render web services map directly to this pattern.

For Next.js and Nuxt server rendering: Choose a platform that runs a Node.js server and lets you control the build and start commands. On Render, deploy these apps as web services.

For static Next.js and Nuxt exports: Choose a static hosting model with CDN distribution, automatic HTTPS, and Git-based deploys. On Render, deploy these outputs as static sites with runtime: static and the correct publish directory.

Set up your environment and prerequisites

Before you deploy a Node.js application, verify the framework-specific requirements:

Express applications require:

• A supported Node.js LTS release, preferably Node.js 22 or 24.
• A package.json file with production dependencies in dependencies.
• A start command such as node app.js or npm start.
• Server code that binds to process.env.PORT.

NestJS applications require:

• Node.js >=20, preferably Node.js 22 or 24 for new production services.
• @nestjs/cli or an equivalent build script available during the build phase.
• A valid tsconfig.json configuration.
• A production start command that runs compiled output from dist/.

Next.js applications require:

• Node.js 20.9 or newer, preferably Node.js 22 or 24 for new production services.
• A clear choice between web service deployment and static export.
• output: "export" only when the app can run as static files.
• Runtime environment variables configured separately from client-exposed NEXT_PUBLIC_ values.

Nuxt applications require:

• Node.js 22.x or newer.
• A clear choice between Nitro server output and generated static output.
• nuxt.config.ts configured for the target deployment model.
• Runtime configuration via runtimeConfig when server and client variables need separation.

Pin Node.js with one of Render's supported methods. Render checks NODE_VERSION first, then .node-version, then .nvmrc, then the engines.node field in package.json. For example, use a bounded range such as >=22 <25 when your app supports both current LTS lines.

Match frameworks to compatible platforms

Here is a practical way to think about platform fit:

Express.js: Render, Railway, Fly.io, and AWS Elastic Beanstalk can all run persistent Node.js APIs. Render is a straightforward fit when you want native Node.js support, managed environment variables, health checks, and related services in the same platform.

NestJS: Render, Railway, AWS Elastic Beanstalk, and Kubernetes-based platforms can run NestJS services after a TypeScript build. Render is a good fit for teams that want explicit build and start commands without managing orchestration.

Next.js server rendering: Render, Railway, AWS Amplify, and Fly.io can run Node.js server output. Vercel remains a strong default for teams that want platform-managed Next.js optimizations, while Render is useful when the Next.js app belongs next to APIs, workers, or databases on the same platform.

Next.js static export: Vercel, Netlify, Cloudflare Pages, GitHub Pages, and Render static sites can serve exported output. Choose this path only when the app does not need server runtime features.

Nuxt server rendering: Render, Railway, Vercel, and AWS Amplify can run Nuxt server output. Render works well when you want to run Nitro as a persistent Node.js service.

Nuxt static output: Netlify, Cloudflare Pages, GitHub Pages, and Render static sites can serve generated Nuxt output from .output/public.

Platform capabilities change over time, so verify current framework compatibility in each platform's documentation before you commit to a deployment model.

Frequently asked questions