Oct 30, 2026Blog

Host Next.js without Vercel: how to choose

PRNext

You can host a Next.js application without Vercel. The choice depends mainly on the server features you need and the operational work you want to own.

A site exportable as static files, an authenticated SaaS product and an application regenerating pages on demand have different hosting contracts. Start with those needs before choosing a provider or changing frameworks.

List the features that must work after deployment

Identify request-rendered pages, actions, APIs, cookies, images and revalidation. Include long-lived connections, background work and storage needs. These determine constraints more reliably than the hosting provider’s name.

Separate the execution environment from platform integrations. Storage, authentication or a work queue can have their own contracts. Deploying pages does not automatically migrate those services.

Compare hosting models

These models help structure the decision. A container describes packaging and execution, and can run on a VPS or a managed platform. The options are not all mutually exclusive.

On small screens, scroll the table horizontally.

Architecture choices. Exact features depend on the release and platform.
Model	Fits when	Work to account for
Node server on a VPS	You want a persistent server process	Proxy, TLS, monitoring, updates and backups
Container	You want a reproducible release environment	Images, secrets, volumes and deployment lifecycle
Static export	Required pages and features are exportable	File hosting and any external services
Managed platform	You want to delegate part of operations	Limits, Next.js adaptation and usage-dependent cost

Choose a VPS when you want server control

Running a Node server is a self-hosting path documented by Next.js. You control the process, budget and reverse proxy. That control also means monitoring memory, errors, certificates and storage.

A standalone build can reduce deployment files through traced dependencies and a generated entrypoint. It does not remove the need for Node or determine application memory usage. Check the target system, native modules and static assets.

Deploy Next.js on a VPS behind a reverse proxy

Check whether static export is enough

If every required page can be generated at build time, static export can simplify operations. The host distributes generated files; features requiring request-time processing need another design or another service.

Review your version’s restrictions before choosing this mode. A cookie-dependent private page, a Server Action or a dynamic route unknown at build time does not become available on a file host. A form can call an external API, but that API remains a service to operate.

Evaluate managed hosting with a real journey

For managed hosting, check supported Next.js features, execution limits, cache behavior and regional restrictions. Deploy an example representing your application rather than only a homepage.

Compare compute, bandwidth, storage and the operational work you retain. Without traffic and peak information, claiming one model is always cheaper would be misleading. Check current prices and terms directly with the provider.

Place PRNext in this decision

PRNext is an experimental runtime for applications following Next.js conventions, with partial compatibility. You can evaluate it on your infrastructure. This changes the runtime and requires its own checks; self-hosting Next.js on a VPS can also retain Next.js.

PRNext Host is a separate managed service. Check its availability, terms and capabilities on its own page. To choose a runtime, start with your application’s functional requirements, then measure resources using the same workload.

Check the scope of a PRNext migration

Evaluate whether PRNext fits your application