name: Deploy Next.js to VPS
on:
push:
branches: [ main ]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run Lint & Tests
run: |
npm run lint
# npm run test --if-present
- name: Build application
run: npm run build
env:
NEXT_PUBLIC_API_URL: https://api.siteul-tau.ro
- name: Deploy to VPS via SSH
uses: appleboy/scp-action@v0.1.7
with:
host: ${{ secrets.SSH_HOST }}
username: ${{ secrets.SSH_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
source: ".next/,public/,package.json,package-lock.json,next.config.js"
target: "/var/www/my-next-app/tmp"
- name: Post-deploy setup on VPS
uses: appleboy/ssh-action@v1.0.3
with:
host: ${{ secrets.SSH_HOST }}
username: ${{ secrets.SSH_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
cd /var/www/my-next-app
# Mutam fisierele din folderul temporar
rsync -avz tmp/ .
rm -rf tmp
# Instalam doar dependintele de productie
npm ci --omit=dev
# Restartam aplicatia fara downtime
pm2 reload my-next-app || pm2 start npm --name "my-next-app" -- startSalutare. Am tot văzut oameni care se complică inutil cu Vercel pentru proiecte medii sau care dau banii pe resurse scumpe când au deja un VPS de 5 euro cumpărat. Azi vă arăt pipeline-ul de GitHub Actions pe care îl folosesc la un SaaS de-al meu cu vreo 12.000 de utilizatori activi lunar, care face totul cap-coadă: verificări, build și deploy direct prin SSH.
Nu e fizică nucleară, dar sunt câteva detalii care vă pot salva de la downtime sau de la servere blocate din cauza lipsei de RAM.
Trade-off-ul sincer: VPS vs. Vercel
Hai să fim realiști de la început. Vercel e genial pentru DX (Developer Experience). Ai preview deployments la fiecare PR și totul merge din trei click-uri.
Dar când ai baze de date mari, joburi pe fundal și trafic constant, treci repede de pragul lor gratuit. Pe VPS-ul tău ai control total, dar trebuie să-ți configurezi singur securitatea, SSL-ul (cu Caddy sau Nginx) și deployment-ul. Merge excelent pentru bugete mici și control total, dar e destul de nasol dacă ai nevoie de preview deployments automate pentru fiecare branch. Acolo chiar trebuie să muncești mult la scripturi ca să emulezi ce face Vercel nativ.
De ce facem build-ul pe GitHub și nu direct pe VPS?
Am văzut mulți devi care dau git pull pe VPS și apoi rulează npm run build direct acolo. Să nu faceți asta niciodată în producție.
Next.js mănâncă foarte multe resurse (în special RAM) în timpul build-ului de webpack/turbopack. Dacă ai un VPS ieftin cu 1GB sau 2GB RAM, procesul de build îți va bloca serverul, va genera OOM (Out Of Memory) și site-ul tău va fi picat câteva minute bune la fiecare deploy.
Soluția? Facem build-ul pe mașina virtuală gratuită de la GitHub (care are vreo 7GB RAM), arhivăm rezultatul (.next, public, package.json, node_modules) și trimitem doar fișierele gata compilate pe VPS prin SSH/rsync. Am economisit cam 30% la build time doar structurând cache-ul corect.
Cum gestionăm zero-downtime cu PM2
Pe server rulăm Next.js în mod standalone folosind PM2. Când facem deploy, scriptul nostru de pe server va dezarhiva noul build într-un folder temporar, va schimba symlink-ul către folderul curent de producție și va da un reload la PM2.
Folosim pm2 reload în loc de pm2 restart. Diferența e masivă: reload repornește procesele pe rând, menținând aplicația online fără nicio secundă de downtime pentru utilizatori.
Înainte de a rula pipeline-ul, asigură-te că ai adăugat secretele în GitHub: SSH_PRIVATE_KEY (cheia ta privată), SSH_HOST (IP-ul serverului) și SSH_USER (de regulă root sau un user dedicat cu drepturi de scriere).