Hostinger zbudował Web Apps Hosting wokół prostej obietnicy: wypchnij swój kod z GitHub, plik ZIP albo swojego agenta kodującego AI, a otrzymasz działającą, produkcyjną aplikację online w około minutę, bez serwera, którym musiałbyś zarządzać. Chciałem sprawdzić, ile z tego naprawdę się sprawdza, gdy to ty klikasz wdrożenie, więc oto, co odkryłem.

Wdrażaj Web Apps szybciej z Hostinger

Wdrażaj nowoczesne aplikacje webowe na Hostinger dzięki zautomatyzowanym buildom, zarządzanej infrastrukturze, globalnemu CDN, SSL, narzędziom bezpieczeństwa i 30-dniowej gwarancji zwrotu pieniędzy.

Odwiedź Hostinger

Plusy i minusy

Ocena szczegółowa

Aby ocenić Hostinger Web Apps Hosting, zastosowałem metodologię oceniania HostAdvice, ten sam standardowy sposób używany w każdej recenzji na stronie, dzięki czemu oceny pozostają oparte na rzeczywistych testach, a nie na języku marketingowym. Oto, jak wypada w poszczególnych kategoriach.

Uruchom swoje aplikacje webowe bez problemów z DevOps

Wdrażaj nowoczesne aplikacje webowe na w pełni zarządzanym hostingu z automatycznymi wdrożeniami, zarządzanym SSL, globalnym CDN i wbudowanymi narzędziami bezpieczeństwa.

Odwiedź Hostinger

Plany i ceny

Hostinger sprzedaje Web Apps Hosting w dwóch wariantach, Business i Cloud Startup, oba stworzone specjalnie do wdrażania aplikacji Node.js i nowoczesnych aplikacji JavaScript, a nie do tradycyjnego tworzenia stron internetowych.

Cloud Startup, czyli plan, który testowałem, podwaja liczbę aplikacji i rdzeni CPU względem Business, a oba plany zawierają darmową domenę, darmowy firmowy e-mail i zarządzany SSL na pierwszy rok bezpośrednio w cenie przy finalizacji zamówienia.

Kilka rzeczy, które warto wiedzieć przed zamówieniem:

• Gwarancja zwrotu pieniędzy: Web Apps Hosting podlega standardowym warunkom zwrotu Hostinger, czyli prostemu 30-dniowemu oknu od daty zakupu. To znacznie prostsze niż w przypadku planów VPS Hostinger, które mają dodatkowy 180-dniowy cooldown między wnioskami o zwrot. Tutaj taki cooldown nie obowiązuje.
• Bezpłatny okres próbny: Nie znalazłem dedykowanego darmowego okresu próbnego. Twoim oknem na ocenę jest 30-dniowa gwarancja zwrotu pieniędzy.
• Metody płatności: Na stronie finalizacji zakupu jako domyślną metodę pokazano kartę płatniczą, z logotypami Visa, Mastercard, Amex i Discover, oraz opcją dodania innej metody płatności podczas procesu zakupu.
• Co zawiera pakiet: Darmowa domena na rok, darmowe skrzynki pocztowe na rok i zarządzany SSL są wliczone bez dodatkowych opłat ponad cenę planu, więc cena na etykiecie jest bardzo bliska rzeczywistemu kosztowi uruchomienia w pełni działającego, zabezpieczonego wdrożenia.
• Jedyny upsell: Hostinger Reach, dodatek do marketingu e-mailowego, pojawia się w koszyku jako osobne, wyróżnione pole z własną miesięczną ceną. Łatwo go pominąć i nie jest domyślnie dołączony ani zaznaczony.

Jeśli anulujesz plan Web Apps Hosting w ciągu 30 dni, polityka zwrotów Hostinger potwierdza, że podlega on standardowym warunkom zamiast listy wyłączeń, więc zwykłe anulowanie w tym terminie powinno kwalifikować się do zwrotu bez dodatkowych warunków, które dotyczą planów VPS lub zakupu domeny.

Funkcje

• Automatyczne wykrywanie frameworka i wersji Node
• Narzędzia do tworzenia zarządzanej bazy danych MySQL
• Globalny CDN aktywny domyślnie
• WAF i ochrona przed DDoS w zestawie
• Codzienne i na żądanie kopie zapasowe
• Skaner malware i skanowanie podatności
• Integracja z GitHub z automatycznym wdrażaniem
• Darmowa domena, e-mail i SSL
• Dostęp SSH dla zaawansowanych użytkowników

Od kodu do działającej aplikacji z Hostinger

Podłącz swoje repozytorium GitHub lub wgraj projekt i uruchom go online dzięki zarządzanej infrastrukturze, automatycznym wdrożeniom i codziennym kopiom zapasowym.

Odwiedź Hostinger

Wydajność

Ponieważ Web Apps Hosting jest w pełni zarządzany, nigdy nie otrzymujesz dostępu shell do serwera, więc nie da się bezpośrednio benchmarkować CPU, RAM ani dysku tak jak w przypadku recenzji VPS.

To, co możesz mierzyć, to szybkość ładowania i odpowiadania samej wdrożonej aplikacji, z prawdziwych lokalizacji na całym świecie. Testowałem to z czterech różnych stron: GTmetrix z dwóch kontynentów, ponad 50-punktowa globalna kontrola spójności oraz wbudowane narzędzie prędkości Hostinger zarówno dla desktopu, jak i mobile.

Testowana aplikacja to wdrożenie Next.js opisane w sekcji Łatwość użycia poniżej, działające pod ivory-llama-856835.hostingersite.com, na planie Cloud Startup (4 rdzenie CPU, 4096 MB RAM, 100 GB NVMe storage), z aktywnym domyślnie CDN.

1. GTmetrix, testowane z dwóch kontynentów

Uruchomiłem GTmetrix dwa razy z różnych części świata, aby sprawdzić, czy wynik pozostaje spójny, czy też wygląda dobrze tylko z jednego szczęśliwego punktu widzenia.

Oba uruchomienia uzyskały doskonałe 100% zarówno w Performance, jak i Structure, z zerowym przesunięciem układu i zerowym czasem blokowania w obu lokalizacjach, co oznacza, że nic na stronie nie konkurowało o uwagę przeglądarki ani nie przeskakiwało podczas ładowania.

Naprawdę interesującym szczegółem jest to, że Frankfurt faktycznie wyprzedził Chicago we wszystkich metrykach czasowych, mimo że celowo wybrałem lokalizację serwera w USA dla tej aplikacji. Ten wynik ma sens tylko w świetle CDN.

Gdy CDN jest aktywny, jak tutaj domyślnie, Twój użytkownik niekoniecznie łączy się bezpośrednio z serwerem źródłowym.

Łączy się z najbliższym węzłem cache na edge, więc punkt testowy w Europie może wypaść szybciej niż punkt w USA, nawet jeśli właściwy serwer znajduje się w USA. To realne, praktyczne potwierdzenie, że domyślnie włączony CDN Hostinger faktycznie działa, zamiast być tylko marketingowym hasłem.

2. Globalna spójność (Check-Host)

Przeprowadziłem test HTTP dla aktywnego adresu URL ze wszystkich punktów kontrolnych, które oferuje Check-Host, 54 lokalizacji na sześciu kontynentach. Pełny obraz:

Każde udane sprawdzenie zwróciło czyste 200 OK, bez błędów, bez częściowych niepowodzeń, bez nieoczekiwanych przekierowań.

Czasy odpowiedzi wyraźnie pokazały, jak zachowuje się buforowanie CDN w rzeczywistych odległościach:

Europejskie punkty kontrolne konsekwentnie zwracały najszybsze czasy, kilka poniżej 50 milisekund, podczas gdy punkty fizycznie najdalsze od jakiegokolwiek węzła edge, Tokio, Singapur, Ho Chi Minh City, nadal zwracały poprawne odpowiedzi 200, tylko wolniej, w zakresie 0.3 do 0.8 sekundy.

To jest oczekiwany kształt dla wdrożenia opartego na CDN: szybko blisko krawędzi, a nadal w pełni funkcjonalnie daleko od niej.

Cztery przekroczenia czasu, Kazachstan, Rumunia i dwa z czterech rosyjskich punktów kontrolnych, nie są czymś, co interpretowałbym jako problem z infrastrukturą Hostinger.

Inne punkty kontrolne w tych samych krajach zakończyły się sukcesem (Sankt Petersburg zwrócił poprawną odpowiedź 0.063s, podczas gdy dwa punkty Moskwa przekroczyły czas), co wskazuje na regionalne filtrowanie sieci po stronie punktu kontrolnego, a nie na jakikolwiek problem z wdrożoną aplikacją.

3. Własne narzędzie prędkości Hostinger, desktop i mobile

Hostinger uruchamia własny test Page Speed bezpośrednio w panelu aplikacji, więc porównałem jego wyniki z niezależnymi rezultatami GTmetrix, zamiast przyjmować którekolwiek z nich bezkrytycznie.

Oba typy urządzeń uzyskały doskonałe 100, a wyniki desktopu są bardzo zbliżone do tego, co niezależnie zmierzył GTmetrix, i właśnie o to chodzi w uruchamianiu obu testów. Dwa różne narzędzia, dwie różne metodologie i zgadzają się ze sobą.

Mobile wypadł wolniej we wszystkich metrykach czasowych, co jest spodziewane przy symulowanym wolniejszym łączu i słabszym procesorze, ale nadal wystarczająco szybko, by wynik 100 oznaczał naprawdę mocną wydajność w realnym użyciu, a nie tylko łagodną skalę oceniania.

Jedna niespójność w samym narzędziu. Mimo że wynik wynosi czyste 100 na obu urządzeniach, panel Diagnostics poniżej nadal oznacza kilka pozycji dosłownie jako 0, dependency tree sieci, document request latency i avoiding multiple redirects, oraz dwie pozycje z wynikiem 50, unused JavaScript i legacy JavaScript.

Żaden z tych niskich wyników cząstkowych nie obniżył wyniku głównego, więc traktuj je jako drobne, rzeczywiście istniejące możliwości optymalizacji, a nie jako coś nie tak z wdrożeniem.

Dodatkowo „pomocne linki”, które Hostinger pokazuje obok tych diagnostyk, są wszystkie napisane pod WordPress, „Speed up WordPress in 9 easy steps”, „How to optimize images for your WordPress site”, mimo że to aplikacja Node.js bez żadnego WordPressa w stosie. To pozostałość po wspólnym szablonie diagnostyki, a nie treść przygotowana dla tego produktu.

Ogólny werdykt dotyczący wydajności

Zarządzany hosting aplikacji webowych od Hostinger

Skup się na budowaniu aplikacji, a Hostinger zajmie się wdrożeniem, infrastrukturą, bezpieczeństwem, SSL, kopiami zapasowymi i globalnym dostarczaniem treści.

Odwiedź Hostinger

Łatwość użycia

Testowałem Hostinger Web Apps Hosting od strony docelowej przez proces zakupu, a następnie z czystego konta do w pełni działającego wdrożenia Node.js.

Obejmowało to wybór planu, płatność, sposób budowania, podłączenie GitHub i obserwowanie builda w czasie rzeczywistym. Oto, jak naprawdę wyglądał ten proces.

1. Rejestracja

Zacząłem na stronie docelowej Web Apps Hosting, która prowadzi z jednym wezwaniem do działania: Start deploying.

Kliknięcie go nie otwiera formularza rejestracji. Przewija Cię od razu do sekcji cen, więc pierwszą realną decyzją jest wybór planu, a nie wypełnianie danych konta.

Obok siebie stały dwa plany:

Wybrałem Cloud Startup ze względu na dwukrotnie większy limit aplikacji i większy zapas CPU względem wejściowego planu. Jedna drobna niespójność do odnotowania: strona cenowa nazywa go „Cloud Startup”, ale po dodaniu do koszyka ten sam plan jest oznaczony jako „Startup plan”. Nie jest to problem funkcjonalny, tylko rozbieżność w nazewnictwie między dwoma ekranami w tym samym procesie zakupu.

Sam koszyk był przejrzysty. Pokazywał 48-miesięczny okres, oszczędność, darmową domenę na rok i darmowe skrzynki pocztowe, a następnie oferował jeden upsell, Hostinger Reach email marketing, umieszczony we własnym wyróżnionym polu zamiast być domyślnie zaznaczonym.

Pominąłem go i kliknąłem Continue bez żadnych przeszkód.

Jeśli jesteś nowym klientem, a nie istniejącym, finalizacja zakupu w tym miejscu wstawia krok tworzenia konta, zanim dojdziesz do adresu rozliczeniowego i strony płatności.

Następnie dodajesz adres rozliczeniowy, wybierasz metodę płatności, kartę, PayPal lub jedną z pozostałych opcji, i wysyłasz zamówienie. Potwierdzenie zakupu otrzymałem e-mailem w kilka chwil po kliknięciu Submit payment, a potem trafiłem bezpośrednio do hPanel, gdzie plan był już przydzielony.

Co pomyślałem: Proces zakupu jest krótki, a upsell można łatwo odrzucić bez szukania ukrytego linku pomijania. Rozbieżność w nazwie planu między stroną cenową a koszykiem to drobiazg, ale to właśnie taki szczegół sprawia, że kupujący pierwszy raz zatrzymuje się i sprawdza dwa razy, czy wybrał właściwy wariant.

2. Panel

Gdy płatność zostanie zaksięgowana, trafiasz do hPanel, autorskiego panelu Hostinger, stworzonego do zarządzania każdym produktem, który sprzedaje, a nie do strony przygotowanej specjalnie dla Twojej nowej Web App.

Strona, na którą trafiasz jako pierwszą, to Home, i jest zbudowana wokół paska promptu AI u góry: „Hi, [your name]! How can I help you today?” z polem tekstowym poniżej i sześcioma przyciskami skrótu: Get domain, Create website, Get email, Migrate site, Get VPS i Try email marketing.

Przewiń niżej, a znajdziesz:

• Kafelki promocyjne funkcji dla AI Builder, narzędzia sklepu internetowego, z informacją o darmowym e-mailu firmowym, agentach AI, aplikacji do automatyzacji oraz darmowej domenie
• Listę zadań nakierowującą Cię na kroki konfiguracji, dokończenie ustawień Reach, odebranie darmowego e-maila, odebranie darmowej domeny
• Your business, bieżącą listę wszystkich stron, aplikacji i instancji VPS powiązanych z Twoim kontem, każdą z własnym przyciskiem Manage site
• VPS, osobną tabelę niżej, pokazującą wszelkie instancje VPS według adresu IP, statusu i daty wygaśnięcia

Panel Agent jest również stale widoczny w prawym górnym rogu każdej strony hPanel, nie tylko na Home. To ten sam asystent Kodee używany do wsparcia, ale umieszczony tutaj jako ogólne narzędzie do działań z gotowymi promptami, takimi jak „Deploy my Node.js app” lub „Harden VPS updates”, które możesz uruchomić bez wpisywania pełnego pytania.

Home jest naprawdę użyteczny, gdy Twoja aplikacja już istnieje, wszystko w Your business prowadzi bezpośrednio do niej. Ale nie tam tworzysz nową Web App ani nie docierasz do przycisku Setup. Do tego trzeba przejść inną ścieżką przez pasek boczny:

1. Kliknij Websites w lewym pasku bocznym
2. Rozwinie się podmenu poniżej: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Kliknij Web Apps

To kliknięcie przenosi Cię do zupełnie innego ekranu niż Home, zorganizowanego wokół rzeczywistych planów hostingowych, a nie paska promptu.

Tutaj każdy posiadany plan dostaje własną kartę. Na moim koncie oznaczało to trzy karty ułożone pionowo:

Karta Business miała już też pod spodem aktywną aplikację z wcześniejszych testów, orange-walrus-700988.hostingersite.com, z własnymi przyciskami Tools i Dashboard.

To samo w sobie jest przydatne. Gdy Web App już istnieje, jej karta rozwija taki wiersz pokazujący bezpośrednio aktywną stronę, dokładnie tak, jak będzie wyglądać karta Twojego Cloud Startup po zakończeniu konfiguracji.

Ponieważ Cloud Startup był planem, który właśnie kupiłem i jeszcze go nie skonfigurowałem, jego karta pokazywała zamiast tego pojedynczy przycisk Setup. To ten przycisk faktycznie uruchamia kreator tworzenia Web App i pojawia się tylko tutaj, pod Websites → Web Apps, a nie na ekranie Home, na który trafiasz domyślnie.

Co pomyślałem: hPanel jest przejrzysty, gdy już znajdziesz właściwy ekran, ale Web Apps Hosting nie ma oczywistego głównego wejścia. Lądowanie na Home pokazuje pasek promptu i skróty, a nie ścieżkę do tworzenia aplikacji — trzeba wiedzieć, że należy kliknąć Websites, potem Web Apps, zanim w ogóle pojawi się Setup. To kilka dodatkowych kliknięć jak na produkt reklamowany jako „live in a minute”. Gdy już tam jesteś, karty planów są jednak czyste i uczciwe w kwestii statusu, a plan z działającą aplikacją pokazuje ją bezpośrednio na karcie.

3. Wdrażanie aplikacji

Kliknięcie Setup na karcie planu otworzyło krótki proces wprowadzający: Where would you like to start? z trzema opcjami, Create a new site, Migrate an existing site lub I hired someone to build my site. Wybrałem Create a new site.

To prowadziło do How do you want to build your website?, podzielonego na dwie opcje dla początkujących u góry, Hostinger AI Builder i WordPress + AI, oraz dwie opcje pod osobnym nagłówkiem „for advanced users” poniżej: Node.js web app i PHP/HTML website. Wybranie Node.js web app to krok, który faktycznie prowadzi do produktu Web Apps Hosting.

To istotna uwaga strukturalna dla każdego, kto porównuje produkty: Web Apps Hosting nie ma własnego, dedykowanego procesu rejestracji.

To jedna gałąź w tym samym ogólnym kreatorze tworzenia witryn używanym dla AI Builder i WordPress.

Kliknąłem kółko obok Node.js web app, a następnie kliknąłem Next.

Stamtąd:

• Ekran domeny: Wybrałem Use temporary domain zamiast wiązać się z prawdziwą domeną, ponieważ był to testowy deployment.

• Ekran lokalizacji serwera: Hostinger domyślnie wybrał Francję, najbliższy region do mojego kraju rozliczeniowego, i pokazał 167ms opóźnienia. Po przewinięciu do opcji United States widniało 364ms, ponad dwa razy więcej.

Wybrałem jednak United States, Massachusetts i to jest dokładna lekcja, jaką daje ten selektor lokalizacji na każdym produkcie Hostinger: wybieraj zgodnie z tym, gdzie są Twoi rzeczywiści użytkownicy, a nie według najniższej liczby na liście.

Moją docelową publicznością dla tej aplikacji są użytkownicy z USA, więc serwer w USA rzeczywiście obsłuży ich szybciej niż zrobiłby to serwer we Francji, niezależnie od tego, co pokazywał mi selektor z mojej lokalizacji. Liczba na ekranie mówi Ci, jak szybko serwer reaguje na test Hostinger, a nie jak szybko zareaguje na ludzi, którzy faktycznie będą używać Twojej strony.

• Ekran metody wdrożenia: dwie główne opcje, Import Git repository (oznaczone jako Recommended) albo Upload your files, plus niżej wyróżniona informacja o wdrożeniu bezpośrednio z Claude Code, Cursor lub VS Code przez Hostinger Connector. Wybrałem Import Git repository i kliknąłem Connect with GitHub.

To otworzyło prawdziwe okno logowania GitHub, jeśli nie byłeś już zalogowany, a następnie ekran uprawnień zatytułowany Install & Authorize Hostinger, proszący o wybór między:

• Instalacją na all repositories które posiadasz, w tym przyszłe, z dostępem tylko do odczytu dla publicznych repozytoriów
• Instalacją tylko na only select repositories wybranych indywidualnie i listą dokładnych przyznawanych uprawnień: dostęp do odczytu dla actions, metadata i repository hooks oraz dostęp do odczytu i zapisu dla administration, code i pull requests. Po kliknięciu Install & Authorize GitHub automatycznie przekierowuje Cię z powrotem do hPanel.

Trafiasz na Select Git repository to import, przewijaną listę wszystkich repozytoriów powiązanych z Twoim kontem GitHub, każde z własnym przyciskiem Deploy obok. Znalazłem testowe repozytorium, które wcześniej wypchnąłem, hostadvice-webapps-test, i kliknąłem Deploy obok niego.

Od kliknięcia tego przycisku minęło prawie 30 sekund bez żadnego wskaźnika postępu na ekranie, wystarczająco długo, by zacząć się zastanawiać, czy kliknięcie w ogóle zostało zarejestrowane.

Ekran, który w końcu się ładuje, nosi tytuł Review build settings i mówi dokładnie, gdzie będzie działać Twoja aplikacja, zanim cokolwiek zatwierdzisz: „Deploys to ivory-llama-856835.hostingersite.com.” Poniżej, bez dotykania ani jednego pola, automatycznie wykryto już:

Każdy z tych pięciu wierszy ma obok własny przycisk Change lub Add, więc nic tutaj nie jest zablokowane, jeśli wykrywanie pomyliło się w czymś.

Kliknąłem Add obok Environment variables i ustawiłem jedną parę klucz-wartość, aby sprawdzić, czy faktycznie dotrze później do działającej aplikacji, a następnie kliknąłem Finish w tym oknie, po czym kliknąłem główny przycisk Deploy na dole strony.

Obserwowanie builda

Ekran przełącza się na widok Deploying… z oznaczonym paskiem postępu, „Deployment from GitHub”, przesuwającym się etapami — obserwowałem, jak dochodzi do 28%, potem 51%, w drodze do zakończenia. Pod paskiem postępu znajduje się zwijany panel Build logs, a jego rozwinięcie pokazuje prawdziwy, bieżący terminal output, a nie symboliczny spinner:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Wdrożenie zakończone

Gdy build się zakończy, trafiasz na ekran Deployment completed! z miniaturą na żywo Twojej rzeczywiście działającej aplikacji wyrenderowaną bezpośrednio na karcie, obok podsumowania pokazującego nazwę repozytorium i przypisany aktywny adres URL.

Z tej strony możesz od razu kliknąć Go to dashboard, gdzie zarządzasz aplikacją dalej.

Co pomyślałem: Automatyczne wykrywanie jest tutaj najmocniejszym elementem. Framework, branch i wersja Node zostały rozpoznane poprawnie bez ręcznego wpisywania czegokolwiek, a żywy log builda sprawia, że czekanie jest przejrzyste, a nie nieprzejrzyste. Jedyny słaby punkt to 30-sekundowa przerwa zanim w ogóle trafiasz na ekran ustawień, wystarczająco długa, by pomyśleć, że coś się zawiesiło, zanim proces wyraźnie ruszy.

4. Potwierdzenie aktywnego wdrożenia

Zanim zacząłem oglądać jakiekolwiek narzędzia zarządzania, chciałem potwierdzić, że aplikacja rzeczywiście została wdrożona i działa, a nie tylko została oznaczona jako „Completed” na ekranie.

Z ekranu Deployment completed kliknąłem bezpośrednio aktywny adres URL, ivory-llama-856835.hostingersite.com, zamiast ufać samej miniaturze podglądu w panelu.

Strona na żywo wczytała się i pokazała dokładnie to, co aplikacja była zaprogramowana wyświetlać:

• Server build time, aktualny znacznik czasu potwierdzający, że strona została świeżo zbudowana, a nie podana z dawnej pamięci podręcznej
• Environment variable check, pokazujący niestandardową zmienną, którą ustawiłem podczas wdrażania, poprawnie potwierdzoną na rzeczywistej stronie, a nie tylko w podglądzie panelu

Następnie kliknąłem własny przycisk aplikacji Ping the API route, który wywołuje aktywny backendowy endpoint, a nie tylko renderuje statyczną treść. Zwrócił czystą odpowiedź JSON:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

Ta odpowiedź ma większe znaczenie, niż może się wydawać. Strona ładująca się poprawnie potwierdza jedynie, że pliki statyczne zostały wgrane.

Działające wywołanie API potwierdza, że rzeczywisty serwer Node.js działa pod spodem i odpowiada na prawdziwe żądania — to właśnie ta część „Node.js web app” hostingu, którą łatwo udawać za pomocą statycznego pliku, a trudno udawać za pomocą aktywnego znacznika czasu serwera wygenerowanego dokładnie w chwili kliknięcia przycisku.

Co pomyślałem: To jest sprawdzenie, które poleciłbym Ci przed zaufaniem jakimkolwiek wdrożeniom na tej platformie, albo na podobnej. Zielony status „Completed” i miniatura podglądu mówią Ci, że build się zakończył. Kliknięcie aktywnego URL i uruchomienie czegoś dynamicznego — wywołania API, odczytu bazy danych, czegokolwiek, czego nie da się podrobić przez buforowaną statyczną stronę — mówi Ci, że serwer naprawdę żyje i robi to, do czego został zbudowany.

5. Zarządzanie aplikacją webową

Po potwierdzeniu, że aktywna aplikacja działa, wróciłem do hPanel i przejrzałem od początku do końca dashboard zarządzania samej aplikacji, czyli właściwą warstwę zarządzania serwerem tego produktu, oddzieloną od ogólnego ekranu Home w hPanel omówionego wcześniej.

Przegląd pulpitu. W momencie wejścia tutaj cztery znaczniki statusu pokazują stan rzeczy na pierwszy rzut oka:

Wszystkie cztery były zielone domyślnie, bez konieczności przełączania czegokolwiek ręcznie. Poniżej znajduje się karta Last deployment potwierdzająca stan, repozytorium, autora, commit, czas wdrożenia, wykryty stack i wersję Node — wszystko, co chcesz sprawdzić na pierwszy rzut oka bez przekopywania logów.

Automatyczny test Page Speed został już samodzielnie uruchomiony na aktywnej stronie i zwrócił wynik 99/100 dla Desktop bez mojego inicjowania, obok panelu Essentials z szybkimi linkami do połączenia z bazą danych, kopii zapasowych, menedżera plików, logów runtime i cache.

Deployments, environment variables i logi. Trzy osobne strony obejmują ten obszar:

• Deployments zachowało pełny zapis wypchnięcia, autora, brancha, hash commit i statusu zakończenia, prawdziwą historię, a nie tylko najnowszy wpis
• Environment variables poprawnie pokazały tę, którą ustawiłem podczas wdrażania, potwierdzając, że została zapisana i zastosowana, a nie tylko pokazana raz podczas konfiguracji i zapomniana
• Runtime logs strumieniowały na żywo wyjście serwera, linie startowe Next.js, znaczniki czasu gotowości i bieżącą liczbę problemów oraz błędów, która przez cały czas wynosiła zero i zero, gdy je obserwowałem

Bezpieczeństwo. Malware Scanner zwrócił czysty wynik, „Your website is safe”, z jednym zastrzeżeniem podanym wprost, a nie ukrytym w drobnym druku: sprawdza on tylko pliki witryny, nie zawartość bazy danych, a jeśli chcesz głębszego skanu obejmującego bazę danych, dostępna jest płatna opcja czyszczenia. Skan Vulnerabilities również wypadł czysto.

Bazy danych. Tu marketing produktu tworzy realną lukę, którą powinieneś zrozumieć przed zakupem. Plan reklamuje zarządzany MySQL jako kluczową funkcję, ale nic nie jest tworzone automatycznie za Ciebie.

Sekcja Databases otwiera się na ręcznym formularzu Create a New MySQL Database And Database User, co oznacza, że sam nadajesz nazwę i tworzysz bazę danych, zanim Twoja aplikacja będzie mogła z niej korzystać. Potwierdziłem to bezpośrednio z Kodee, o czym w sekcji Wsparcie poniżej, a odpowiedź była jednoznaczna: zarządzany oznacza, że Hostinger obsługuje infrastrukturę bazy danych w tle, a nie że baza danych zostaje utworzona dla Ciebie w momencie uruchomienia aplikacji.

Dostęp zaawansowany. Dostęp SSH znajduje się w sekcji Advanced, razem z IP, portem i nazwą użytkownika, ale domyślnie jest Inactive i wymaga ręcznego kliknięcia Enable, zanim będziesz mógł z niego korzystać. File Manager oferuje wybór między przeglądaniem tylko plików tej aplikacji albo wszystkich plików w całym planie hostingowym.

Co pomyślałem: Codzienny panel jest szczegółowy i dobrze zorganizowany. Szczególnie bezpieczeństwo i historia wdrożeń są łatwe do znalezienia i naprawdę informacyjne, a log runtime bez błędów wraz z czystym skanem malware dały mi realną pewność, że aplikacja jest zdrowa, a nie tylko online.

Jedynym miejscem, gdzie interfejs przecenia swoje możliwości, jest sekcja bazy danych, gdzie „managed MySQL” brzmi na stronie planu jak coś gotowego do użycia od razu po uruchomieniu aplikacji, a w praktyce oznacza formularz do samodzielnego utworzenia bazy.

Ogólny werdykt dotyczący łatwości użycia

Buduj, wdrażaj i skaluj z Hostinger

Hostuj nowoczesne aplikacje webowe z integracją GitHub, zarządzanym MySQL, globalnym CDN, nielimitowanym transferem i wbudowanymi narzędziami bezpieczeństwa.

Odwiedź Hostinger

Poziom wsparcia

Testowałem wsparcie Hostinger dla Web Apps Hosting przez Kodee, asystenta AI wbudowanego w hPanel, a następnie sprawdziłem bazę wiedzy, aby zobaczyć, jak dużo obejmuje bez potrzeby zadawania pytań komukolwiek innemu. Kodee pojawia się w dwóch miejscach, które warto rozróżnić: jako Ask AI na publicznej stronie marketingowej oraz jako panel Agent dostępny z każdej strony w samym hPanel, także bezpośrednio na dashboardzie samej Web App.

1. Wsparcie AI (Kodee)

Zadałem dwa pytania oparte na realnych lukach, które zauważyłem podczas testów, a nie na ogólnych zapytaniach, na które Kodee mógłby odpowiedzieć, wklejając fragment dokumentacji.

Pytanie 1 sprawdzało zachowanie przy nieudanym wdrożeniu i moment ustawiania zmiennych środowiskowych, czyli realne kwestie produkcyjne dla każdego, kto wdraża aplikację na tę platformę:

Jeśli build mojej aplikacji zawiedzie w połowie wdrożenia z GitHub, czy aplikacja automatycznie wróci do ostatniej udanej wersji, czy też przestanie działać, dopóki tego nie naprawię i nie wdrożę ponownie? I czy mogę ustawić niestandardowe zmienne środowiskowe przed pierwszym wdrożeniem, czy dopiero po nim?

Kodee odpowiedział bezpośrednio i poprawnie na oba pytania. Nieudany build nie zastępuje obecnie działającej aplikacji; jeśli poprzednie wdrożenie się udało, aplikacja nadal obsługuje ostatnią działającą wersję. Jeśli to pierwsze wdrożenie i nie ma do czego wrócić, aplikacja pozostaje niedostępna, dopóki build nie zostanie naprawiony i wdrożony ponownie — to jasna, uczciwa odpowiedź, a nie ogólnikowe uspokojenie.

Jeśli chodzi o zmienne środowiskowe, potwierdził, że można je ustawić przed pierwszym wdrożeniem w ustawieniach deploymentu, a dla już działającej aplikacji opisał dokładnie trzy kroki: otwórz Settings i Redeploy, dodaj lub edytuj zmienne w Environment variables, zapisz i wdroż ponownie.

Pytanie 2 dotyczyło dwóch luk, które sam zauważyłem w panelu: rozbieżności między określeniem „managed MySQL” a ręcznym formularzem tworzenia oraz faktu, że SSH jest domyślnie nieaktywne:

Ten plan reklamuje managed MySQL, ale panel pokazuje ręczny formularz „Create a New MySQL Database” zamiast bazy tworzonej automatycznie. Czy baza danych jest tworzona domyślnie dla każdej Web App, czy tylko jeśli utworzę ją sam? I jeszcze jedno: dostęp SSH jest pokazany jako dostępny, ale domyślnie ma status Inactive. Jeśli nigdy go nie włączę, czy to cokolwiek zmienia w tym, jak działa moja aplikacja, czy SSH jest tylko opcjonalnym dodatkiem dla zaawansowanych użytkowników?

Odpowiedź Kodee potwierdziła dokładnie to, co sam sprawdziłem w interfejsie, a nie jakąś łagodniejszą wersję tego. Baza danych nie jest tworzona automatycznie dla każdej Web App; „managed” oznacza, że Hostinger obsługuje usługę i infrastrukturę bazy danych, natomiast utworzenie i skonfigurowanie rzeczywistej bazy należy do Ciebie, poprzez ten sam ekran Create a New MySQL Database, a następnie ręczne dodanie jej danych połączeniowych do zmiennych środowiskowych aplikacji.

W kwestii SSH potwierdził, że pozostawienie go w stanie nieaktywnym nic nie zmienia w działaniu aplikacji, wdrożeniach ani połączeniu z bazą danych. Jest to wyłącznie opcjonalne narzędzie do poleceń CLI, migracji lub bezpośredniego debugowania plików, a nie coś, od czego platforma zależy w tle.

Co pomyślałem: Obie odpowiedzi zgadzały się z tym, co wcześniej zweryfikowałem ręcznie w panelu, zamiast temu zaprzeczać lub to łagodzić, a to znak, że narzędzie wsparcia faktycznie sprawdza stan realnego produktu, zamiast recytować skrypt. Żadnego z tych pytań nie dało się odpowiedzieć przez wklejenie odpowiedzi z ogólnego FAQ, a Kodee poradził sobie z obydwoma w około minutę, podając konkretne, uporządkowane, dwuczęściowe odpowiedzi.

2. Baza wiedzy

Baza wiedzy Hostinger otwiera się na siatce kategorii, 20 kategorii łącznie, każda z liczbą artykułów. Kilka największych: AI Builder ma 330 artykułów, VPS 276, Email 127, a Website 103.

Web Apps Hosting nie ma własnej, dedykowanej kategorii. Jej treści są rozproszone po Getting Started, hPanel i Website, co jest realnym odkryciem dla każdego, kto oczekuje jednego, dedykowanego miejsca, takiego jak dla VPS czy Email.

Wyszukiwanie „Web Apps” bezpośrednio zwróciło 71 wyników na 8 stronach. Najlepsze wyniki były mieszanką treści bezpośrednio związanych i tylko luźno powiązanych:

• How to deploy apps built with Codex on Hostinger, bezpośrednio powiązany
• Hostinger AI Builder: How to create a web app in agentic mode, powiązany, ale dotyczący innego produktu
• How to add a Node.js Web App in Hostinger, bezpośrednio powiązany
• How to install Flutter Web on a VPS at Hostinger, zupełnie inny produkt
• Kilka artykułów Website Builder o metodach płatności (PayPal, WeChat Pay, BLIK), niezwiązanych z tematem poza tym, że gdzieś w tekście pojawia się słowo „web” i „app”

Otworzyłem jeden z najwyższych wyników, How to deploy apps built with Codex on Hostinger, aby sprawdzić jego szczegółowość. Okazał się rzetelnym, dobrze uporządkowanym przewodnikiem, z listą obsługiwanych frameworków na początku, instrukcjami krok po kroku ze zrzutami ekranu dla obu ścieżek — importu z GitHub i uploadu ZIP — sekcją o konfiguracji ustawień builda z przykładowymi poleceniami, omówieniem struktury plików po wdrożeniu, pokazem kreatora połączenia z bazą danych, sekcją monitorowania podatności i końcowym blokiem FAQ.

Mimo że jest opisany konkretnie pod Codex, podstawowa platforma jest ta sama, co w ogólnym produkcie Node.js Web App, więc większość informacji można zastosować bezpośrednio.

Co pomyślałem: Liczba artykułów w wynikach wygląda dobrze na papierze, 71 trafień dla jednego hasła, ale znacząca część tego wolumenu to szum z innych produktów, które po prostu mają podobne słownictwo. Jeden artykuł, który otworzyłem w całości, trzymał poziom pod względem jakości, gdy już do niego dotarłem: jasne kroki, prawdziwe zrzuty ekranu i rzeczywista sekcja FAQ, ale trzeba go było znaleźć, przewijając wyniki, które nie miały nic wspólnego z tym, co faktycznie chciałem wdrożyć.

Ogólny werdykt dotyczący obsługi klienta

Prosty hosting dla nowoczesnych aplikacji webowych

Wdrażaj React, Next.js, Vue, Node.js i inne nowoczesne aplikacje bez zarządzania serwerami czy skomplikowaną infrastrukturą.

Odwiedź Hostinger

Czy polecamy Hostinger Web Apps Hosting?

Tak. Proces wdrożenia jest najmocniejszą częścią tego produktu: poprawne automatyczne wykrywanie mojego stacka, brancha i wersji Node, prawdziwy, strumieniowy build log zamiast spinnera oraz aktywna aplikacja, która przeszła każdy test wydajności, jaki jej zadałem — doskonałe wyniki GTmetrix z dwóch różnych kontynentów, czysta 54-punktowa globalna kontrola spójności i zgodne wyniki 100/100 z własnych narzędzi Hostinger zarówno na desktopie, jak i mobile. Kodee wsparł to dokładnymi, konkretnymi odpowiedziami na rzeczywiste pytania techniczne, a nie ogólnymi odpowiedziami ze skryptu.

Drobne niedoskonałości są niewielkie, ale warto je znać przed zakupem. „Managed MySQL” brzmi na stronie planu jak coś gotowego w momencie, gdy Twoja aplikacja zostanie uruchomiona, a w praktyce oznacza ręczny formularz tworzenia. Panel też nie daje Web Apps Hosting dedykowanego wejścia z głównego ekranu Home — trzeba wiedzieć, że należy przejść przez Websites.

Dla dewelopera, który chce szybkie wdrożenie niezależne od frameworka na infrastrukturze, która tak dobrze wypada w benchmarkach, to łatwa rekomendacja. Dla kogoś, kto oczekuje, że każda reklamowana funkcja będzie włączona w momencie zakończenia zakupu, warto zarezerwować kilka dodatkowych minut na samodzielną konfigurację bazy danych.

Hostinger

5.0

2,471 user reviews

1,37 € /mo

Cena początkowa

Odwiedź Hostinger

Rating based on expert review

• Przyjazność
  4.9
• Pomoc techniczna
  4.9
• Funkcje
  4.8
• Niezawodność
  4.7
• Cena
  4.5