Deploy Next.js to a VPS: Every Step, No Skips

You can deploy a Next.js app to a VPS without Vercel by running Node.js + PM2 + Nginx on any Linux VPS with 2 GB of RAM or more — or by using a platform like Temps that handles all of that automatically from a single git push. This guide covers both paths so you can choose what fits your situation.

TL;DR: Manual deployment means managing Node.js, PM2, Nginx, Certbot, deploy scripts, and GitHub Actions — plus separate services for monitoring, error tracking, and analytics. A self-hosted deployment platform collapses all of that into one tool. Either way, this guide walks every step.

How to Deploy a Next.js App to a VPS

The fastest answer: SSH into a fresh Ubuntu server, install Node.js 24 LTS, clone your repo, run npm ci && npm run build, start the app with PM2, put Nginx in front for SSL, and wire up GitHub Actions to re-run those steps on every push to main.

The rest of this guide explains exactly how to do that, why each piece exists, and what it still leaves unsolved.

Manual vs. Platform: What You're Actually Choosing

Before diving into the steps, it helps to know what you're signing up for:

For a priced comparison with Vercel see Temps vs Vercel and the Next.js hosting cost breakdown. Temps is a self-hosted platform, written in Rust, that runs your apps in Docker containers and provides the git-push deployment workflow plus built-in analytics, error tracking, session replay, uptime monitoring, and managed databases — free to self-host, with no per-seat fees and no bandwidth bills. Temps Cloud, a hosted control plane for your own servers, is coming soon from $29/month. If you want the manual approach for full control or learning, keep reading. If you want to skip straight to a platform, see how to deploy Next.js to your own server with Temps.

What You Need (Manual Path)

• A VPS from any provider (Hetzner, DigitalOcean, Linode, Vultr). 2 GB RAM minimum for a Next.js app with a build step. 4 GB if you're running a database on the same box.
• A domain name pointed at your server's IP address.
• SSH access to the server.
• A Next.js app that builds successfully with npm run build locally.

This guide assumes Ubuntu 22.04 or 24.04. Debian works too with minor differences.

Step 1: Set Up the Server

SSH into your new server:

ssh root@your-server-ip

Update packages and install the basics:

apt update && apt upgrade -y
apt install -y curl git ufw

Set up the firewall (the VPS security checklist covers the rest of the hardening). Open SSH, HTTP, and HTTPS. Close everything else:

ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enable

Create a non-root user (running everything as root is asking for trouble):

adduser deploy
usermod -aG sudo deploy

Copy your SSH key to the new user:

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Log out and log back in as the deploy user from now on.

Step 2: Install Node.js

Don't install Node from apt. The version in Ubuntu's default repos is usually ancient. Use the NodeSource repository:

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs

Verify:

node --version  # Should be 24.x
npm --version

If your project uses a specific Node version (check .nvmrc or engines in package.json), match it here. Mismatched Node versions between local and server are one of the most common causes of "works on my machine" deployment failures.

Step 3: Clone and Build Your App

cd /home/deploy
git clone https://github.com/your-username/your-nextjs-app.git
cd your-nextjs-app
npm ci

npm ci instead of npm install. It installs from the lockfile exactly, which is what you want in production. npm install can resolve to different versions.

Set your environment variables:

cp .env.example .env.production
nano .env.production
# Fill in your production values: DATABASE_URL, API keys, etc.

Build:

npm run build

If this fails, fix it before continuing. Common issues: missing env vars that the build needs at compile time (Next.js bakes NEXT_PUBLIC_* variables into the client bundle during build), or native dependencies that need build tools (sudo apt install -y build-essential).

Step 4: Run the App with PM2

You need a process manager. If you just run npm start in your terminal and disconnect, the process dies. PM2 keeps it running, restarts it if it crashes, and manages logs.

sudo npm install -g pm2

Start your app:

pm2 start npm --name "nextjs-app" -- start

Check it's running:

pm2 status
pm2 logs nextjs-app

By default, Next.js starts on port 3000. Verify it's listening:

curl http://localhost:3000

Tell PM2 to start your app on server boot:

pm2 startup
pm2 save

The pm2 startup command prints a line you need to copy and run with sudo. Don't skip it, or your app won't survive a server reboot.

Step 5: Install and Configure Nginx

Nginx sits in front of your Next.js app. It handles SSL termination, serves static files, and proxies dynamic requests to your Node process.

sudo apt install -y nginx

Create a site config:

sudo nano /etc/nginx/sites-available/your-app

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Enable the site:

sudo ln -s /etc/nginx/sites-available/your-app /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

The proxy_set_header Upgrade and Connection 'upgrade' lines are for WebSocket support. If your app uses real-time features, these headers are required.

At this point, your app should be accessible at http://yourdomain.com. No SSL yet.

Step 6: SSL with Let's Encrypt

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot modifies your Nginx config to add SSL, sets up automatic certificate renewal, and redirects HTTP to HTTPS.

Verify the renewal timer is active:

sudo systemctl status certbot.timer

Certificates expire every 90 days. Certbot's timer renews them automatically. If you skip this check and the timer isn't running, your site goes down in 3 months with an expired cert. It happens more often than you'd think.

Step 7: Set Up Deployments

Your app is live. Now you need a way to update it when you push new code.

Create /home/deploy/deploy.sh:

#!/bin/bash
set -e

cd /home/deploy/your-nextjs-app

echo "Pulling latest code..."
git pull origin main

echo "Installing dependencies..."
npm ci

echo "Building..."
npm run build

echo "Restarting..."
pm2 restart nextjs-app

echo "Done."

chmod +x /home/deploy/deploy.sh

Automating with GitHub Actions

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_IP }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: /home/deploy/deploy.sh

Add SERVER_IP and SSH_PRIVATE_KEY to your repo's GitHub Secrets.

What This Doesn't Handle

The deploy script above has real gaps:

• No health check and no safe build. The script builds into the same .next directory the live app is serving from, so requests can fail while the build runs. If the build fails, set -e stops the script before pm2 restart, and the running app is left on a half-written .next that the next restart or reboot will boot. PM2 has no previous version to fall back to.
• No rollback. If the deploy breaks the app, you have to manually revert.
• No preview environments. Every push to main goes straight to production.
• Downtime during restart. PM2's restart kills the old process and starts the new one. There's a 1–3 second gap with 502 errors.

You can solve each of these individually (building each release in its own directory and switching a current symlink, blue-green deploys with Nginx upstream toggling, a webhook server, PM2's cluster mode). But each solution adds complexity, and by the time you've built all of them, you've built a deployment platform. For a deeper look at how these platforms automate this pipeline, see how git-push deployments work under the hood.

Step 8: Monitoring (The Part Most Tutorials Skip)

Your app is deployed. How do you know it's still running tomorrow?

Logs: PM2 handles application logs. Rotate them or they'll fill your disk:

pm2 install pm2-logrotate

Uptime: You need something that pings your site and alerts you when it's down. Free options: UptimeRobot, Betterstack (free tier), or a cron job that curls your health endpoint. See our guide on building an uptime monitoring system for more depth.

Error tracking: When your app throws an unhandled exception in production, how do you find out? Sentry (free tier), LogRocket, or parsing PM2 logs manually. We covered the options in error tracking without Sentry.

Analytics: Google Analytics, Plausible, Umami, or similar. If you want to avoid third-party scripts entirely, see how to add web analytics without third-party scripts.

Each of these is a separate tool, a separate account, a separate dashboard.

The Full Stack of What You Just Built

Let's count:

Running on your server:

1. Node.js (runtime)
2. PM2 (process manager)
3. Nginx (reverse proxy, SSL termination)
4. Certbot (certificate renewal)
5. Git (code delivery)
6. GitHub Actions (build automation)

Still need but didn't set up: 7. Uptime monitoring (external service) 8. Error tracking (external service) 9. Analytics (external service) 10. Log management (PM2 + logrotate, or external service)

That's 6 things on your server and 4 external services for a single Next.js app.

The Alternative: Auto-Detected Builds with Temps

If you'd rather not manage Nginx, PM2, Certbot, and four separate observability tools, Temps is a self-hosted deployment platform that replaces all of it.

Three things Temps does that the manual approach doesn't:

1. Auto-detected builds. Point Temps at your repository. It detects Next.js from next.config.js, next.config.mjs or next.config.ts, runs your build script on Node.js 22 and starts the app with next start, so there's no Dockerfile or build script to maintain and you don't need output: 'standalone'. An app with a custom server such as server.js needs its own Dockerfile, which Temps uses as-is.

2. Health-checked cutover. Before switching traffic, Temps requests your app (/, or the path set in .temps.yaml) until it gets 2 consecutive good responses. If the new version doesn't become healthy within the startup timeout (5 minutes by default, configurable per project), the deployment is marked failed and the current version keeps serving. Rolling back a deploy that already went live is a manual redeploy of a previous version. The manual PM2 approach has no equivalent gate.

3. Built-in observability stack. Analytics, error tracking, session replay, and uptime monitoring are included — not separate accounts. Temps replaces PostHog/Plausible, Sentry, FullStory, and Pingdom alongside its deployment engine.

Self-host Temps on the same VPS (dual MIT / Apache 2.0 license, free). Download the installer, read it, then run it with bash; it installs Docker if needed, sets up the database and creates your admin account:

curl -fsSL https://temps.sh/deploy.sh -o deploy.sh
less deploy.sh
bash deploy.sh

Then connect your Next.js repo and push. The quickstart covers the installer's setup modes, and Deploy Next.js to your own server covers the Next.js specifics.

Or: Other Platforms Worth Knowing

• Vercel — They built Next.js. Free tier is generous. Costs scale fast with traffic.
• Coolify — Open-source, self-hosted. Handles Docker, Traefik proxy, SSL, and git-push deploys.
• Dokploy — Open-source, simpler than Coolify, focused on minimal configuration.
• Kamal — From the Rails team. Deploys Docker containers to any server over SSH with minimal abstraction.

Frequently Asked Questions

How do I deploy a Next.js app without Vercel?

Run it on a server you control, either by hand (Node.js, PM2, Nginx and Certbot, as this guide shows) or with a self-hosted platform such as Temps. Deploy Next.js without Vercel compares the options, including managed platforms.

Can I deploy Next.js to a VPS without Docker?

Yes. The manual path in this guide (Node.js + PM2 + Nginx) runs the app directly without Docker. Temps also supports Dockerfile-based builds if you prefer containerization.

Do I need a Dockerfile to deploy Next.js with Temps?

No. Temps detects Next.js from a next.config.* file, builds it on Node.js 22 and runs next start. Add your own Dockerfile only if the app needs a custom server such as server.js; Temps then builds that Dockerfile as-is.

What's the minimum VPS size for a Next.js app?

2 GB RAM is the practical minimum for a Next.js app that builds on the server. 1 GB servers frequently run out of memory during next build. If you're also running a database on the same box, use 4 GB.

Does Temps support Next.js App Router and Server Components?

Yes. Temps runs Next.js as a standard Node.js application. App Router, Server Components, API routes, and Server Actions all work as expected — there are no serverless function limitations or Edge runtime constraints.

How does Temps handle zero-downtime deployments for Next.js?

The old version keeps serving while Temps health-checks the new one. Traffic switches only after 2 consecutive successful responses; if the new version isn't healthy when the startup timeout (5 minutes) runs out, the deployment is marked failed and traffic never moves. There's no automatic rollback after a deploy has gone live: to go back, redeploy a previous deployment from the dashboard or with bunx @temps-sdk/cli rollback.