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'
}
}
]
};Vercel e mișto până când îți vine prima factură serioasă sau când clientul vrea neapărat datele pe un server local din România. Am mutat recent un proiect cu 12.000 de utilizatori unici pe lună de pe Vercel pe un VPS de 5 euro de la Hetzner și totul rulează brici. Îți arăt exact setup-ul meu de producție pe care îl folosesc de vreo trei ani fără probleme de downtime.
De ce VPS și care e compromisul?
Să fim sinceri. Pe Vercel dai un git push și ai uitat de el. Pe VPS, tu ești sysadmin-ul. Dacă pică baza de date la ora 3 dimineața, tot tu te trezești. Dar pentru proiecte medii, unde nu ai nevoie de serverless functions care să scaleze la infinit, un VPS e de zece ori mai ieftin și mult mai predictibil ca preț.
Plătești o sumă fixă pe lună și ai resurse dedicate. Partea proastă e că trebuie să configurezi manual procesele, proxy-ul și SSL-ul. Dar odată ce ai un template de configurare, îți ia fix 15 minute să ridici un proiect nou.
PM2 în mod cluster pentru zero downtime
Dacă rulezi doar npm start, aplicația ta va rula pe un singur thread. Dacă dă crash o singură rută din cauza unui bug ascuns, tot site-ul e jos până când repornește procesul.
Soluția este PM2 rulat în mod cluster. Acesta va porni mai multe instanțe ale aplicației tale (de regulă, câte nuclee are procesorul tău) și va face load-balancing între ele. Când faci un deployment nou, în loc de pm2 restart, folosești pm2 reload. Comanda asta repornește instanțele pe rând. În timp ce instanța A se oprește și încarcă noul cod, instanța B preia tot traficul. Utilizatorul nu simte nimic.
Nginx ca reverse proxy
Next.js nu ar trebui niciodată să fie expus direct în internet pe portul 3000. Nu e treaba lui să facă SSL termination sau să servească fișiere statice la performanță maximă. Pentru asta punem Nginx în față.
Configurația de Nginx trebuie să trimită toate request-urile către portul local unde rulează PM2. Nu uita să adaugi headerele corecte pentru IP-ul real al clientului (X-Real-IP și X-Forwarded-For), altfel în logurile Next.js o să vezi doar 127.0.0.1 la toți vizitatorii.
După ce Nginx e sus, rulezi sudo certbot --nginx și ai SSL moca în 2 minute. Certbot își configurează singur reînnoirea automată printr-un cron job, deci nu-ți mai bați capul cu certificatele expirate.
Logurile și capcana hard disk-ului plin
Am pățit-o la un proiect mai vechi. Totul mergea perfect, până când într-o dimineață am primit alertă că baza de date e blocată. Motivul? PM2 scria fiecare request în ~/.pm2/logs/app-out.log. În 6 luni, logurile au adunat 45 GB și au umplut tot SSD-ul serverului.
Nu lăsa logurile să crească la infinit. Folosește logrotate din Ubuntu sau modulul intern pm2-logrotate. Eu prefer să las PM2 să scrie în fișiere, iar serviciul de logrotate din sistem să se ocupe de comprimarea lor zilnică și ștergerea celor mai vechi de 14 zile. E sfânt.
Voi unde vă țineți proiectele de Next.js când Vercel devine prea scump? Rămâneți pe VPS clasic sau ați trecut pe chestii gen Coolify?