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.