module.exports = {
apps: [{
name: "next-app",
script: "./node_modules/next/dist/bin/next",
args: "start",
instances: "max",
exec_mode: "cluster",
cwd: "/var/www/next-app",
env: {
PORT: 3000,
NODE_ENV: "production"
}
}]
}Am mutat recent un landing page mărișor și o aplicație de dashboard (în total cam 14k useri activi lunar) de pe Vercel pe un VPS de 10 euro de la Hetzner. Costurile au scăzut drastic, dar a trebuit să îmi bat capul cu chestiile pe care platformele PaaS le fac la un click distanță: zero downtime, SSL și managementul logurilor.
Dacă doar dai npm run build și npm run start pe server, ai o mare problemă. La fiecare deploy, aplicația ta va fi offline câteva secunde bune. Iată cum am rezolvat asta pe VPS-ul nostru de producție.
Cluster Mode în PM2 pentru Zero Downtime
Trucul ca să nu ai nicio milisecundă de downtime este să folosești PM2 în cluster mode. PM2 va porni mai multe instanțe ale aplicației tale (una pentru fiecare nucleu CPU) și va distribui traficul între ele.
Când faci deploy, în loc de clasicul pm2 restart, folosești pm2 reload. PM2 va reporni instanțele una câte una. În timp ce prima instanță se restartează, celelalte preiau tot traficul. Utilizatorul nu simte absolut nimic.
Configurația de PM2 care chiar funcționează
Am văzut mulți developeri care pornesc Next.js direct cu pm2 start npm -- start. E o greșeală mare. NPM consumă memorie inutil și, mai grav, uneori PM2 pierde controlul asupra procesului copil, iar la reload te trezești cu procese fantomă care mănâncă portul 3000. Cel mai curat mod este să apelezi direct binarul Next.js din node_modules.
Compromisul sincer: Ce pierzi pe VPS?
Să fim sinceri, trecerea pe VPS vine cu un cost de mentenanță. Pierzi optimizarea automată de imagini la nivel de Edge. Next.js va folosi procesorul VPS-ului tău pentru a redimensiona imagini.
La un proiect cu 8k vizite pe zi, am văzut CPU-ul sărind la 90% când editorii au urcat 50 de imagini noi în CMS fără să le comprime. Dacă ai un site foarte vizual, recomand să folosești un CDN extern (cum ar fi Cloudinary sau Bunny.net) sau să limitezi drastic dimensiunile din next.config.js.
Logurile îți pot bloca serverul
Am pățit-o acum doi ani la un proiect în Node.js. După vreo 6 luni de rulare impecabilă, site-ul a picat din senin. Motivul? PM2 salvase 35GB de loguri de erori (un API extern dădea timeout-uri dese) și discul VPS-ului era complet plin. Baza de date locală nu mai putea scrie nimic.
Nu lăsa PM2 de capul lui. Instalează imediat modulul de logrotate în PM2:
pm2 install pm2-logrotate
Acesta va tăia logurile zilnic și va păstra, de exemplu, doar ultimele 10 zile. Îți salvează viața, serios.
Nginx și HTTPS cu Certbot
Nginx stă în fața PM2-ului și se ocupă de SSL și de routarea traficului de pe portul 80/443 către portul intern 3000.
Pentru HTTPS, folosește Certbot. Dai un sudo apt install certbot python3-certbot-nginx și apoi sudo certbot --nginx -d domeniul-tau.ro. Își configurează singur certificatele Let's Encrypt în config-ul de Nginx și adaugă un cronjob de auto-renew. Nu mai trebuie să atingi nimic timp de ani de zile.
Voi unde țineți aplicațiile Next.js când cresc în trafic? Rămâneți pe Vercel pentru confort sau treceți pe VPS-uri proprii ca să economisiți bani?