Offshore React and Next.js Hosting on VPS

Next.js is designed to run on Vercel, but it also runs excellently on any Node.js VPS as a self-hosted application. Self-hosted Next.js provides capabilities that Vercel's managed platform restricts: custom server middleware, long-running processes, access to the underlying OS, and full control over the deployment pipeline without Vercel's build and bandwidth pricing.

Self-hosted deployment: on a Debian 12 VPS, install Node.js 22 LTS from NodeSource, clone your Next.js project, run npm install and npm run build to compile the application. Run the production server with node server.js or next start, managed by PM2 for process management, crash recovery, and clustering. PM2 cluster mode with multiple instances provides horizontal scaling across all available CPU cores for CPU-bound SSR rendering.

Nginx reverse proxy: configure Nginx to proxy requests to the Next.js server on port 3000 (or your configured port). Next.js serves its own /static/ and /_next/ asset paths - configure Nginx with proxy_cache for these paths to cache Next.js static assets at the Nginx layer, dramatically reducing Node.js load for asset requests. The _next/static/ path contains hashed, immutable assets that can be cached for long periods (cache-control: max-age=31536000, immutable).

Environment variables for Next.js on VPS: server-side environment variables in .env.production are available to Next.js API routes and server components. Client-side variables must be prefixed NEXT_PUBLIC_ and are embedded in the built bundle at build time. Store sensitive server-side variables (API keys, database credentials, JWT secrets) in the .env.production file with 600 permissions on the VPS, not in the repository. Never prefix secrets with NEXT_PUBLIC_ - they will be visible in the browser.

Static export: for Next.js projects that can be fully statically generated (no dynamic server-side rendering, no API routes that require a running server), next export produces a static HTML/CSS/JS bundle that can be served by Nginx alone with no Node.js runtime. Static export eliminates the Node.js process manager requirement and dramatically simplifies the VPS setup. However, most production Next.js applications use server-side features that require a running Node.js process.

Vercel and Netlify are the dominant managed platforms for Next.js and React deployments. Both are US companies subject to US law, DMCA compliance obligations, and their own acceptable use policies that restrict content categories. Vercel has terminated deployments for content policy violations, and Netlify processes DMCA notices per US law. For React/Next.js applications in sensitive categories, self-hosted offshore VPS provides the same deployment benefits with none of the managed platform's compliance constraints.

Content restrictions on managed platforms are enforced at the CDN edge - when Vercel removes a deployment, it removes all edge-cached copies simultaneously, making the site inaccessible globally within seconds. A self-hosted VPS requires valid local court process to take down, which takes months. For content that is regularly targeted by DMCA notices or platform policy enforcement, the difference between managed-platform hosting and offshore VPS hosting is the difference between hours of availability and months of availability before a takedown can be executed.

Performance for self-hosted Next.js on offshore VPS competes with Vercel for audiences close to the server location. Iceland serves European and North Atlantic users with excellent latency. Romania serves Eastern European audiences. For global audiences, a Cloudflare CDN layer (free tier) in front of the offshore Next.js VPS provides edge caching for static assets and SSG-rendered pages globally while the origin server remains in the privacy-protected offshore location. Cloudflare processes DMCA notices for cached content only - if your origin is unreachable, there is no content to serve from cache, making Cloudflare-layer takedowns ineffective for dynamic content.

Cost comparison: Vercel Pro at $20/mo includes usage limits - $20 in bandwidth overages can quickly escalate costs for high-traffic applications. AnubizHost Romania VPS at $19.99/mo for 1 vCPU / 1 GB RAM handles low-to-medium traffic Next.js sites with unlimited bandwidth (subject to fair use). Higher-tier configurations scale to 8 vCPU / 16 GB RAM for large Next.js applications at predictable fixed monthly pricing.

Next.js API routes (/pages/api/ in Pages Router, /app/api/ in App Router) run as serverless functions on Vercel but as standard Node.js request handlers in self-hosted deployments. In self-hosted mode, API routes are persistent handlers in the Next.js server process rather than ephemeral functions - they can maintain in-memory state, use long-lived database connections, and call external APIs without cold start latency.

Database connections from Next.js API routes on a VPS: use connection pooling (PgBouncer for PostgreSQL, or the Prisma connection pool for ORM-based applications). Without pooling, each server-side render and API route invocation that queries the database creates a new connection - this exhausts PostgreSQL's connection limit quickly under concurrent load. Prisma (popular with Next.js) has built-in connection pooling via Prisma Accelerate, but on a self-hosted VPS, use PgBouncer as a middleware layer between the Next.js process and PostgreSQL instead.

Next.js middleware runs at the edge on Vercel but runs in the Node.js server process on self-hosted deployments. Middleware for authentication checks, rate limiting, and geo-based routing works the same functionally but does not benefit from Vercel's global edge distribution. For offshore self-hosted Next.js, this means authentication middleware adds a small fixed latency to every request (the time to validate a JWT or check a session in Redis) rather than being handled at a distributed edge. This is acceptable for most applications and is the standard behavior in self-hosted Next.js.

For Next.js applications that need both a frontend and a separate API backend (a common architecture for applications with complex business logic), the API backend can be a separate process on the same VPS or a separate VPS. Offshore hosting allows you to run both layers in the same jurisdiction, maintaining data residency consistency. An Express, Fastify, or NestJS API on the same VPS as the Next.js frontend communicates over localhost - zero network latency between frontend server and API, with both under the same offshore legal framework.

Pure React Single Page Applications (create-react-app, Vite-based SPAs, or custom webpack configurations) without server-side rendering deploy as static HTML/JS/CSS bundles that can be served by Nginx alone. The VPS role for a React SPA is pure static file serving - no Node.js runtime required for the application itself (API backends run separately). This makes React SPA hosting extremely lightweight: a 1 vCPU / 1 GB RAM VPS can serve thousands of concurrent SPA visitors if the assets are properly cached.

Nginx static file serving for a React SPA: set the root directive to your build output directory (typically build/ for CRA or dist/ for Vite). The critical Nginx configuration for SPAs is the try_files directive: try_files $uri $uri/ /index.html; - this returns index.html for any path that does not match a static file, allowing React Router to handle client-side routing. Without this configuration, direct navigation to a route like /dashboard returns a 404 from Nginx because no file called dashboard exists at the file system level.

Asset caching strategy: React's build process produces hashed filenames for all compiled assets (main.abc12345.js), making them safe to cache indefinitely. Configure Nginx Cache-Control: max-age=31536000, immutable for paths matching the hashed pattern. The index.html file must not be cached long-term (or cached with short TTLs) because it references the hashed assets by name - a cached old index.html referencing old asset hashes will fail to load after a deployment changes the asset filenames. Set Cache-Control: no-cache for index.html specifically.

For React SPAs that attract audiences in regions with high DDoS risk (privacy tools, political content, content in censorship-heavy regions), a Cloudflare free-tier layer in front of the offshore VPS provides DDoS protection without moving the origin out of the offshore jurisdiction. Cloudflare's cache rules can cache the SPA's hashed assets globally while passing through API calls to the offshore API backend. The origin IP is hidden from users behind Cloudflare's anycast network, preventing direct DDoS against the offshore VPS IP.