VPS pod Node.js i Next.js - PM2, Nginx, SSL, CI/CD
Opublikowano: 26 czerwca 2026 · Kategoria: VPS / Node.js
Szczegółowe porównanie planów VPS - parametry, ceny i ranking providerów - znajdziesz w artykule Jaki VPS wybrać?. Poniżej skupiamy się wyłącznie na konfiguracji Node.js i Next.js: process manager, reverse proxy, SSL i automatyczny deployment.
Dlaczego hosting współdzielony nie wystarcza dla Node.js?
Hosting współdzielony jest optymalny dla prostych stron i blogów - jeśli to wystarczy, sprawdź poradnik hostingu współdzielonego. Dla Node.js/Next.js potrzebny jest VPS, bo:
Aplikacja Node.js to serwer HTTP działający jako stały proces - nie skrypt PHP wywoływany per-request. Hosting współdzielony zazwyczaj nie pozwala uruchamiać trwałych procesów w tle i restartować ich po awarii.
Next.js 15 wymaga Node.js ≥18.18.0. Na VPS instalujesz dokładnie tę wersję, którą potrzebujesz - nvm lub fnm pozwalają zarządzać kilkoma wersjami jednocześnie. Na hostingu współdzielonym wersja Node.js jest narzucona przez providera.
Next.js SSR generuje strony na żądanie - każde zapytanie to praca procesora. PM2 cluster mode uruchamia tyle workerów ile masz vCPU, obsługując równoległe zapytania. Na hostingu współdzielonym zasoby CPU są ograniczone i dzielone z innymi.
PM2 - zarządzanie procesami Node.js na VPS
PM2 to najpopularniejszy process manager dla Node.js. Instaluje się globalnie przez npm, obsługuje restart po awarii, cluster mode i centralne logowanie.
PORT=3000 pm2 start .next/standalone/server.js --name "myapp"
pm2 save
Plik konfiguracyjny `ecosystem.config.js` pozwala zarządzać wieloma aplikacjami i zmiennymi środowiskowymi. Podstawowe komendy zarządzania: `pm2 status`, `pm2 logs myapp`, `pm2 reload myapp` (zero-downtime w cluster mode), `pm2 stop myapp`.
Alternatywa to systemd - wbudowany init system Linuxa. Tworzysz unit file `/etc/systemd/system/myapp.service`, definiujesz ExecStart, RestartSec i User. Zaletą jest głębsza integracja z systemem (logi przez journald, standardowe `systemctl start/stop`). Wadą - brak natywnego cluster mode dla wielu workerów (za to node ma cluster module).
Reverse proxy - Nginx i SSL z Let's Encrypt
Node.js nasłuchuje na wewnętrznym porcie (np. 3000) - Nginx jako reverse proxy odbiera ruch na 80/443 i przekazuje go do aplikacji. Daje to SSL, nagłówki bezpieczeństwa i możliwość obsługi wielu aplikacji na jednym VPS.
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
SSL przez Let's Encrypt instalujesz przez certbot: `apt install certbot python3-certbot-nginx`, potem `certbot --nginx -d example.com`. Certbot automatycznie edytuje konfigurację Nginxa i ustawia cron na odnawianie certyfikatu co 90 dni.
Caddy to alternatywa z automatycznym SSL bez certbota. Konfiguracja w Caddyfile jest
zwięźlejsza: example.com { reverse_proxy localhost:3000 } - Caddy sam pobiera certyfikat i odświeża go. Wygodny dla prostych konfiguracji, mniej dokumentacji
dla zaawansowanych scenariuszy niż Nginx.
Next.js standalone - minimalny bundle na VPS
Next.js 12.1+ obsługuje output: 'standalone' w next.config.js. Generuje minimalny bundle zawierający tylko potrzebne pliki - bez
node_modules.
const nextConfig = {
output: 'standalone',
}
# Wynikowe katalogi:
# .next/standalone/ - serwer z zależnościami
# .next/static/ - statyczne assety (CSS/JS)
# public/ - pliki publiczne
rsync -avz .next/static/ user@vps:/var/www/myapp/.next/static/
rsync -avz public/ user@vps:/var/www/myapp/public/
# Start:
cd /var/www/myapp
PORT=3000 node server.js
Standalone output znacznie zmniejsza czas deployu i zużycie dysku - brak 300 MB
node_modules w każdym deploymencie. Pamiętaj o przekopiowaniu zarówno
.next/static/ jak i
public/ - standalone nie zawiera ich wewnątrz bundla.
CI/CD - automatyczny deployment przez GitHub Actions
Typowy flow dla Next.js na VPS: push do `main` → GitHub Actions buduje aplikację → rsync na VPS → PM2 reload (zero-downtime w cluster mode).
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20 }
- run: npm ci && npm run build
- name: Deploy via rsync
run: |
rsync -avz .next/standalone/ ${{ secrets.VPS_USER }}@${{ secrets.VPS_HOST }}:/var/www/myapp/
rsync -avz .next/static/ ${{ secrets.VPS_USER }}@${{ secrets.VPS_HOST }}:/var/www/myapp/.next/static/
- name: Reload PM2
run: ssh ${{ secrets.VPS_USER }}@${{ secrets.VPS_HOST }} "pm2 reload myapp"
W GitHub Secrets dodajesz `VPS_HOST`, `VPS_USER` i `VPS_SSH_KEY` (klucz prywatny SSH). Klucz publiczny dodajesz do `~/.ssh/authorized_keys` na VPS. Ważne: akcja `webfactory/ssh-agent` lub `appleboy/ssh-action` upraszczają konfigurację klucza SSH w Actions.
Przy bardziej złożonych deploymentach warto rozważyć Dockera - build obrazu na CI, push do rejestru, pull na VPS i restart kontenera. Daje izolację środowiska i łatwy rollback (poprzedni tag obrazu). Konfigurację Dockera dla Node.js znajdziesz w artykule Docker na VPS.
Jakie parametry VPS dla Node.js i Next.js?
| Scenariusz | RAM (orient.) | vCPU | Uwagi |
|---|---|---|---|
| API/backend, mały ruch | 1-2 GB | 1-2 | Wystarczy PM2 single mode |
| Next.js SSR, umiarkowany ruch | 2-4 GB | 2-4 | PM2 cluster mode (-i max) |
| Next.js + PostgreSQL + Redis | 4-8 GB | 2-4 | Wszystko na jednym VPS |
| Duży ruch, wiele serwisów | 8 GB+ | 4+ | Rozważ Docker Compose |
Dysk NVMe przyspiesza build Next.js i operacje npm - szczególnie widoczne przy pierwszym `npm ci` na VPS. Dla aplikacji z bazą danych lokalnie: PostgreSQL i Redis zajmują orientacyjnie 1-2 GB RAM przy normalnym obciążeniu, co trzeba dodać do wymagań aplikacji. Użyj kalkulatora, żeby porównać plany.
Sprawdź oferty pasujące do tego scenariusza
Poniżej masz szybkie przejścia do ofert i stron z kodami rabatowymi tam, gdzie są dostępne.
Często zadawane pytania
Czy Next.js można hostować na zwykłym VPS?
Tak - VPS z 1-2 GB RAM wystarczy dla małej aplikacji Next.js. Dla SSR z większym ruchem warto mieć 2+ GB RAM i 2+ vCPU. PM2 cluster mode wykorzystuje wszystkie vCPU do obsługi równoległych zapytań.
PM2 czy systemd dla Node.js na VPS?
PM2 jest łatwiejszy w konfiguracji, ma cluster mode i centralne logowanie. systemd jest bardziej natywny dla Linuxa. Dla większości projektów Node.js polecamy PM2 jako punkt startowy - `pm2 startup && pm2 save` i autostart po reboocie gotowy.
Nginx czy Caddy jako reverse proxy dla Node.js?
Caddy automatycznie obsługuje SSL przez Let's Encrypt - prosta konfiguracja jedną linią. Nginx jest bardziej elastyczny przy zaawansowanych wymaganiach. Dla prostych konfiguracji Caddy jest szybszy do wdrożenia.
Jak skonfigurować CI/CD dla Next.js na VPS?
GitHub Actions: push → build → rsync na VPS → `pm2 reload`. Klucz SSH w GitHub Secrets. PM2 cluster mode z `pm2 reload` daje zero-downtime deployment. Alternatywa: Docker - build obrazu na CI, pull i restart na VPS.
Jak hostować Next.js standalone (output: standalone)?
Dodaj `output: 'standalone'` do next.config.js. Build generuje `.next/standalone/` z zależnościami. Na VPS kopiujesz standalone + `.next/static/` + `public/`, uruchamiasz `node server.js`. Brak 300 MB node_modules w deploymencie.