eduardweb.
DeploymentIntermediar#nextjs#deployment#pm2#nginx#vps

Next.js pe VPS: PM2, Nginx și cum să nu-ți umpli SSD-ul cu loguri

De Andreea Crăciun, 1 mai 2026 · 2 vizualizări · 3 like-uri

Postat acum 1 zi
javascript
module.exports = {
  apps: [
    {
      name: 'my-next-app',
      script: 'node_modules/next/dist/bin/next',
      args: 'start -p 3000',
      instances: 'max',
      exec_mode: 'cluster',
      autorestart: true,
      watch: false,
      max_memory_restart: '1G',
      env: {
        NODE_ENV: 'production',
      },
    },
  ],
};

Vercel e grozav, n-am ce zice. Apeși un buton și ești online. Dar când proiectul crește sau când ai 10 aplicații mici care încep să te coste 20$ bucata, începi să te uiți cu drag la un VPS de la DigitalOcean sau Hetzner. Am avut recent cazul unui client care plătea aproape 200$ pe lună pe serverless, iar după ce l-am mutat pe un singur VPS de 15$, performanța a rămas identică, dar am salvat 90% din costuri.

Nu e fizică cuantică, dar sunt câteva detalii unde poți să o dai în bară dacă nu ești atent. Cel mai des văd oameni care pornesc aplicația cu npm start direct în terminal și se miră de ce pică site-ul când închid consola. Sau, mai rău, uită de loguri și se trezesc cu SSD-ul plin în două săptămâni.

PM2 pentru liniștea ta sufletească

PM2 e standardul de facto aici. Nu-l folosi doar ca să pornești procesul, fă-ți un fișier ecosystem.config.js. De ce? Pentru că vrei să gestionezi variabilele de mediu și să ai instanțe multiple. La un proiect cu vreo 8k useri activi, am setat instances: 'max' și am observat o reducere a timpului de răspuns cu vreo 15%, pur și simplu pentru că Node profita de toate nucleele procesorului.

Trade-off-ul aici e memoria. Dacă ai un VPS mic, de 1GB RAM, nu pune max că o să crape tot din cauza OOM (Out of Memory). Rămâi la o singură instanță sau maxim două.

Nginx și HTTPS fără bătăi de cap

Nginx stă în față și face tot „heavy lifting-ul” pentru SSL și buffering. Configurația de proxy e destul de standard, dar nu uita să adaugi headerele pentru IP-ul real al clientului. Altfel, în logurile aplicației tale, toți vizitatorii o să pară că vin de la 127.0.0.1.

Pentru HTTPS, Certbot e sfânt. Rulezi o comandă și ai terminat. Totuși, am pățit ca reînnoirea automată să dea fail pentru că portul 80 era blocat de un firewall uitat. Verifică mereu că certbot renew --dry-run trece cu succes imediat după ce ai configurat totul.

Problema logurilor (care umplu discul)

Aici e buba unde mulți juniori se ard. Next.js și PM2 scot loguri constant. Dacă ai trafic serios, fișierul out.log poate să ajungă la câțiva giga în câteva zile. Am avut un proiect unde am găsit un log de 40GB care omorâse tot serverul.

Soluția e pm2-logrotate. E un modul care vine separat și face exact ce zice: taie logurile la o anumită dimensiune și păstrează doar ultimele X fișiere. E genul de chestie „set and forget” care te scapă de un telefon la 3 dimineața că site-ul e jos.

Deployment-ul propriu-zis

Eu prefer să fac git pull și npm run build direct pe server pentru proiecte mici, deși unii zic că e „bad practice”. Trade-off-ul e că în timpul build-ului, procesorul sare la 100% și RAM-ul se consumă rapid, deci site-ul ar putea să se miște greu timp de 30 de secunde. Dacă ai un proiect gigant, fă build-ul în CI (GitHub Actions) și urcă doar folderul .next și node_modules pe server prin rsync.

În final, VPS-ul îți dă control total, dar vine cu responsabilitatea mentenanței. Voi ce preferați? Confortul de la Vercel/Netlify sau controlul (și prețul) unui VPS configurat manual?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.