module.exports = {
apps: [
{
name: "next-app",
script: "node_modules/next/dist/bin/next",
args: "start -p 3000",
instances: "max",
exec_mode: "cluster",
env: {
NODE_ENV: "production"
}
}
]
};Salutare. Am mutat recent un proiect de e-commerce cu vreo 15.000 de vizitatori unici pe lună de pe Vercel pe un VPS de 6 euro de la Hetzner. Facturile pe Vercel începuseră să sară de 120$ din cauza lătimii de bandă și a execuției de serverless functions, așa că am revenit la clasicul VPS.
Nu e fizică cuantică, dar dacă nu ești atent la câteva detalii, te trezești cu downtime la fiecare deploy sau cu SSD-ul plin de loguri în două luni. Iată cum am configurat totul să ruleze stabil și fără întreruperi.
Configurația PM2 pentru Zero Downtime
Mulți fac greșeala să ruleze Next.js direct cu npm run start în PM2. Problema e că dacă dai pm2 restart, aplicația se oprește complet timp de 2-3 secunde până când pornește noul proces Node.js. Utilizatorii tăi vor vedea o eroare 502 (Bad Gateway) în timpul ăsta.
Soluția este să folosești cluster mode. Am creat un fișier ecosystem.config.js în rădăcina proiectului. Acesta îi spune lui PM2 să ruleze mai multe instanțe ale aplicației și să le restarteze pe rând (rolling restart) când facem deploy.
Când facem deploy, rulăm pm2 reload ecosystem.config.js în loc de restart. PM2 va opri și va reporni instanțele pe rând, iar traficul va fi direcționat doar către instanțele care sunt deja active. Clientul final nu va simți nicio secundă de downtime.
Nginx ca Reverse Proxy și SSL cu Certbot
Next.js rulează acum intern pe portul 3000. Avem nevoie de Nginx în față ca să preia traficul de pe porturile standard HTTP (80) și HTTPS (443) și să-l trimită către instanțele noastre de Node.js.
Configurația de Nginx e simplă, dar e important să trimiți corect headerele de IP real către Next.js, altfel funcțiile de analiză, req.ip sau middleware-ul de geolocație vor vedea mereu adresa IP locală 127.0.0.1 a serverului.
După ce ai configurat blocul de server în Nginx, rulezi sudo certbot --nginx -d domeniul-tau.ro și ai rezolvat HTTPS-ul în mai puțin de un minut, cu reînnoirea certificatelor configurată automat prin cronjob.
Capcana în care cad mulți: Logurile care umplu SSD-ul
Am pățit-o acum vreo trei ani la un proiect cu trafic mare: m-a sunat clientul duminică dimineața că site-ul e complet blocat. Când m-am conectat prin SSH, comanda df -h arăta 100% disk usage. Logurile PM2 (out.log și err.log) ajunseseră la 42 GB și blocaseră sistemul de operare.
Nu lăsa PM2 să scrie loguri la nesfârșit în același fișier. Instalează modulul de logrotate pentru PM2 direct pe server:
pm2 install pm2-logrotate
Acesta vine preconfigurat să taie logurile când ating dimensiunea de 10MB și să păstreze doar ultimele 30 de fișiere, ștergându-le automat pe cele vechi. Îți salvează efectiv nopțile și weekendurile.
Trade-off-uri sincere
Configurația asta merge brici și am redus costurile cu peste 90%, dar vine cu un cost de mentenanță. Pierzi complet preview-urile automate la fiecare Pull Request pe care le aveai moca pe Vercel. De asemenea, trebuie să-ți scrii singur un pipeline simplu de CI/CD (în GitHub Actions) care să facă build-ul, să dea rsync la fișiere pe server și să ruleze comanda de reload.
Pentru proiecte mici sau medii unde bugetul contează, un VPS configurat corect este aur curat. Pentru echipe mari unde viteza de development și preview-urile instant sunt vitale, Vercel își merită în continuare banii.
Voi cum procedați când proiectele Next.js încep să consume prea multe resurse pe platformele serverless? Rămâneți pe Vercel sau treceți pe infrastructură proprie?