1. [Strona główna](/) › 2. [Baza wiedzy](/baza-wiedzy/) › 3. VPS pod Node.js i Next.js # VPS pod Node.js i Next.js — PM2, Nginx, SSL, CI/CD Opublikowano: 26 czerwca 2026 · Kategoria: VPS / Node.js ⚡ W skrócie · 8 min czytania - Dlaczego hosting współdzielony nie wystarcza dla Node.js. - PM2 vs systemd — zarządzanie procesami Node.js na VPS. - Nginx i Caddy jako reverse proxy — konfiguracja z SSL. - Deployment Next.js standalone — minimalny bundle na VPS. - CI/CD przez GitHub Actions — zero-downtime deploy. Szczegółowe porównanie planów VPS — parametry, ceny i ranking providerów — znajdziesz w artykule [Jaki VPS wybrać?](/jaki-vps-wybrac/). 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](/jaki-hosting-wybrac/). Dla Node.js/Next.js potrzebny jest VPS, bo: ⚡ **Node.js to długo żyjący proces** 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. 🔧 **Kontrola nad wersją Node.js i zależnościami** 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. 📈 **SSR i obsługa równoległych zapytań** 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. \# Instalacja PM2 npm install -g pm2 \# Start aplikacji Next.js (standalone) cd /var/www/myapp PORT=3000 pm2 start .next/standalone/server.js --name "myapp" \# Cluster mode — wykorzystaj wszystkie vCPU pm2 start .next/standalone/server.js --name "myapp" -i max \# Autostart po reboocie pm2 startup 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. \# /etc/nginx/sites-available/myapp server { 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`. // next.config.js — włącz standalone output /\*\* @type {import('next').NextConfig} \*/ const nextConfig = { output: 'standalone', } \# Lokalnie: build i spakowanie do transferu npm run build \# Wynikowe katalogi: \# .next/standalone/ — serwer z zależnościami \# .next/static/ — statyczne assety (CSS/JS) \# public/ — pliki publiczne \# Na VPS: rsync -avz .next/standalone/ user@vps:/var/www/myapp/ 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). \# .github/workflows/deploy.yml (skrót) on: 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](/baza-wiedzy/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](/kalkulator/), ż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. Contabo VPS z dużą ilością RAM dla Node.js/Next.js i baz danych — dobry stosunek ceny Dobra cena/RAM [Aktywuj rabat →](/out/contabo/#reklama "Contabo") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/contabo) ProSerwer VPS KVM w Polsce — niskie opóźnienie dla użytkowników z Polski, root SSH KVM Polska [Aktywuj rabat →](/out/proserwer-pl/#reklama "ProSerwer") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/proserwer) Mikrus Tanie VPS w Polsce — dobry start dla projektów Node.js i testowania Tanie VPS [Aktywuj rabat →](/out/mikrus/#reklama "Mikrus") #Reklama · link partnerski [Zobacz kod rabatowy →](/kody-rabatowe/mikrus) ## 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. ## Powiązane strony - [Jaki VPS wybrać? Kompletny poradnik wyboru VPS — parametry, koszty, ranking providerów. ](/jaki-vps-wybrac/) - [VPS dla aplikacji AI Ollama, RAG, self-hosted LLM — wymagania RAM/CPU i konfiguracja. ](/baza-wiedzy/vps-dla-aplikacji-ai/) - [Docker na VPS Instalacja Docker CE, Compose i uruchamianie kontenerów. ](/baza-wiedzy/docker-na-vps/) - [PostgreSQL na VPS Instalacja, zabezpieczanie i optymalizacja PostgreSQL na VPS. ](/baza-wiedzy/postgresql-vps-instalacja-konfiguracja/) - [Ranking VPS Porównanie planów VPS z filtrami RAM, vCPU i kosztami. ](/vps/) Autor: [Adam Nadolny](/autorzy/adam-nadolny) Ekspert DevOps i infrastruktury · Zweryfikowano Czerwiec 2026 Administruje własnymi serwerami VPS i dedykowanymi, testując konfiguracje pod realnym obciążeniem — nie w sandboxie. W HostGrade.pl buduje bazę wiedzy DevOps: przewodniki po konfiguracji Nginx, Dockera, Redis i backupów serwerowych pisane na podstawie realnych deploymentów. Porównuje parametry techniczne planów VPS: gwarantowane vCPU kontra shared core, przepustowość sieci i IOPS dysków NVMe. Specjalizuje się w hardening serwera Linux — od fail2ban przez iptables po audyty CIS Benchmark. Każdy artykuł techniczny przechodzi przez środowisko testowe: konfiguracja Redis Cluster, setup HAProxy czy skrypt backup z BorgBackup są uruchamiane przed publikacją. Wierzy, że dobry tutorial kończy się komendą, której wynik faktycznie działa. [Pełny profil autora →](/autorzy/adam-nadolny)