Next.js or Nuxt on Your Own VPS: What to Watch for When Self-Hosting

You describe an app idea to an AI tool. Shortly afterwards you have a working project: Next.js, App Router, TypeScript, Tailwind. Now you want to put it on your own server, and the deployment side deserves a closer look.

The React docs list Next.js (App Router) as the first recommended full-stack framework for new React apps (react.dev, as of Nov 8, 2026). For a project on your own VPS, that brings its own tasks.

This article explains what they are and how Nuxt differs when self-hosting.

Two routers in one framework

Next.js has two routing systems: the Pages Router and the App Router. The app directory can exist next to the pages directory. The Pages Router uses getServerSideProps and getStaticProps for data; in the app directory, a new data-fetching API replaces these functions (Next.js docs, as of Nov 8, 2026).

For AI-generated code this means: check whether getServerSideProps or getStaticProps still appear in the app directory. Those functions no longer exist there.

If you chose vibe coding to move fast, this check is worth doing right at the start.

React Server Components: the invisible mental model

The App Router is built on React Server Components (RSC). Pages in the app directory are Server Components by default; you mark a Client Component with "use client" (react.dev, as of Nov 8, 2026). That sounds simple, but in practice it has consequences.

You cannot pass ordinary functions as props to Client Components, but Server Functions you can; event handlers belong in Client Components (react.dev, as of Nov 8, 2026). If an AI-generated Server Component uses useState, Next.js reports this with its own error and a pointer to 'use client' (Next.js docs, as of Nov 8, 2026).

Help starts in the editor: the Next.js TypeScript plugin warns about a misplaced 'use client' and about client hooks in Server Components (Next.js docs, as of Nov 8, 2026). You still have to keep the boundary between server and browser in your head.

Several rendering strategies per route

Next.js renders routes statically or dynamically, with ISR or with Partial Prerendering (PPR), and the strategy can differ per route. For experienced teams that is flexible. With AI-generated projects, you as the reviewer have to work out which strategy was chosen and whether it fits your deployment.

On a VPS it looks like this (Next.js docs, as of Nov 8, 2026; sources in the paragraph below):

Sources: self-hosting guide, output, cacheComponents, Edge Runtime (all Next.js docs, as of Nov 8, 2026).

Two caching models

Next.js has two caching models: Cache Components with 'use cache' and the earlier model, which the docs list as the "Previous Model" (Next.js docs, as of Nov 8, 2026). If you generate code with an AI tool, check it against the installed version and its docs.

When self-hosted, the cache lives on the local filesystem of each Next.js instance. If you start a second instance, for redundancy for example, each serves its own cache, and a revalidateTag only affects one of them. The fix is a custom cacheHandler with a shared store such as Redis; with several instances you also set NEXT_SERVER_ACTIONS_ENCRYPTION_KEY and deploymentId (Next.js docs, as of Nov 8, 2026). On Vercel the deployment runs without configuration, and ISR pages are stored durably there (Vercel docs, as of Nov 8, 2026).

Self-hosting and Vercel

Next.js is maintained by Vercel (Vercel docs, as of Nov 8, 2026). Image optimization, proxy and ISR work with next start without extra configuration; individual features need their own settings when self-hosting (Next.js docs, as of Nov 8, 2026).

next/image optimizes images on your server. On glibc Linux, extra configuration against high memory use may be needed; alternatives are a custom loader or unoptimized (Next.js docs, as of Nov 8, 2026). With output: 'standalone', check whether sharp is in the output; the docs show outputFileTracingIncludes for this (Next.js docs, as of Nov 8, 2026).

ISR behind a CDN: If you put a CDN in front, check whether it respects the Cache-Control headers from Next.js (Next.js docs, as of Nov 8, 2026). Cloudflare, for example, supports stale-while-revalidate (Cloudflare docs, as of Nov 8, 2026).

Proxy (formerly middleware) runs in the Node.js runtime by default since version 16 and works with a Node.js server and Docker (Next.js docs, as of Nov 8, 2026).

None of these points is a bug in Next.js. Some features need their own settings when self-hosting, such as a cache handler with several instances or streaming behind nginx.

What this means for AI-generated projects

You chose vibe coding to get a result fast. The AI generates a Next.js project, and it compiles. Before deploying, it pays to check against the Next.js self-hosting docs.

Checks before deployment (sources as in the sections above):

• sharp is in the build output if you use output: 'standalone'
• a shared cache handler with several instances
• no runtime = 'edge' exports you do not need on the VPS
• no Pages Router functions in the app directory
• buffering turned off in nginx for streaming

Nuxt: a Node server by default

Nuxt is a full-stack framework for Vue. Its server engine Nitro produces output for various hosting providers from the same codebase; the default for production builds is a Node.js server (Nitro docs, as of Nov 8, 2026). nuxt build creates an .output folder that you start like this (Nuxt docs, as of Nov 8, 2026):

NODE_ENV=production node .output/server/index.mjs

The server runs behind nginx like any Node app and reads port and host from PORT and HOST; for several cores the docs name PM2 or the node_cluster preset (Nuxt docs, as of Nov 8, 2026).

Rendering per route in one place. The default is universal rendering; you set other strategies such as SPA, prerendering, swr or isr per route centrally in routeRules (Nuxt docs, as of Nov 8, 2026).

Route caching bundled. The rules sit in one block in nuxt.config.ts. The Nitro cache lives in the memory of the process by default; for several instances you need a shared store such as Redis (Nitro docs, as of Nov 8, 2026):

export default defineNuxtConfig({
  routeRules: {
    '/':            { prerender: true },   // static at build time
    '/products/**': { swr: 600 },          // cached, regenerated in the background after 600 s
    '/admin/**':    { ssr: false }         // client-only SPA
  }
})

Presets. Nitro ships presets for Node.js and many hosting providers; the default is the Node.js server (node_server), which also runs in a Docker container (Nitro docs, as of Nov 8, 2026).

Comparison table

Table as of Nov 8, 2026, sources in the sections above (Next.js, Nuxt and Nitro docs).

The IPX detail comes from the module docs (Nuxt Image docs, as of Nov 8, 2026).

Which VPS fits your project

The framework calculator estimates the resources your project needs. Current prices per RAM tier are in the VPS comparison.

If you run several apps on one server, add up their memory needs. Each in-memory cache needs room.

For the typical vibe-coding case (one app, one server, one developer): start with the RAM tier the framework calculator suggests and scale up as traffic grows; prices per tier are in the VPS comparison.

Not just Nuxt: other frameworks for self-hosting

Nuxt is not the only alternative. Depending on the project type there are further options:

Astro for content sites such as blogs, docs and marketing: no client-side JavaScript by default (Astro docs, as of Nov 8, 2026), SSR via the @astrojs/node adapter in standalone or middleware mode (Astro docs, as of Nov 8, 2026).

SvelteKit creates a standalone Node server with adapter-node, started with node build, port and host via PORT/HOST (SvelteKit docs, as of Nov 8, 2026).

React Router v7 is what was planned as Remix v3 (Remix blog, as of Nov 8, 2026), and it is listed among the recommended frameworks in the React docs (react.dev, as of Nov 8, 2026).

Which framework fits depends on the project; for Nuxt, SvelteKit and Astro the respective docs describe a Node server of its own.

When Next.js is still the right choice

This article is about one particular situation: an AI-generated project you want to host on your own server.

If you deploy on Vercel and want to stay there, Next.js is an obvious choice. On Vercel, Next.js runs without configuration, image optimization does too, and ISR pages are stored durably (Vercel docs, as of Nov 8, 2026).

If your team knows Next.js and makes the architecture decisions deliberately (App Router, which caching model, how ISR works with several instances), that is an informed choice. This article is aimed at people who did not make these decisions themselves because the AI made them.

Conclusion

Nuxt bundles rendering and cache rules per route in routeRules and builds a Node server by default. With Next.js, the self-hosting effort depends on which features your code uses.

Before choosing, check which features your project needs and how the respective docs describe them for self-hosting.

Which VPS you need depends on framework and traffic. The framework calculator estimates the resources, the VPS comparison shows current prices, sorted by price.