Deployment Next.js pe VPS ieftin: PM2, Nginx, Certbot și fără downtime

Delia Petre · 2026-07-21T17:08:34.859Z

Cum am mutat un proiect Next.js cu 12k DAU de pe Vercel pe un VPS Hetzner de 6€: setup cu PM2 cluster, reverse proxy Nginx, logrotate și SSL gratuit.

Postat 21 iul. 2026

javascript

// ecosystem.config.js
module.exports = {
  apps: [
    {
      name: 'my-next-app',
      script: '.next/standalone/server.js',
      instances: 'max',
      exec_mode: 'cluster',
      env: {
        NODE_ENV: 'production',
        PORT: 3000
      }
    }
  ]
};

Salutare tuturor! Dacă v-ați lovit vreodată de factura de Vercel pe un proiect Next.js care a început să crească, știți exact despre ce vorbesc. Recent am mutat o platformă e-commerce cu vreo 12.000 de utilizatori zilnici de pe Vercel (unde săream frecvent de $250/lună) pe un VPS de la Hetzner de 6 euro.

Câștigul financiar e evident, dar vin și responsabilitățile. Dacă nu configurezi lucrurile cap-coadă, te trezești cu site-ul picat la fiecare deploy sau cu discul plin de log-uri inutile.

Zero Downtime cu PM2 în Cluster Mode

Cea mai mare greșeală pe care o văd pe forumuri e rularea pm2 start npm -- start. Comanda asta pornește un singur proces Node care consumă memorie aiurea și crapă la primul request mai ciudat.

Soluția matură este să folosești opțiunea output: 'standalone' în next.config.js și un fișier ecosystem.config.js. În felul ăsta, pornești direct serverul optimizat generat de Next.js, rulat pe toate nucleele CPU disponibile.

Când faci un deploy nou, după ce ai tras codul din Git și ai rulați npm run build, nu dai pm2 restart. Trucul pentru zero downtime e pm2 reload all. PM2 repornește procesele pe rând (rolling reload): primește trafic doar procesul nou instanțiat, în timp ce procesul vechi își termină request-urile active. Userul nu vede absolut niciun ecran de eroare 502.

Nginx ca Reverse Proxy și SSL cu Certbot

Nu expune niciodată portul 3000 direct în internet. Pune întotdeauna un Nginx în față. Nginx știe să gestioneze conexiunile blocate, fișierele statice și compresia gzip/brotli mult mai bine decât Node.js.

Configurația e banală: un proxy_pass http://127.0.0.1:3000; cu header-ele standard de Upgrade, Connection și X-Forwarded-For.

După ce ai salvat Nginx-ul, arunci un sudo certbot --nginx -d domeniul-tau.ro și ai HTTPS funcțional în mai puțin de un minut. Certbot își configurează automat un cron job sau un timer systemd pentru reînnoire, așa că nu mai ai treabă cu certificatele expirate.

Buba de care uită toți: Logrotate

Prin 2019 am învățat asta pe pielea mea. M-a sunat clientul duminică dimineață că e site-ul picat complet. Când m-am logat pe VPS, Nginx arunca eroare No space left on device. PM2 scrisese într-un fișier out.log vreo 45GB de log-uri de-a lungul a 6 luni până a umplut tot SSD-ul.

Ai două soluții simple:

Instalezi modulul de PM2: pm2 install pm2-logrotate. Îi configurezi o limită de 10MB per fișier și păstrezi doar ultimele 7 arhive.
Configurezi /etc/logrotate.d/nextjs din sistemul de operare.

Eu prefer modulul pm2-logrotate pentru că e foarte ușor de setat direct din CLI fără să-ți prinzi urechile în permisiuni pe Linux.

Care e trade-off-ul real?

Merge excelent dacă vrei control total, latență mică (un VPS în Frankfurt dă sub 30ms TTFB în România) și costuri fixe. Nasol devine când ai nevoie de Serverless Edge Functions distribuite global sau când crești atât de mult încât un singur VPS nu mai face față și trebuie să bagi un Load Balancer în fața a două noduri.

Pentru 90% din proiectele din România, un VPS de 10-15 euro cu PM2 + Nginx e mai mult decât suficient și îți economisește mii de dolari pe an.

Voi ce setup folosiți în producție pentru Next.js? Rămâneți pe Vercel/Netlify sau preferați Docker / Coolify / VPS clasic?