Strona oparta na Next.js lub Node.js nie działa tak samo jak klasyczna witryna HTML albo prosty WordPress.
Nie wystarczy skopiować plików na serwer i wskazać domeny.
Aplikacja może wymagać stale działającego procesu, własnego backendu, bazy danych, zadań automatycznych, zmiennych środowiskowych, mechanizmu cache, kolejek oraz monitoringu wielu niezależnych usług.
Dlatego wybór hostingu dla Next.js i Node.js powinien wynikać z architektury projektu, a nie wyłącznie z ceny pakietu.
Środowisko musi być przygotowane tak, aby aplikacja:
- działała stabilnie,
- uruchamiała się po restarcie serwera,
- bezpiecznie przechowywała dane,
- posiadała aktualne kopie,
- była monitorowana,
- mogła być rozwijana bez niepotrzebnych przestojów.
Czym różni się hosting aplikacji od hostingu zwykłej strony?
Prosta strona może składać się z gotowych plików HTML, CSS, JavaScript i obrazów.
Serwer wysyła je użytkownikowi bez konieczności uruchamiania rozbudowanej aplikacji po stronie backendu.
Projekt Next.js lub Node.js może natomiast posiadać:
- rendering po stronie serwera,
- własne API,
- logowanie użytkowników,
- panel administracyjny,
- bazę danych,
- przetwarzanie formularzy,
- generowanie dokumentów,
- integracje zewnętrzne,
- procesy wykonywane w tle,
- system płatności,
- obsługę rezerwacji.
W takim przypadku serwer nie przechowuje wyłącznie plików. Aktywnie wykonuje kod oraz komunikuje się z innymi usługami.
Awaria jednego elementu może wpłynąć na działanie całego systemu.
Czy Next.js wymaga własnego serwera?
Nie zawsze.
Next.js może zostać uruchomiony na kilka sposobów.
Projekt może być:
- statycznie wygenerowany,
- renderowany po stronie serwera,
- uruchomiony jako aplikacja Node.js,
- wdrożony w środowisku serverless,
- hostowany na własnym VPS.
Prosta strona wygenerowana statycznie może działać na podstawowym hostingu plików.
Aplikacja wykorzystująca:
- Server-Side Rendering,
- API Routes,
- autoryzację,
- dynamiczne dane,
- połączenie z bazą,
potrzebuje środowiska zdolnego do uruchomienia procesu Node.js lub platformy obsługującej takie aplikacje.
Wybór zależy więc nie od samego użycia Next.js, ale od sposobu działania projektu.
Czy zwykły hosting współdzielony obsłuży Node.js?
Niektóre pakiety hostingowe oferują obsługę Node.js.
Może ona jednak posiadać ograniczenia dotyczące:
- wersji środowiska,
- czasu działania procesu,
- dostępnych portów,
- pamięci RAM,
- liczby procesów,
- dostępu SSH,
- zadań wykonywanych w tle,
- konfiguracji reverse proxy.
Dla niewielkiej aplikacji takie rozwiązanie może wystarczyć.
W bardziej rozbudowanym projekcie może szybko stać się ograniczeniem.
Jeżeli aplikacja wymaga własnego backendu, bazy danych, Redis, kolejek lub procesów typu worker, najczęściej lepszym rozwiązaniem będzie zarządzany VPS.
Różnice pomiędzy środowiskami opisaliśmy w artykule [VPS czy hosting współdzielony – co wybrać dla firmy](/blog/vps-czy-hosting-wspoldzielony-co-wybrac-dla-firmy).
VPS dla aplikacji Next.js i Node.js
VPS daje możliwość skonfigurowania środowiska dokładnie pod projekt.
Na serwerze można uruchomić:
- frontend Next.js,
- backend NestJS lub Express,
- bazę danych,
- Redis,
- procesy PM2,
- zadania cron,
- kolejki,
- reverse proxy,
- osobne środowiska produkcyjne i testowe.
Nie oznacza to jednak, że każdy VPS będzie właściwym wyborem.
Serwer musi posiadać odpowiednie zasoby oraz zostać prawidłowo zabezpieczony.
Sam zakup maszyny wirtualnej nie zapewnia:
- konfiguracji,
- aktualizacji,
- SSL,
- kopii,
- monitoringu,
- reakcji na awarie.
VPS jest fundamentem infrastruktury, ale nie jest gotową usługą utrzymania aplikacji.
Jakie zasoby powinien mieć serwer?
Wymagania zależą od:
- liczby użytkowników,
- ruchu,
- sposobu renderowania,
- liczby procesów,
- wielkości bazy danych,
- rodzaju integracji,
- częstotliwości zadań automatycznych,
- ilości przetwarzanych danych.
Podstawowe parametry to:
Procesor
Procesor odpowiada między innymi za wykonywanie kodu, generowanie stron, przetwarzanie zapytań oraz zadania wykonywane w tle.
Większe zapotrzebowanie mogą generować:
- rendering SSR,
- generowanie dokumentów,
- importy,
- przetwarzanie obrazów,
- raporty,
- synchronizacje.
Pamięć RAM
Pamięć wykorzystują:
- system operacyjny,
- procesy Node.js,
- baza danych,
- Redis,
- serwer WWW,
- procesy dodatkowe.
Zbyt mała ilość pamięci może powodować:
- regularne restarty,
- błędy 502,
- zatrzymywanie procesów,
- spadki wydajności,
- problemy podczas buildów.
Dysk
Ważna jest nie tylko pojemność, ale również szybkość operacji.
Aplikacja może przechowywać:
- pliki użytkowników,
- logi,
- buildy,
- kopie,
- dane bazy,
- pliki tymczasowe.
Szybki dysk NVMe może poprawić działanie bazy oraz operacji wykonywanych na plikach.
Frontend i backend na jednym serwerze czy osobno?
W mniejszym projekcie frontend, backend i baza mogą działać na jednym VPS.
Upraszczają to:
- konfigurację,
- kopie,
- wdrożenia,
- koszty.
Wraz z rozwojem systemu można rozdzielić poszczególne elementy.
Przykładowa architektura może obejmować:
- osobny frontend,
- osobne API,
- niezależną bazę danych,
- Redis,
- oddzielny magazyn plików,
- dodatkowy worker.
Rozdzielenie usług zwiększa możliwości skalowania i izolacji, ale również podnosi złożoność oraz koszt utrzymania.
Nie warto tworzyć rozbudowanej infrastruktury bez realnej potrzeby.
Dobra architektura powinna być wystarczająca dla obecnego projektu i umożliwiać późniejszy rozwój.
Rola Nginx jako reverse proxy
Aplikacja Node.js zwykle nasłuchuje na wewnętrznym porcie, na przykład 3000 lub 4000.
Nie powinna być bezpośrednio wystawiona do internetu bez odpowiedniej warstwy pośredniczącej.
Nginx może odpowiadać za:
- obsługę domeny,
- certyfikat SSL,
- przekazywanie ruchu do aplikacji,
- przekierowania,
- kompresję,
- limity zapytań,
- obsługę statycznych zasobów.
Schemat może wyglądać następująco:
1. użytkownik otwiera domenę,
2. ruch trafia do Nginx,
3. Nginx przekazuje żądanie do aplikacji,
4. aplikacja zwraca odpowiedź,
5. Nginx wysyła ją użytkownikowi.
Jeżeli aplikacja nie działa albo używa innego portu niż wskazany w konfiguracji, użytkownik może zobaczyć błąd 502.
Tego typu awarie opisaliśmy w poradniku [błąd 500 lub 502 na stronie – co oznacza i jak go naprawić](/blog/blad-500-lub-502-na-stronie-co-oznacza-i-jak-naprawic).
PM2 i utrzymanie procesów Node.js
Proces aplikacji może zatrzymać się z powodu:
- błędu,
- braku pamięci,
- restartu serwera,
- nieudanego wdrożenia,
- problemu z bazą.
Dlatego aplikacje Node.js często uruchamia się przez menedżer procesów, taki jak PM2.
PM2 może:
- utrzymywać aplikację aktywną,
- automatycznie ją restartować,
- uruchomić proces po restarcie serwera,
- przechowywać logi,
- pokazywać liczbę restartów,
- monitorować wykorzystanie zasobów.
Automatyczny restart nie rozwiązuje jednak każdej przyczyny.
Jeżeli proces regularnie się zatrzymuje, trzeba sprawdzić logi i ustalić źródło problemu.
System, który restartuje się kilkadziesiąt razy dziennie, nie jest stabilny tylko dlatego, że po chwili ponownie odpowiada.
Zmienne środowiskowe i sekrety
Aplikacja może potrzebować danych takich jak:
- adres bazy,
- hasło do bazy,
- klucz JWT,
- konfiguracja SMTP,
- klucze API,
- dane operatora płatności,
- adres Redis,
- klucze usług zewnętrznych.
Takich wartości nie należy umieszczać bezpośrednio w publicznym kodzie ani repozytorium.
Powinny być przechowywane jako zmienne środowiskowe z odpowiednio ograniczonym dostępem.
Ważne jest również rozdzielenie konfiguracji dla:
- środowiska lokalnego,
- środowiska testowego,
- produkcji.
Przypadkowe użycie klucza produkcyjnego w środowisku testowym może prowadzić do wysyłania prawdziwych wiadomości, wykonywania płatności lub modyfikacji danych klientów.
Baza danych dla aplikacji firmowej
Aplikacje Node.js często korzystają z:
- PostgreSQL,
- MySQL,
- MariaDB,
- MongoDB.
Baza może działać na tym samym serwerze lub w osobnej usłudze.
Trzeba zadbać o:
- bezpieczne dane dostępowe,
- ograniczenie dostępu z sieci,
- regularne kopie,
- aktualizacje,
- monitoring,
- indeksy,
- kontrolę liczby połączeń.
Baza nie powinna być publicznie dostępna bez wyraźnej potrzeby.
Najbezpieczniejszym rozwiązaniem jest ograniczenie dostępu do aplikacji i wybranych adresów administracyjnych.
Połączenia z bazą danych
Każde żądanie aplikacji może wymagać kontaktu z bazą.
Niewłaściwa konfiguracja puli połączeń może powodować:
- przekroczenie limitu połączeń,
- spowolnienia,
- timeouty,
- błędy aplikacji.
Problem może pojawiać się szczególnie podczas:
- skoków ruchu,
- wielu procesów aplikacji,
- nieprawidłowego zamykania połączeń,
- wdrożeń serverless,
- ciężkich raportów.
Monitoring powinien obejmować nie tylko dostępność bazy, ale również liczbę aktywnych połączeń oraz wolne zapytania.
Redis i cache
Redis może być wykorzystywany do:
- cache,
- przechowywania sesji,
- kolejek,
- blokad,
- limitowania żądań,
- tymczasowych danych.
Nie każda aplikacja go potrzebuje.
Jeżeli jednak projekt posiada wiele procesów albo wymaga szybkiej współdzielonej pamięci, Redis może poprawić wydajność i stabilność.
Usługa powinna być:
- zabezpieczona,
- niedostępna publicznie,
- objęta monitoringiem,
- skonfigurowana z odpowiednimi limitami pamięci.
Pozostawienie Redis otwartego do internetu jest poważnym błędem bezpieczeństwa.
Kolejki i zadania wykonywane w tle
Nie każda operacja powinna być wykonywana podczas oczekiwania użytkownika.
Do kolejki można przenieść:
- wysyłkę wiadomości,
- generowanie dokumentów,
- import danych,
- synchronizacje,
- przetwarzanie obrazów,
- powiadomienia,
- raporty.
Dzięki temu użytkownik szybciej otrzymuje odpowiedź, a ciężkie zadanie wykonuje się niezależnie.
Kolejka wymaga jednak osobnego procesu typu worker.
Monitoring powinien sprawdzać:
- czy worker działa,
- ile zadań czeka,
- czy pojawiają się błędy,
- czy kolejka nie rośnie zbyt szybko.
Aplikacja może działać poprawnie na froncie, ale procesy biznesowe mogą być zatrzymane z powodu niedziałającego workera.
Zadania cron
Cron może uruchamiać regularne procesy:
- raporty,
- synchronizacje,
- czyszczenie danych,
- publikacje,
- przypomnienia,
- backupy.
Sam wpis w harmonogramie nie gwarantuje, że zadanie się wykonało.
Warto kontrolować:
- czas ostatniego uruchomienia,
- wynik,
- długość wykonania,
- błędy,
- brak zakończenia.
Monitoring zadań automatycznych opisaliśmy szerzej w artykule [monitoring strony internetowej 24/7 – co naprawdę powinien sprawdzać](/blog/monitoring-strony-internetowej-24-7-co-powinien-sprawdzac).
Certyfikat SSL
Każda aplikacja firmowa powinna działać przez HTTPS.
SSL chroni dane przesyłane pomiędzy użytkownikiem a serwerem.
Jest szczególnie ważny przy:
- logowaniu,
- formularzach,
- płatnościach,
- panelach klientów,
- API.
Certyfikat może być odnawiany automatycznie, ale proces powinien być monitorowany.
Wygasły SSL może całkowicie zablokować użytkownikom dostęp albo zerwać integracje wykorzystujące bezpieczne połączenie.
Firewall i dostęp SSH
VPS powinien posiadać zaporę sieciową.
Publicznie dostępne powinny być wyłącznie potrzebne usługi, najczęściej:
- HTTP,
- HTTPS,
- zabezpieczony dostęp administracyjny.
Baza danych, Redis i wewnętrzne porty aplikacji nie powinny być otwarte bez potrzeby.
Dostęp SSH warto zabezpieczyć przez:
- logowanie kluczem,
- wyłączenie prostych haseł,
- ograniczenie dostępu root,
- blokowanie powtarzających się prób,
- aktualizacje systemu.
Bezpieczeństwo nie polega na zainstalowaniu jednego programu. To połączenie konfiguracji, aktualizacji, monitoringu i ograniczania dostępu.
Backup aplikacji Next.js i Node.js
Kopia aplikacji powinna obejmować więcej niż repozytorium kodu.
Kod można odtworzyć z Git, ale nadal trzeba zabezpieczyć:
- bazę danych,
- pliki użytkowników,
- zmienne środowiskowe,
- konfigurację serwera,
- ustawienia procesów,
- zadania cron,
- konfigurację proxy.
Backup powinien być:
- regularny,
- automatyczny,
- przechowywany poza głównym serwerem,
- objęty monitoringiem,
- możliwy do odtworzenia.
Zasady prawidłowych kopii opisaliśmy w artykule [kopie zapasowe strony – jak często je wykonywać i gdzie przechowywać](/blog/kopie-zapasowe-strony-jak-czesto-i-gdzie-przechowywac).
Kopie bazy danych
Częstotliwość kopii bazy zależy od liczby zmian.
Aplikacja, w której użytkownicy codziennie tworzą rezerwacje, zamówienia lub dokumenty, może wymagać częstszych backupów niż zwykła strona firmowa.
Trzeba określić:
- ile danych można utracić,
- jak szybko system powinien wrócić do działania,
- jak długo przechowywać wersje,
- gdzie trzymać backup.
Kopia bazy raz dziennie może oznaczać utratę zmian z ostatnich 24 godzin.
Dla aktywnej aplikacji może to być nieakceptowalne.
Monitoring aplikacji
Monitoring powinien obejmować kilka warstw:
Frontend
Czy strona otwiera się i zwraca prawidłowy kod?
Backend
Czy API odpowiada i zwraca poprawne dane?
Procesy
Czy aplikacja i workery są aktywne?
Baza danych
Czy połączenie działa, a zapytania nie są nadmiernie wolne?
Serwer
Czy nie kończy się RAM, procesor lub miejsce na dysku?
Backup
Czy ostatnia kopia została wykonana poprawnie?
SSL
Czy certyfikat jest ważny i odnawia się automatycznie?
Samo sprawdzanie strony głównej nie daje pełnej informacji o działaniu systemu.
Endpoint health check
Aplikacja może posiadać specjalny endpoint techniczny, na przykład:
`/api/health`
Może on sprawdzać:
- działanie procesu,
- połączenie z bazą,
- Redis,
- kolejkę,
- magazyn plików.
Endpoint nie powinien ujawniać poufnych danych.
Jego zadaniem jest zwrócenie prostego statusu pozwalającego systemowi monitorującemu ocenić stan aplikacji.
Health check ułatwia odróżnienie problemu frontendu od awarii backendu lub bazy.
Logi aplikacji
Logi są podstawowym źródłem informacji podczas awarii.
Powinny zawierać:
- czas zdarzenia,
- typ błędu,
- nazwę usługi,
- kontekst techniczny,
- identyfikator żądania.
Nie powinny natomiast przechowywać:
- pełnych haseł,
- kluczy API,
- danych kart,
- poufnych tokenów,
- nadmiarowych danych osobowych.
Logi powinny być rotowane.
Jeżeli rosną bez ograniczeń, mogą zapełnić dysk i doprowadzić do awarii całego serwera.
Środowisko testowe
Zmiany w aplikacji firmowej nie powinny być testowane wyłącznie na produkcji.
Środowisko testowe pozwala sprawdzić:
- nowy build,
- migrację bazy,
- aktualizację bibliotek,
- zmianę Node.js,
- integrację,
- nową funkcję.
Powinno być:
- oddzielone od produkcji,
- zabezpieczone przed dostępem publicznym,
- zablokowane przed indeksowaniem,
- pozbawione prawdziwych kluczy produkcyjnych, jeżeli nie są potrzebne.
Publikowanie zmian bez testów zwiększa ryzyko przerwy w działaniu systemu.
Bezpieczne wdrożenie aplikacji
Najprostsze wdrożenie może polegać na:
1. pobraniu nowego kodu,
2. instalacji zależności,
3. wykonaniu buildu,
4. restarcie procesu.
Ważne jest jednak, aby posiadać:
- backup,
- log wdrożenia,
- test po uruchomieniu,
- możliwość powrotu do poprzedniej wersji,
- kontrolę migracji bazy.
Jeżeli build nie powiedzie się, stara wersja powinna nadal działać.
Nie warto usuwać aktywnej aplikacji przed sprawdzeniem, czy nowa wersja została poprawnie zbudowana.
Migracje bazy danych
Nowa wersja aplikacji może wymagać zmiany struktury bazy.
Migracja powinna być:
- przygotowana wcześniej,
- przetestowana,
- wykonana po backupie,
- zgodna z wdrażaną wersją kodu.
Niektóre zmiany są trudne do cofnięcia.
Dlatego wdrożenie musi uwzględniać kolejność:
1. backup,
2. migracja,
3. nowy kod,
4. test działania,
5. monitoring.
Automatyzacja wdrożeń
W bardziej rozwiniętym projekcie warto wdrożyć proces CI/CD.
Może on automatycznie:
- uruchamiać testy,
- budować aplikację,
- sprawdzać jakość kodu,
- przygotowywać wersję,
- wdrażać po zatwierdzeniu.
Automatyzacja ogranicza liczbę ręcznych błędów, ale nie oznacza, że każde wdrożenie powinno automatycznie trafiać na produkcję.
W systemach biznesowych warto zachować etap kontroli i możliwość szybkiego wycofania wersji.
Skalowanie aplikacji
Jeżeli ruch rośnie, można zwiększyć:
- zasoby VPS,
- liczbę procesów,
- liczbę serwerów,
- wydajność bazy,
- cache,
- niezależne workery.
Nie każda aplikacja od początku potrzebuje skomplikowanego skalowania.
Dla większości młodych projektów lepszy jest dobrze skonfigurowany pojedynczy VPS z monitoringiem niż rozbudowana infrastruktura, której nikt nie potrafi później utrzymać.
Skalowanie powinno wynikać z pomiarów:
- wykorzystania procesora,
- pamięci,
- czasu odpowiedzi,
- liczby użytkowników,
- wydajności bazy.
VPS czy platforma chmurowa?
Platformy chmurowe mogą uprościć wdrażanie aplikacji.
Często oferują:
- automatyczne buildy,
- integrację z repozytorium,
- skalowanie,
- zarządzane certyfikaty,
- logi.
Mogą jednak posiadać:
- limity,
- rosnące koszty,
- ograniczoną kontrolę,
- zależność od konkretnego dostawcy.
VPS daje większą kontrolę i przewidywalność kosztów, ale wymaga administracji.
Wybór powinien zależeć od:
- kompetencji zespołu,
- skali projektu,
- budżetu,
- potrzeb konfiguracyjnych,
- planowanego rozwoju.
Ile kosztuje hosting aplikacji Node.js?
Koszt składa się z kilku elementów:
- serwera,
- administracji,
- bazy danych,
- backupów,
- monitoringu,
- dodatkowych usług,
- pracy przy wdrożeniach.
Mała aplikacja może działać na niedużym VPS.
System biznesowy obsługujący wielu użytkowników będzie wymagał większych zasobów i szerszej opieki.
Nie należy porównywać ceny hostingu aplikacji do najtańszego pakietu dla strony-wizytówki.
Aplikacja posiada więcej elementów, które muszą działać i być nadzorowane.
Koszty utrzymania różnych projektów opisaliśmy w artykule [ile kosztuje utrzymanie strony internetowej miesięcznie](/blog/ile-kosztuje-utrzymanie-strony-internetowej-miesiecznie).
Kiedy potrzebny jest zarządzany VPS?
Zarządzany VPS warto wybrać, gdy:
- firma nie posiada własnego administratora,
- aplikacja jest ważna dla działalności,
- potrzebny jest monitoring,
- ktoś musi reagować na awarie,
- regularnie wykonywane są wdrożenia,
- serwer wymaga aktualizacji,
- dane wymagają zabezpieczenia.
Usługa może obejmować:
- konfigurację serwera,
- aktualizacje systemu,
- Nginx,
- SSL,
- PM2,
- bazę danych,
- Redis,
- kopie,
- monitoring,
- analizę awarii.
Dokładny zakres powinien być jasno ustalony.
Hosting aplikacji w HeatLogic
W HeatLogic przygotowujemy środowiska dla:
- Next.js,
- Node.js,
- NestJS,
- React,
- aplikacji z bazą PostgreSQL lub MySQL,
- paneli klientów,
- systemów rezerwacji,
- rozwiązań SaaS.
Zakres może obejmować:
- dobór VPS,
- konfigurację systemu,
- Nginx i SSL,
- procesy PM2,
- bazę danych,
- backupy,
- monitoring,
- migrację,
- wdrożenia,
- aktualizacje serwera,
- reakcję na awarie.
Usługa może być połączona z [hostingiem i opieką techniczną HeatLogic](/hosting-i-opieka).
Nie dobieramy serwera wyłącznie na podstawie liczby rdzeni i gigabajtów.
Najpierw analizujemy architekturę aplikacji, ruch, bazę, procesy i wymagania biznesowe.
Lista kontrolna hostingu aplikacji
Przed wdrożeniem sprawdź:
1. Jakiej wersji Node.js wymaga projekt?
2. Czy aplikacja potrzebuje SSR?
3. Czy posiada własne API?
4. Jakiej bazy danych używa?
5. Czy potrzebuje Redis?
6. Czy posiada workery?
7. Czy wykonuje zadania cron?
8. Jak przechowywane są zmienne środowiskowe?
9. Czy porty wewnętrzne są zabezpieczone?
10. Czy działa Nginx jako reverse proxy?
11. Czy aplikacja uruchamia się po restarcie?
12. Czy proces jest monitorowany?
13. Czy istnieje endpoint health?
14. Czy logi są rotowane?
15. Czy baza posiada backup?
16. Czy kopie znajdują się poza serwerem?
17. Czy SSL odnawia się automatycznie?
18. Czy istnieje środowisko testowe?
19. Czy wdrożenie można wycofać?
20. Kto reaguje na awarie?
Podsumowanie
Hosting dla Next.js i Node.js powinien zapewniać znacznie więcej niż miejsce na pliki.
Aplikacja może potrzebować:
- stale działających procesów,
- reverse proxy,
- bazy danych,
- Redis,
- kolejek,
- cronów,
- bezpiecznych zmiennych środowiskowych,
- backupów,
- monitoringu,
- procesu wdrożeniowego.
VPS daje odpowiednią kontrolę, ale wymaga prawidłowej konfiguracji i administracji.
Najtańszy serwer bez opieki nie jest oszczędnością, jeżeli firma nie wie, że aplikacja przestała działać albo od kilku dni nie wykonują się kopie.
Budujesz aplikację Next.js, Node.js lub NestJS i potrzebujesz stabilnego środowiska?
Skontaktuj się z HeatLogic. Sprawdzimy architekturę projektu, dobierzemy serwer, skonfigurujemy środowisko i uruchomimy monitoring oraz kopie bezpieczeństwa.