module.exports = {
apps: [
{
name: 'next-app',
script: 'node_modules/next/dist/bin/next',
args: 'start',
instances: 'max',
exec_mode: 'cluster',
env: {
PORT: 3000,
NODE_ENV: 'production'
}
}
]
};Am văzut zeci de oameni care aruncă bani pe Vercel deși au proiecte mici sau medii care ar rula lejer pe un VPS de 5 euro de la Hetzner. Azi vă arăt cum am configurat eu o flotă de 12 aplicații Next.js pe VPS-uri clasice, folosind PM2, Nginx și logrotate. Obții zero-downtime la deploy și control total asupra infrastructurii fără să plătești taxe absurde de cloud.
De ce VPS și unde e capcana?
Să fim sinceri: Vercel e genial pentru DX (Developer Experience). Dai push în git și totul merge de la sine. Dar când treci de limitele free tier-ului și începi să plătești pentru bandwidth sau serverless execution time, te ia durerea de cap. La un proiect cu 8k useri activi pe zi, am redus costurile de la 120$ pe Vercel la exact 6$ pe un cloud VPS de la Hetzner.
Trade-off-ul? Trebuie să îți configurezi singur serverul. Dacă pică VPS-ul la 3 dimineața, tu ești cel sunat, nu echipa de on-call de la Vercel. Dacă accepți riscul ăsta și ai cunoștințe minime de Linux, iată rețeta mea stabilă.
PM2 în Cluster Mode pentru zero-downtime
Marea greșeală pe care o văd pe forumuri este rularea Next.js direct cu npm start sau cu PM2 în mod simplu (fork). Dacă dai restart la proces în timpul unui deploy, aplicația are un downtime de 2-5 secunde până pornește Node.js. Clientul primește o eroare urâtă de tip 502 Bad Gateway.
Soluția este să rulezi PM2 în cluster mode. PM2 pornește mai multe instanțe (de preferat egale cu numărul de nuclee CPU) și, când dai deploy, folosești comanda pm2 reload în loc de restart. PM2 va reporni instanțele pe rând, iar utilizatorul nu simte absolut nimic.
Nginx ca Reverse Proxy și Certbot pentru HTTPS
Next.js rulează local pe portul 3000 (sau cel definit în config). Nginx stă în față pe porturile 80 și 443, preia request-urile din exterior și le trimite către PM2. În plus, Nginx servește excelent fișierele statice din directorul .next/static direct de pe disc, scutind Node.js de muncă inutilă.
După ce ai pus Nginx-ul să asculte pe portul 80 și să facă proxy către localhost:3000, rulezi sudo certbot --nginx -d domeniul-tau.ro și ai rezolvat SSL-ul în 30 de secunde. Certbot își configurează singur reînnoirea automată prin cron job, deci uiți de el.
Coșmarul logurilor: Cum eviți un disc plin
Am pățit o chestie stupidă acum doi ani pe un server de producție. Un API extern pe care îl foloseam a început să arunce erori în buclă, iar Next.js le scria în console.log. În doar 3 zile, logul PM2 a ajuns la 42GB și a blocat complet VPS-ul fiindcă nu mai aveam spațiu pe disc.
De atunci, nu mai las niciun server fără pm2-logrotate. Este un modul PM2 care taie automat logurile când ajung la o anumită dimensiune și le șterge pe cele vechi. Îl instalezi cu o singură comandă: pm2 install pm2-logrotate și uiți de grija discului plin.
Când NU merită să faci asta?
Dacă ai un site cu mii de pagini generate prin ISR (Incremental Static Regeneration) sau folosești intens NextJS Image Optimization la volum mare, un VPS ieftin o să gâfâie rapid din cauza CPU-ului. Vercel externalizează imaginile și ISR-ul în CDN-ul lor global. Pe VPS, resursele tale sunt finite.
Sunt curios, voi pe ce rulați Next.js când vreți să scăpați de costurile din cloud?