How to Deploy a Next.js and Node.js Application on a VPS

Deploying Next.js and Node.js on your own VPS gives you fixed monthly costs, full data ownership, and no serverless cold starts. This is the exact production stack TechDino uses to deploy client applications: Ubuntu + Nginx + PM2 + Let's Encrypt. Here is the complete process.

1. Prepare the Server

Create a non-root deploy user, enable the firewall (allow OpenSSH, 'Nginx Full'), and point your domain's A record at the server IP before continuing.

2. Build the Application

3. Run It Under PM2

PM2 restarts crashed processes, keeps logs (pm2 logs), and survives server reboots — the minimum bar for production Node hosting.

4. Nginx Reverse Proxy

5. Free SSL with Let's Encrypt

6. Updating Without Downtime

Production Checklist

• Environment variables set on the server, never committed to git.
• Database backups scheduled (cron + off-server storage).
• pm2 save run after any process changes.
• Firewall allows only 22/80/443.
• Monitoring: pm2 monit locally, uptime checks externally.

Before You Go Live

The deployment works long before it is production-ready. These are the steps that separate a running app from a maintainable one:

• Set PM2 to start on boot (`pm2 startup` then `pm2 save`), or a reboot silently takes the site down.
• Confirm the Let's Encrypt renewal timer is active — certificates expire in 90 days and expiry always happens at an inconvenient moment.
• Keep secrets in environment files outside the repository, readable only by the service user.
• Enable gzip or brotli in Nginx. It is a one-line change with a measurable effect on load time.
• Set cache headers for static assets so browsers stop re-fetching them.
• Configure a firewall allowing only 22, 80 and 443, and put SSH on key authentication.

Backups and Recovery

A backup that has never been restored is a hypothesis. Schedule database dumps and uploaded-file backups to off-server storage, keep enough history to survive a problem discovered late, and restore one to a scratch server at least once so you know the procedure and how long it takes.

Knowing When It Breaks

• External uptime monitoring — the server cannot tell you it is down.
• Disk space alerts. Logs filling the disk is the most common self-inflicted outage.
• PM2 log rotation, for the same reason.
• Application error tracking, so failures surface before a user reports them.
• A scheduled window for OS and dependency security updates, rather than deferring them indefinitely.

When a VPS Is the Wrong Choice

A VPS gives fixed costs, full data control and no cold starts — but you own the operations. If nobody will handle patching, monitoring and restores, a managed platform is more honest about the trade-off. The comparison is between predictable cost with your maintenance, and higher variable cost with someone else's. Pick based on whether that maintenance owner actually exists.

See deployment options for how TechDino deployments are structured, and support and maintenance for what ongoing ownership involves.

Prefer not to run servers yourself? TechDino includes deployment and maintenance with every ready-made product — VPS setup, SSL, monitoring, and updates handled for you. Get in touch.