Deploy a Nuxt Application on a VPS

With Nitro, Nuxt generates a portable build (preset: node-server) that starts as a simple Node server listening on a port. This portability is ideal for a VPS: you benefit from server-side rendering, server/api routes, and route caching without depending on a proprietary edge runtime.

Self-hosting removes function quotas and lets you tune caching, compression, and the number of Node instances. For a production Vue 3 application with authentication, server API calls, and careful SEO, the VPS offers the stability of a persistent server and a fixed cost, with no per-invocation billing surprises.

You still need a server that accepts a permanent Node.js process: most shared hosting does not allow it, which rules out SSR and server routes from the start. On a VPS you also choose the Node.js version, the reverse proxy (Nginx or Caddy) and how TLS certificates are managed, with no artificial cap on CPU or memory.

As with any modern framework, the Nuxt build consumes memory: aim for at least 2 GB of RAM (the build can be done in CI if your VPS is more modest). At runtime, 1 vCPU and 1 GB are enough for the Nitro server under light load; move up to 2 vCPU / 2 GB for applications with many simultaneous server/api routes, and to 2 vCPU / 4 GB if several Nuxt applications share the VPS.

On the version side, start from Nuxt 4: Nuxt 3 reached end of life on 31 July 2026 and no longer receives bug fixes or security patches. The deployment described here is the same for both versions, since Nitro is what produces the server. Install a Node.js LTS line that is still maintained, Node.js 24 or 26 (Node.js 20 has been end-of-life since 30 April 2026), via nvm or a node:24-alpine image, along with PM2 for process supervision. node-server is the preset Nitro applies by default to a production build: declaring it in nuxt.config.ts simply makes it explicit. A domain pointing to your VPS is required for the TLS certificate. Ubuntu 22.04 or 24.04 LTS remains the recommended base.

The Nuxt Stack template in the ServOrbit Marketplace prepares an Ubuntu 24.04 VPS with Node.js on the current LTS line of the NodeSource repository, PM2 installed globally, Nginx and PostgreSQL. It saves you installing the runtime: the steps below then start at the project configuration.

It is a runtime environment, not an application with a login screen: you get in over SSH (ssh root@<vps-ip>) to upload your code. On first access, Nginx serves its default page on port 80; your application's virtual host, the Let's Encrypt certificate (Certbot is not preinstalled) and your code are still to be set up. PostgreSQL listens only locally, with peer authentication for the postgres system user (sudo -u postgres psql): enough to plug a DATABASE_URL into 127.0.0.1 without exposing the database.

Nuxt organizes its runtime configuration on two levels. Keys placed under runtimeConfig.public are sent to the browser and remain readable on the server: public API URL, analytics identifier. The other runtimeConfig keys never leave the server: secret keys, database access.

At startup, an environment variable overrides the matching key if it follows the NUXT_<NAME> convention, or NUXT_PUBLIC_<NAME> for a public key: NUXT_PUBLIC_API_BASE replaces runtimeConfig.public.apiBase. A value read elsewhere, for example process.env.OTHER_VARIABLE written in nuxt.config.ts, is only picked up at build time and stays frozen in the artifact.

In practice, changing an API URL or a key therefore does not require a rebuild: you edit the .env on the server, then reload PM2 (pm2 reload nuxt-app). The same .output folder can thus serve staging and production with two different environment files. The only condition is to have the process load that file, since Nuxt no longer reads .env once the application is built — hence the --env-file option passed to Node when starting with PM2.

One of Nuxt's strengths on a VPS is the granularity of per-page rendering strategies, without changing infrastructure. In nuxt.config.ts, routeRules allow you to mix SSR, SSG, ISR, and SWR on a single Nitro deployment.

Static pages (blog, legal notices, landing pages) can be pre-generated at build time with prerender: true: Nitro serves them from disk, without Node. Semi-dynamic pages (product listings, public dashboards) benefit from swr: 60 for a one-minute cache invalidated in the background. Full SSR remains reserved for personalized pages that depend on session or user profile.

This approach reduces the load on Node without requiring a paid CDN or an external cache layer — your Nginx caches what Nitro pre-generates.

PM2 centralizes the application's output: pm2 logs nuxt-app follows the live stream (standard output and errors), and pm2 logs nuxt-app --lines 100 shows the latest lines. The files are written to ~/.pm2/logs/, one -out.log and one -error.log per application, suffixed with the instance number in cluster mode.

These files do not rotate on their own. The pm2-logrotate module rotates them past 10 MB and keeps 30 by default; adjust these thresholds to the size of your disk:

pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7

When the browser gets a 502 or a 504, look at Nginx first: /var/log/nginx/error.log tells you whether it could not reach 127.0.0.1:3000 (process stopped, wrong port) or whether Nitro took too long to respond.

Error: listen EADDRINUSE: address already in use :::3000
A process is already holding port 3000. Identify it with ss -tlnp | grep 3000 and stop the orphaned PM2 instance: pm2 delete nuxt-app followed by a clean restart. Avoid running multiple instances without a load balancer — configure PM2's cluster_mode instead.

502 Bad Gateway in Nginx
Nitro is not started or is listening on the wrong port. Check pm2 status and review the logs: pm2 logs nuxt-app --lines 50. Also verify that the proxy_pass directive in Nginx points to http://127.0.0.1:3000 (not localhost which may resolve to IPv6 if the process only listens on IPv4).

useRuntimeConfig() returns undefined
NUXT_* variables are only read when the Nitro process starts: after changing .env, reload with pm2 reload nuxt-app. Check that the file is actually loaded through --node-args="--env-file=…" rather than exported in the current shell, which disappears with the SSH session. If the value is missing in the browser only, the key must be declared under runtimeConfig.public and the variable prefixed NUXT_PUBLIC_.

server/api routes return 404 in production
Check that your build includes the server/ folder in .output. A misconfigured nitro.preset (for example static instead of node-server) generates a static site without a server. Rebuild with npm run build after verifying nuxt.config.ts.

X-Forwarded-Proto ignored, redirect loop
If Nuxt redirects HTTP → HTTPS in a loop, it means the redirect middleware sees http despite the client-side HTTPS. Make sure Nginx forwards proxy_set_header X-Forwarded-Proto $scheme and that your nuxt.config.ts does not force HTTPS redirect twice alongside Certbot.