Next.js 16 on $5 VPS — Memory OOM Killed the Server Every 6 Hours

You migrated from Vercel to a $5 DigitalOcean VPS to save money. You SSH in, clone the repo, run npm run build && npm start, and it works. You close your laptop, satisfied. Six hours later, your phone buzzes: site is down. You SSH in. The Node process is gone. No error message. Just dead.

You restart it. Six hours later, it dies again. You check dmesg — the kernel's Out-Of-Memory killer terminated your Node process. npm run start doesn't set memory limits, and Next.js in production with image optimization, server-side rendering, and API routes can easily exceed a $5 VPS's 1GB RAM.

The fix is not a bigger server. The fix is a proper production deployment setup: a process manager that restarts on crash, memory limits that prevent OOM kills, a reverse proxy for static file serving and SSL termination, and health checks that catch issues before users do.

This guide covers four deployment strategies — Vercel, self-hosted Node.js, Docker, and static export — with the pros, cons, and configs for each. By the end, your $5 VPS will run Next.js 16 without crashing, restart automatically if it does, and serve pages fast enough to compete with a $20 plan.

Vercel: The One-Button Deployment (And When It Gets Expensive)

Vercel is the easiest way to deploy Next.js. Connect your GitHub repo, hit deploy, and it works. SSL, CDN, image optimization, serverless functions, and automatic preview deployments are all included. For most projects, this is the right choice.

When does Vercel get expensive? At scale. Vercel's Pro plan ($20/month) includes 1TB bandwidth and 5,000 build minutes. Beyond that: $0.40/additional 100GB bandwidth, $0.10/additional build minute. A site with 100GB monthly traffic costs $20. A site with 2TB costs $40 + build costs. A media-heavy site with 10TB costs $360/month — suddenly the $5 VPS looks attractive.

Vercel also charges for serverless function execution. Each API route invocation, each ISR revalidation, and each middleware call counts. For high-traffic APIs, this adds up fast. The Pro plan includes 500K function invocations; additional invocations are $0.18/100K.

Self-Hosting with Node.js: PM2, Memory Limits, and Reverse Proxy

Self-hosting Next.js with a Node.js process manager (PM2) is the most common VPS setup. PM2 handles process restarts, log management, and cluster mode (multi-core).

Essential config: set NODE_OPTIONS='--max-old-space-size=512' to cap Node's heap at 512MB on a 1GB server. This prevents the kernel's OOM killer from terminating your process. PM2's max_memory_restart option restarts the process if it exceeds a memory threshold.

You also need a reverse proxy — Caddy or Nginx. The proxy handles SSL termination, static file serving, and load balancing. Caddy is simpler (auto-SSL with Let's Encrypt). Nginx is more configurable. The proxy forwards requests to your Node process on localhost:3000.

// PM2 ecosystem file
module.exports = {
  apps: [{
    name: 'next-app',
    script: 'node_modules/next/dist/bin/next',
    args: 'start',
    env: {
      NODE_ENV: 'production',
      NODE_OPTIONS: '--max-old-space-size=512',
      PORT: 3000,
    },
    max_memory_restart: '600M',
    instances: 1, // Single instance for low-memory VPS
    autorestart: true,
    watch: false,
    max_restarts: 10,
    min_uptime: '10s',
    error_file: './logs/err.log',
    out_file: './logs/out.log',
    merge_logs: true,
  }]
}

# Commands:
# pm2 start ecosystem.config.js
# pm2 save
# pm2 startup  # auto-start on reboot

Caddy as Reverse Proxy: The Easiest SSL Setup

Caddy is the simplest reverse proxy for self-hosted Next.js. It automatically provisions and renews Let's Encrypt SSL certificates. The config is minimal: a single Caddyfile with your domain and the proxy directive.

Caddy also serves static files directly, reducing load on your Node process. For Next.js, the proxy passes all requests to localhost:3000. Caddy handles HTTPS, HTTP/2, and compression.

The alternative is Nginx — more configurable but more complex. Nginx requires manual SSL certificate setup with certbot. For most self-hosted Next.js setups, Caddy is the better choice unless you already have Nginx infrastructure.

# Caddyfile — reverse proxy for Next.js
yourdomain.com {
    reverse_proxy localhost:3000

    # Optional: serve static files directly
    root * /var/www/next-app/public
    file_server
}

# Alternative: Nginx configuration
# /etc/nginx/sites-available/next-app
server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Docker Deployment: Reproducible and Portable

Docker gives you a reproducible environment that works identically on your laptop, VPS, or cloud. The Dockerfile for Next.js uses a multi-stage build: build the app in one stage, run it in a minimal production stage with only the necessary files.

Key Docker config: use node:20-alpine for the smallest image size (~150MB). Copy only .next (built app), public, package.json, and node_modules. Use --max-old-space-size in the CMD. Add HEALTHCHECK so Docker knows if the app is responding.

Docker Compose adds the reverse proxy as a separate service. Caddy in a container handles SSL, and Next.js runs in its own container with resource limits and restart policy.

# Multi-stage build
# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Production
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
ENV NODE_OPTIONS='--max-old-space-size=512'

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000 || exit 1

CMD ["node", "server.js"]

Docker Compose: App + Reverse Proxy + Monitoring

Docker Compose orchestrates multiple containers. For a self-hosted Next.js setup, you typically need: the Next.js app container, a reverse proxy (Caddy), and optional monitoring (Prometheus + cAdvisor for metrics).

The Compose file sets resource limits (512MB RAM for Next.js), restart policies (always), and network configuration. Caddy auto-discovers the Next.js container via Docker's internal DNS (service name as hostname).

Add environment variables in a .env file: NEXT_PUBLIC_API_URL, DATABASE_URL, etc. Docker Compose loads these into the containers.

version: '3.8'

services:
  next-app:
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    ports:
      - '3000:3000'
    mem_limit: 512m
    cpus: 1
    environment:
      - NODE_ENV=production
      - NODE_OPTIONS=--max-old-space-size=384
    env_file:
      - .env
    healthcheck:
      test: ['CMD', 'wget', '--no-verbose', '--tries=1', '--spider', 'http://localhost:3000']
      interval: 30s
      timeout: 3s
      retries: 3

  caddy:
    image: caddy:2-alpine
    restart: always
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - next-app

volumes:
  caddy_data:
  caddy_config:

Static Export: No Node.js Server Needed

If your Next.js app doesn't use server-side features (API routes, server actions, rewrite/redirect, or dynamic SSR), you can export a completely static site with next export. The output is pure HTML, CSS, and JS — deployable to any static host (S3, Netlify, Cloudflare Pages, GitHub Pages) with no Node.js runtime.

Static export has no memory issues, no process management, no reverse proxy. It's the simplest deployment and the cheapest to scale. CDNs serve static files instantly from edge locations.

The trade-off: no dynamic server-side features. If you need SSR, API routes, or image optimization at request time, static export won't work. But for blogs, documentation, marketing sites, and most content-driven sites, static export is ideal.

Enable static export in next.config.ts with output: 'export'. Images must be pre-optimized (use unoptimized: true or static imports).

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  output: 'export',

  // Images must be pre-optimized for static export
  images: {
    unoptimized: true,
  },

  // Ensures consistent file structure
  trailingSlash: true,
}

export default nextConfig

// Build: npm run build
// Output: out/
// Deploy: serve out/ with any static server
// Netlify: npx netlify-cli deploy --dir=out
// Cloudflare Pages: wrangler pages deploy out/

Memory Optimization: Reducing Next.js RAM Usage

On a $5 VPS with 1GB RAM, every megabyte counts. Next.js's biggest memory consumers: image optimization (sharp/vips buffers), RSC cache, and inline middleware. Here's how to reduce each.

Disable image optimization if you're using a CDN or pre-optimized images: images.unoptimized: true. Or offload to a dedicated image service (Cloudflare Images, imgproxy, Thumbor).

Reduce RSC cache by minimizing the number of unique Server Components. Each unique RSC payload is cached in memory. If you have dynamic pages with many variants, the cache grows. Set staleTimes in next.config to reduce cache duration.

Add a swap file: fallocate -l 2G /swapfile && mkswap /swapfile && swapon /swapfile. Swap is slow but prevents OOM kills when memory spikes.

#!/bin/bash
# Setup 2GB swap file
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make permanent
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Verify
free -hm

# Set swappiness to 10 (only swap when necessary)
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl vm.swappiness=10

Monitoring Self-Hosted Next.js: Uptime, Memory, Logs

Without monitoring, you'll discover crashes when users email you. Set up: uptime monitoring (UptimeRobot or BetterStack — free tiers available), server monitoring (Netdata or Prometheus + Grafana), and log aggregation (Loki or just journald).

PM2 has built-in monitoring: pm2 monit shows CPU/memory per process. For Docker, docker stats shows all containers. Set up alerts for: CPU > 80%, memory > 80%, disk > 90%, and process restarts.

Logs: PM2 writes to ~/.pm2/logs/. Docker writes to docker logs. Forward logs to a central service (Logtail, Axiom, or just journald with journalctl -u next-app -f).

#!/bin/bash

# PM2 monitoring
pm2 monit

# Full process list with memory
pm2 jlist | jq '.[] | {name: .name, memory: .monit.memory, cpu: .monit.cpu}'

# Docker stats (one-liner for monitoring)
docker stats --no-stream --format 'table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}'

# System monitoring
htop  # Real-time process view

# Netdata (one-command monitoring)
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

# Logs
pm2 logs next-app --lines 100
journalctl -u next-app -f --since '5 min ago'

CI/CD: Automating Deployments to Your VPS

Manual SSH deploys are error-prone and time-consuming. Set up GitHub Actions to build and deploy automatically on push to main.

The workflow: checkout → install → build → copy via rsync or scp → restart PM2/Docker. Use SSH keys stored as GitHub secrets for authentication.

For Docker: the workflow builds the image, pushes to Docker Hub or GitHub Container Registry, then SSHes into the VPS and pulls/runs the new image. This gives you versioned, reproducible deployments.

Add a rollback step: if the health check fails after deployment, automatically revert to the previous build.

name: Deploy to VPS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install & Build
        run: |
          npm ci
          npm run build

      - name: Deploy via rsync
        uses: burnett01/rsync-deployments@7.0.1
        with:
          switches: -avz --delete
          path: .next/
          remote_path: /var/www/next-app/.next/
          remote_host: ${{ secrets.VPS_HOST }}
          remote_user: ${{ secrets.VPS_USER }}
          remote_key: ${{ secrets.VPS_SSH_KEY }}

      - name: Restart app
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /var/www/next-app
            pm2 restart next-app || pm2 start npm --name next-app -- start
            pm2 save

Choosing the Right Deployment Strategy

Here's a decision framework. Vercel: use if your team has no DevOps, traffic is under 500K monthly visits, or you need preview deployments. Self-hosted: use if you have DevOps experience, traffic is high enough that Vercel costs exceed $100/month, or you need specific VPS-level control. Docker: use if you want reproducible environments across dev/staging/prod. Static export: use if your app doesn't need server features and you want the cheapest, simplest deployment.

You can also combine: static export for your marketing site (cheap, on CDN), and a self-hosted Node server for the app dashboard (needs server-side features).

The worst choice is no choice: running npm run start on a VPS without a process manager, memory limits, or monitoring. That setup crashes — it's a matter of when, not if.

// Example: Hybrid strategy
// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  // For static export parts of the site
  output: process.env.BUILD_TARGET === 'export' ? 'export' : undefined,

  images: {
    // Use Cloudflare Images for optimization
    loader: 'cloudinary',
    path: 'https://res.cloudinary.com/my-cloud/',
  },
}

export default nextConfig

Common Self-Hosting Mistakes and Fixes

Most self-hosting failures follow a pattern. First: no process manager. npm run start is not a production command — it has no restart, no logging, no memory limit. Fix: PM2 or Docker.

Second: no reverse proxy. Node.js on port 3000 with direct exposure. No SSL, no HTTP/2, no static file optimization. Fix: Caddy or Nginx in front.

Third: no swap file. When memory spikes, the kernel OOM kills Node. A 2GB swap file buys you time and prevents crashes. Fix: fallocate -l 2G /swapfile.

Fourth: no health checks. The process crashes, and you don't know until someone reports the site down. Fix: PM2 autorestart or Docker HEALTHCHECK + restart policy.

Fifth: no monitoring. Even with all the above, you need visibility. A crash that auto-recovers is better than a crash that stays down, but it still means something is wrong. Fix: uptime monitoring + server metrics.

Complete Production Self-Hosting Playbook

Here's the complete setup for a $5 VPS running Next.js 16. Install: Node.js 20, PM2, Caddy, and git. Clone the repo. Set up environment variables. Build the app. Configure PM2 with memory limits. Configure Caddy with auto-SSL. Add 2GB swap. Set up UptimeRobot to ping your domain every 5 minutes.

That's it. This setup handles crashes (auto-restart), memory spikes (swap + limit), SSL (auto-renewal), and monitoring (uptime alerts). It's not as simple as Vercel, but it costs $5/month + domain instead of $20-$200.

For teams that want even simpler: use Coolify or Dokku — open-source PaaS-like tools that wrap Docker and handle the deployment complexity. You still own the VPS but get Heroku-like push-to-deploy workflows.

#!/bin/bash
# Complete self-hosting setup on Ubuntu 22.04

# 1. Install dependencies
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs git

# 2. Install PM2
npm install -g pm2

# 3. Install Caddy
sudo apt-get install -y debian-keyring debian-archive-keyring
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt-get update && sudo apt-get install caddy

# 4. Clone and build
cd /var/www
git clone https://github.com/your-org/your-app.git next-app
cd next-app
npm ci
npm run build

# 5. Setup swap
sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile

# 6. Start with PM2
NODE_OPTIONS='--max-old-space-size=512' pm2 start npm --name next-app -- start
pm2 save && pm2 startup