Choosing hosting for Next.js or Nuxt starts with where each page is rendered and where its data is authorized and processed. A public product page may be generated in advance while the account area requests user-specific data. Those paths can have very different resource needs even when they belong to the same application.
This guide turns rendering choices into a hosting topology: static delivery, a single application server, a separate database, and multiple application instances. It also shows what to measure before choosing a VPS or dedicated server. The scenarios are planning patterns; they are not customer benchmarks or capacity guarantees.
Separate rendering from the execution platform
SSR, SSG and CSR describe when and where content is rendered. Edge describes an execution or deployment environment. Serverless describes an operating model and does not automatically mean execution near every visitor. A regional function can serve SSR, while a CDN can distribute static files without running application code.
| Choice | When content is produced | Hosting responsibility |
|---|---|---|
| Static export | HTML and client assets generated at build time | Serve files; host any separate API independently |
| Request-time SSR | The server renders requests not satisfied by a suitable cache | Run a compatible server or deployment adapter |
| CSR | The browser renders the relevant interface | Serve the client and provide an authorized API where required |
| Runtime regeneration | Cached pages are refreshed under defined conditions | Provide a runtime and consistent cache for regeneration |
| Edge execution | Selected logic executes in the supported platform location | Validate runtime, adapter, data access and platform limits |
For each route, record whether it is public or authenticated, its acceptable content age, and the API or database it uses. Separate the initial HTML request from client navigation and later data requests. A static dashboard shell can fetch private data from an API that enforces authorization; private data does not by itself make SSR mandatory.
For public pages that need search visibility, also check whether the initial HTML contains the substantive content. Prerendered HTML and an empty shell populated by client-side JavaScript are not equivalent outputs. For example, choosing client-only rendering in Nuxt makes the interface depend on JavaScript and can reduce the SEO benefits of prerendering. Neither SSR nor static generation alone guarantees rankings.
In Next.js, getServerSideProps, getStaticProps and getStaticPaths are Pages Router APIs. An App Router Server Component is not automatically rendered on every request: suitable components run during the build for a static export. Nuxt universal rendering can also return prerendered or cached HTML. Do not assign every request the same CPU cost simply because the application uses Next.js or Nuxt.
Static export, SSR and ISR need different deployment outputs
What a static origin actually serves
A full static export produces HTML, JavaScript, CSS and assets. Shared hosting, a web server on a VPS, or a suitable object-storage origin can deliver those files. The host still needs the right URL-to-file mapping, HTTPS, error responses and headers. Uploading a directory is one deployment step, not proof that every deep link, asset and status code works.
For Next.js 16, output: 'export' with next build produces out/ by default. The old next build && next export sequence is historical: next export was removed in Next.js 14. Nuxt 4 static generation uses nuxt generate and publishes .output/public; do not assume an older dist/ instruction matches a current project. These are version boundaries to check against the installed framework and its configuration.
The static site may still call a search, form, checkout or account API. That service retains its own cost, runtime and availability requirements. Content fetched from a CMS during the build can remain unchanged until a new build is deployed. The object storage origin guide and static hosting guide cover the delivery side of this split.
The server side of SSR
In a Node deployment, a reverse proxy forwards application requests to the framework server. The server fetches required data and returns HTML or a streamed response. Static assets and eligible cached responses can follow other paths. Neither an asset request nor a cache hit necessarily performs a fresh render or repeats a database query.
A conventional Next.js server can run with next start after a server build; other supported output modes use their own entry points. A Nuxt 4 Node-server build uses Nitro and its .output/server/index.mjs entry point. A static export has no such production framework server. Keep the selected output and the process you intend to supervise consistent.
When self-hosting, you own runtime updates, process supervision, logs and release management. A VPS or dedicated server is an option, but SSR does not universally require one: compatible managed platforms and some Node-enabled shared environments can also work. Check the Node version, process lifetime, limits, routing and supported framework features. Our Node.js hosting guide provides more context for evaluating those requirements.
Runtime regeneration is not file-only hosting
Next.js ISR requires a supported runtime and cache. In the Next.js 16 documentation, ISR uses the Node.js runtime and is not supported with static export or the Next.js Edge Runtime. Copying out/ to a file server does not enable ISR. For Nuxt 4, nuxt generate produces no server endpoints; runtime hybrid rendering and Nitro swr or platform-dependent isr behavior belong to an appropriate server deployment.
A revalidate interval is not a promise that all users receive new content at the exact second it expires. A request may trigger regeneration, the old response can still be served, and upstream failures can delay a successful update. Next.js can retain the last successful result after regeneration fails. Treat the maximum acceptable age of a page separately from the transaction API’s duty to verify current prices, stock and authorization.
Hybrid rendering can reduce repeated rendering when cacheable content is reused, but it adds refresh and invalidation work. Estimate that work explicitly. It is misleading to group ISR with file-only export and describe both as having almost no runtime CPU cost.
Topology one: a single server with measurable limits
A simple Node topology can place the reverse proxy, application and a small database on one VPS. This reduces the number of operating components. It also makes them compete for memory and disk, and a failure of that host affects all those roles. It is a candidate design to test, not a general answer for every small application.
- The reverse proxy terminates TLS and routes requests to the application or static files. Configure streaming and buffering deliberately when the application depends on streamed responses.
- A process manager such as PM2 or
systemdcan supervise the application. Restarting a process is not the same as verifying that the application is healthy. - Choose worker count with CPU, memory per process and database connection pools in mind. A fixed two-to-four-worker rule is not a capacity calculation.
- Build in CI or a separate environment where practical. If builds run on the serving host, reserve resources for build peaks as well as ongoing requests.
- Define backup and restore procedures that still work when the original host is unavailable.
The useful limit is the load at which the system still meets its response-time and error targets. “Thousands of daily visitors” does not describe burst rate, cache effectiveness, expensive routes or open connections. A recommendation such as 2–4 vCPUs and 4–8 GB RAM needs a specific workload and measurements before it becomes a defensible sizing decision.
Topology two: separate the application and database
Separation can help when the database competes with the application for memory or I/O, requires a different maintenance schedule, or needs a different failure boundary. It is not automatically the first upgrade every growing site needs. Investigate slow queries, missing indexes, repeated calls and connection-pool exhaustion before adding another machine.
- Measure application-to-database latency and transfer. Moving a database farther away can make SSR slower even when the new database host has more resources.
- Budget connections across every worker and application instance. More application processes can exhaust the same database limit.
- Restrict database access to the required application sources and define transport protection, backups and recovery ownership.
- Add Redis, Memcached or another cache when it addresses a measured query or computation cost. Decide whether it stores disposable cached data or state that requires durability.
A headless WordPress and Next.js architecture also separates the frontend from a content API. CMS editing, bulk content reads during a build and visitor API traffic are different workloads. They may peak at different times; averaging them together can obscure the bottleneck.
Role separation makes independent sizing possible, but introduces a network dependency and another service to monitor. A database replica also needs explicit read-routing and replication-lag decisions; creating a replica alone does not make application writes faster or provide a tested failover process.
Topology three: multiple application instances
Multiple instances behind a load balancer can serve increased load and allow traffic to move during maintenance. They do not automatically make the database, cache or load balancer highly available. Identify shared dependencies and test what happens when one component is unavailable.
- Deploy the same release/build output to all instances. Avoid serving HTML and client assets from incompatible builds.
- Decide what happens to sessions and other state when a request reaches another process. In-memory state local to one process is not shared simply because a load balancer exists.
- Next.js instances do not share their default local cache. Choose an appropriate supported cache handler and invalidation design for ISR/Data Cache. Installing Redis does not automatically wire it into Next.js.
- Verify the storage and adapter behavior of the selected Nuxt/Nitro deployment separately. A Next.js cache setting is not a Nuxt configuration instruction.
- Use health checks, remove an instance from new traffic before stopping it, and account for pending requests and background work.
Do not place authenticated account, cart or other user-specific responses in a public CDN or micro-cache. Review cache keys, cookies, Authorization handling and private/no-store directives together. Public responses may still vary by language, currency or experiment. A fast response for the wrong user or variant is a correctness failure.
For self-hosted Next.js, the official guide also calls out streaming through a reverse proxy, consistent builds and version skew. These are operational contracts to validate across the full path. A working local process does not prove that a production CDN and reverse proxy preserve the same behavior.
Size the workload, not the visitor count
Start with route groups and acceptance targets. Separate anonymous cached pages from authenticated reports. Record cache hits and misses; the same URL can create very different origin work in those states. Include client navigation and background API requests instead of counting only initial document requests.
| Measure | Decision it informs |
|---|---|
| Requests per second by route and cache state | Actual work reaching the origin |
| p50/p95/p99 latency and error rate | Slow-tail behavior hidden by averages |
| CPU, event-loop delay and memory per worker | Compute, blocking and process-count constraints |
| Database query latency, connections and I/O | Dependency bottlenecks and resource contention |
| Build duration and peak memory | Separate release-pipeline resource requirements |
| Open connections and reconnection traffic | Connection lifetime and deployment behavior |
Use representative data and user flows in a separate test environment. Exercise warm cache, cold cache, one unavailable instance and a slow dependency as separate scenarios. Track successful user operations as well as request throughput. This article supplies no measured throughput for a particular VPS plan.
Adding workers cannot fix every source of waiting. CPU-bound work, blocked event loops, slow database queries and memory growth call for different changes. Correlate application traces, reverse-proxy timings and database metrics on the same timeline. Then add capacity headroom for explicitly named failure or campaign scenarios.
For a repeatable result, record the framework and Node versions, build identifier, route mix, test duration, cache state, machine resources and dependency placement. Keep the test generator separate from the system being measured where possible. A number without those conditions is hard to compare with the next release.
The VPS sizing guide for WooCommerce, Laravel and Node.js and resource monitoring guide give related operating context. Use those methods to investigate the observed bottleneck rather than treating a generic package size as a benchmark.
Evaluate CDN and edge execution along the data path
A CDN can satisfy eligible static or public responses without reaching the origin. That can reduce origin work. It does not make LCP depend only on network distance: image size, JavaScript, hydration, device performance and data calls also matter. Core Web Vitals are LCP, INP and CLS; TTFB is a useful diagnostic metric, not one of that trio. The hosting-side Core Web Vitals guide develops these distinctions.
Code near the user may still be far from the data. An edge function that calls a distant origin on every request can add a network hop. Measure target regions, origin calls, cache reuse and dependency latency before claiming a lower TTFB or reducing origin capacity. Not every request is necessarily served from the geographically closest location.
The Next.js Edge Runtime exposes a subset of Node.js APIs and does not support Next.js ISR. Nuxt uses a Nitro preset appropriate to its target. A framework middleware or proxy file on one host does not itself create a global edge network. Verify package compatibility, execution limits, outbound networking and connection lifetime for the exact adapter and platform.
Long-lived connections are another platform capability to check; there is no universal WebSocket ban for serverless or edge. The deployment must support the required server-side upgrade and connection behavior, not merely expose a WebSocket client API. The separate real-time service can remain on an origin or use a compatible provider.
The Cloudflare Workers and BunnyCDN edge-logic guide describes related delivery choices. Select only the logic that benefits from the measured placement and keep authorization consistent with the protected origin. An early edge check does not excuse an API from enforcing its own access rules.
Include build, release and rollback in the architecture
Build a distinct release and validate configuration for development, staging and production. For static delivery, publish HTML and hashed assets as a coherent release. Removing old assets immediately can break a page that a visitor opened before deployment. Decide how long earlier assets remain available and how HTML caches move to the new release.
For SSR, make the new instance healthy before sending it traffic, drain the old instance, and allow pending work to finish within the defined shutdown policy. Database migrations need compatibility with the application versions that can run during rollout and rollback. A PM2 reload, symlink swap or CI pipeline alone does not prove error-free deployment.
The GitHub Actions deployment guide for PHP and Node.js and Git deployment workflows for cPanel, Plesk and VPS provide implementation context. Test the selected release strategy through the actual reverse proxy and CDN. Include open browser sessions, client navigation, background jobs and long connections in the acceptance plan.
Log application errors, HTTP status codes and dependency latency without storing session tokens or unnecessary personal data. Correlate requests across layers. Alert on user-visible failures and latency as well as machine usage, and name the person responsible for rollback and restore. The VPS hardening guide covers complementary host controls.
Compare cost and project needs without a fixed upgrade ladder
Static delivery has storage, request, transfer, build and possibly separate API costs. SSR adds runtime capacity, operations and dependency costs. Serverless or edge plans may charge for requests, execution and transfer, with provider-specific allowances and limits. A CDN can reduce some origin work while adding its own bill. Compare the complete service path over the expected traffic profile.
Dedicated servers or colocation may suit sustained workloads, equipment requirements or operating preferences. They are not an inevitable next step after a particular daily-page-view number. Physical isolation does not eliminate application faults, network limits or shared dependencies. The hosting cost right-sizing guide provides a useful framework for comparing the full operating cost.
- For a content site, weigh build duration and acceptable publication delay.
- For a SaaS dashboard, define the authenticated API and session behavior; CSR can be a deliberate choice.
- For commerce, separate public catalog caching from current transaction validation and personal responses.
- For real-time features, specify connection lifetime, message authorization, state sharing and reconnect behavior.
- For a global audience, measure the user-to-compute and compute-to-data paths separately.
These examples do not require every blog to be static, every checkout to use SSR or every international site to use edge. The WordPress scaling roadmap illustrates a related principle of staged capacity decisions, but framework-specific cache and deployment contracts still need their own validation.
Produce a route map, a topology and an acceptance plan
- Record rendering, data source, authorization and freshness requirements for each route group.
- Place static delivery, application runtime and APIs/databases in a topology with explicit network paths.
- Define acceptable latency, errors and representative load; measure the limiting resource.
- Document shared caches, releases, rollback and restore responsibilities.
- Check that the selected DCHost or other hosting product actually supplies the required runtime features and resources.
The outcome is a short operating record explaining where each job runs and how adequacy will be measured. Revisit it when traffic, framework versions, content publishing or dependencies change. That makes later decisions about capacity, role separation or edge execution traceable to the application’s needs.
