At first glance, this sounds simple.

After all, Next.js runs on Node.js, right?

In reality, there are quite a few moving parts that people often overlook:

• Which Node version should you install?

• Do you need PM2?

• What about Nginx?

• How do you handle SSL?

• Does the project use Static Export or Server Rendering?

• How do environment variables work?

• What's the deployment workflow after moving away from Vercel?

In this article I'll go through everything we considered during the migration so you can avoid the common mistakes.

Why Move Awayfrom Vercel?

Don't get me wrong.

Vercel is fantastic.

It's probably still my favourite platform for Next.js projects.

However there are legitimate reasons to move.

For example:

• Company policy requires self-hosting

• Existing VPS infrastructure

• Lower long-term hosting costs

• More control over the server

• Security or compliance requirements

In our case the client already managed several VPS servers and wanted all projects under one infrastructure.

First Question: Is Your Site Actually Static?

This changes everything.

There are generally three scenarios.

1. Static Export

next export

or

output: 'export'

These projects can literally be hosted on Nginx without Node running.

Easy.

2. Server Side Rendering

If you're using:

• getServerSideProps

• API routes

• authentication

• middleware

You'll need Node running continuously.

3. Hybrid

Most modern Next.js projects fall somewhere in between.

Some pages are static.

Some are rendered dynamically.

This is completely fine you'll just need a Node runtime.

Choosing the VPS

For most business websites, you don't need a monster server.

Something like:

• 2 vCPU

• 2–4 GB RAM

• Ubuntu 24.04 LTS

• 40–80 GB SSD

is more than enough.

Popular providers include:

• Hetzner

• DigitalOcean

• Vultr

• Linode

Software Stack

Our deployment stack looked like this:

Ubuntu
↓
Node.js LTS
↓
PM2
↓
Nginx
↓
Let's Encrypt SSL
↓
Next.js

Each tool has a clear responsibility:

Environment Variables

This is one of the easiest things to forget.

Make sure you copy every environment variable from Vercel.

Things like:

NEXT_PUBLIC_API_URL
DATABASE_URL
SMTP_PASSWORD
GOOGLE_CLIENT_ID

Missing even one variable can cause mysterious production bugs.

Build Process

Once the project is on the server, the deployment is surprisingly straightforward.

npm install

npm run build

npm run start

PM2 then keeps everything running.

Nginx Configuration

Instead of exposing Node directly, let Nginx handle incoming traffic.

Benefits include:

• SSL termination

• Compression

• Reverse proxy

• Better security

• Easier scaling later

SSL

Never deploy production websites over plain HTTP.

Let's Encrypt makes this almost effortless.

After the initial setup, certificates renew automatically.

One less thing to worry about.

Deployment Workflow

Instead of Vercel automatically deploying every commit, we implemented a simple deployment flow:

Developer
      ↓ 
GitHub
      ↓
SSH into VPS
      ↓
git pull
      ↓
npm install
      ↓
npm run build
      ↓
pm2 restart

For small teams, this is often all you need.

Larger teams can later automate the process using GitHub Actions.

Things That Caught Us Off Guard

Every migration teaches you something.

Here are a few things worth checking before switching:

• Node version compatibility

• Missing environment variables

• File permissions

• Build cache

• Firewall rules

• SSL certificates

• Reverse proxy configuration

• Process manager restarts

None of these are particularly difficult, but missing just one can turn a 30-minute deployment into hours of debugging.

Moving a Next.js project from Vercel to a VPS isn't about replacing one platform with another—it's about understanding the pieces that Vercel quietly manages for you behind the scenes.

Once those responsibilities are handled correctly, self-hosting can be a reliable and flexible option that gives you full control over your infrastructure.

If you're planning a similar migration, spend a little extra time verifying your runtime requirements, environment variables, and deployment workflow before making the switch. It'll save you a lot of headaches later.

About me

I'm a full-stack developer at Diavante Digital, where I work on WordPress, WooCommerce, Next.js, automations, APIs, and infrastructure projects. I enjoy documenting real engineering challenges and sharing practical solutions from client work.