Offshore Vue.js and Nuxt Hosting on Private VPS

Nuxt 3 built on Nitro server supports multiple deployment targets: node-server for self-hosted Node.js, static for pre-rendered output, and preset-specific builds for Vercel, Netlify, and other platforms. For offshore VPS deployment, use the node-server preset (default) which produces a standalone Node.js server in the .output/server directory that requires only Node.js to run.

Build for production: NITRO_PRESET=node-server nuxi build produces the .output directory containing the server code and prerendered pages. The server entry point is .output/server/index.mjs. Run it with node .output/server/index.mjs, managed by PM2. Unlike Vercel or Netlify deployments that run each Nuxt route as a separate serverless function, the self-hosted node-server runs as a single persistent process handling all routes - this allows in-memory caching, long-lived database connections, and server-side state.

PM2 configuration for Nuxt 3: create an ecosystem.config.cjs with the app module path pointing to .output/server/index.mjs. Set exec_mode to 'cluster' and instances to the CPU count for multi-core utilization. Nuxt 3's Nitro server is designed to run in cluster mode - each worker handles requests independently, and the framework's shared state (Nuxt's useState composable) operates per-worker rather than globally, which is correct behavior for server-rendered applications where per-request state isolation is required.

Nginx reverse proxy for Nuxt 3: identical to the Next.js configuration - proxy_pass to the Nitro server port, proxy_cache for static assets, and appropriate buffer settings. Nuxt 3's public/ directory contains static assets served directly by Nuxt's Nitro server, but you can configure Nginx to serve these files directly using an alias directive for the /_nuxt/ path, bypassing the Node.js process for asset requests. This is the same static file offloading pattern used for Next.js and has the same performance benefit.

Vue.js Single Page Applications built with Vite (vue-cli is deprecated as of 2024) produce a dist/ directory of static HTML, JavaScript, and CSS. Like React SPAs, these deploy on Nginx with no Node.js runtime required for the frontend. The VPS serves as a static file host, with any API backend running separately.

Vite build output: run npm run build (vite build) to produce the dist/ directory. Vite uses Rollup for bundling and produces hashed filenames for all chunks and assets, making them immutable and safe for long-term cache headers. The index.html in dist/ is the SPA entry point - it is not hashed and should not be cached long-term. Configure Nginx with Cache-Control: no-cache for /index.html and Cache-Control: max-age=31536000, immutable for /assets/* (Vite places all hashed assets in the assets subdirectory).

History mode routing for Vue Router: Vue Router's history mode uses the HTML5 History API to create clean URLs (/about instead of /#/about). Configure Nginx with try_files $uri $uri/ /index.html; to return index.html for all routes that do not match a static file, allowing Vue Router to handle client-side routing. Without this configuration, a user who bookmarks /about and navigates directly to it receives a 404 from Nginx.

For Vue applications with both frontend and API backend on the same VPS, configure Nginx location blocks to route API requests (/api/ prefix) to the backend process while serving the frontend SPA from the static file root. This eliminates cross-origin request complexity (both frontend and API are on the same domain) and keeps all traffic flowing through a single Nginx listener on ports 80 and 443.

Vue and Nuxt applications in specific categories particularly benefit from offshore hosting. Privacy-focused applications, independent content platforms, and applications serving audiences in countries with restrictive internet policies all gain measurable protection from offshore VPS hosting in Iceland or Romania.

Privacy tool frontends: Vue and Nuxt are commonly used for the web frontends of privacy tools - VPN management interfaces, encrypted storage UIs, private communication platforms. These applications are increasingly targeted for removal from US-based managed platforms due to regulatory pressure on privacy tool providers. Hosting the frontend on offshore VPS in Iceland provides the same IMMI legal protection as the backend infrastructure.

Independent media and journalism platforms: Nuxt's static site generation produces pre-rendered HTML that is fast to serve and easy to cache. Independent news sites, political publications, and content platforms that face platform risk from US-based hosting providers benefit from both the content freedom of offshore hosting and the performance of Nuxt's static generation with a fast NVMe-backed Nginx server.

Regional content for restricted audiences: applications serving users in countries where certain content types are regionally restricted (gambling platforms for markets where online gambling is legal, adult content for age-verified users in countries with different regulatory frameworks than the US) need hosting that does not bow to US regulatory pressure on these content categories. Offshore VPS with no US nexus provides this protection for Vue/Nuxt frontends as clearly as it does for any other application.

Developer tool frontends: security research tools, penetration testing interfaces, and privacy analysis tools with web frontends are routinely removed from US-based managed hosting platforms due to dual-use concerns. Offshore hosting for the frontend component of these tools keeps the interface available without the arbitrary content policy enforcement of US managed platforms. The offshore VPS does not make a content policy judgment about whether a security tool is legitimate research or misuse - that determination belongs to the legal framework of Iceland or Romania, not a US platform's policy team.

Nuxt 3 SSR performance on a VPS depends heavily on caching configuration. Server-side rendered pages that hit the database on every request do not scale beyond a small number of concurrent users without caching. Nuxt 3 provides multiple caching layers: Nitro's built-in route cache, Nuxt's useAsyncData composable with server-side caching, and external Redis caching for component-level or data-level cache.

Nitro route caching: configure route-level cache rules in nuxt.config.ts using routeRules. Static routes (pages that never change) can be pre-rendered at build time. Quasi-static routes (pages that change infrequently - category pages, author pages) can use stale-while-revalidate caching: serve the cached version immediately and revalidate in the background. Dynamic routes (user-specific pages, real-time data) should not be cached at the route level. This three-tier classification covers most Nuxt application page types.

Redis for Nuxt data caching: the nuxt-redis-cache community module or a custom useFetch wrapper with Redis storage enables fine-grained data caching below the route level. Cache expensive database queries (product lists, article indexes, tag aggregations) in Redis with appropriate TTLs. Monitor Redis hit rates via redis-cli info stats and adjust TTLs based on how frequently the underlying data changes. A well-tuned Redis cache reduces database queries per page by 70-90% for content-heavy Nuxt applications.

Nginx micro-caching: for anonymous traffic (users not logged in, no personalized content), configure Nginx's proxy_cache with a short TTL (10-60 seconds). Nginx micro-caching serves the same Nuxt-rendered HTML to all concurrent anonymous visitors without hitting the Node.js process for each request. This scales anonymous visitor capacity by 10-50x on a given VPS configuration, making it practical to handle traffic spikes from social media links or search ranking improvements without server crashes.