Zarządzanie hostingiem zwykle przerywa pracę nad rozwojem. Piszesz kod w edytorze, otwierasz panel hostingu, aby utworzyć stronę internetową, przełączasz się do terminala, aby spakować lub wypchnąć projekt, wracasz do panelu, aby sprawdzić wdrożenie, i otwierasz kolejne narzędzia, gdy trzeba zająć się DNS, logami lub zasobami serwera.

Hostinger Connector ogranicza to przełączanie kontekstu. Łączy usługi Hostinger z narzędziami do kodowania AI przez Model Context Protocol (MCP), dzięki czemu możesz poprosić asystenta AI o sprawdzenie lub obsługę obsługiwanych zasobów hostingu bez opuszczania edytora.

To brzmi wygodnie. Rodzi też ważniejsze pytanie: Czy można zaufać asystentowi AI, że wykona rzeczywiste zadania hostingowe dokładnie?

Aby się o tym przekonać, przetestowałem Hostinger Connector z VS Code i GitHub Copilot na prawdziwym koncie Hostinger. Użyłem niewielkiej aplikacji Express.js o nazwie PulseWatch i przeszedłem przez cały workflow od instalacji do wdrożenia na żywo. Przetestowałem też ponowne wdrożenia, rekordy buildu, logi oraz odzyskiwanie działania po celowym zepsuciu polecenia startowego aplikacji.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Odwiedź Hostinger

Plusy i minusy Hostinger Connector

Podział ocen

Oto, jak oceniłem Hostinger Connector w obszarach, które mają największe znaczenie dla dewelopera decydującego, czy go używać: koszt, zakres funkcji, codzienna użyteczność, dokładność wykonywania rzeczywistych zadań oraz wsparcie, które stoi za nim, gdy coś pójdzie nie tak. Każda ocena odzwierciedla to, co faktycznie znalazłem podczas testów, a nie stronę marketingową.

Plany i ceny Hostinger Connector

Hostinger Connector nie jest sprzedawany jako samodzielny produkt. Hostinger twierdzi, że Connector jest dołączony za darmo do każdego planu, co oznacza, że nie ma osobnej miesięcznej opłaty za Connector, którą trzeba by doliczyć do rachunku za hosting.

Jednak „darmowy” wymaga kontekstu. Connector zarządza zasobami Hostinger; nie zastępuje ich. Nadal potrzebujesz kwalifikującego się hostingu, cloud, VPS, domeny, poczty e-mail lub innej usługi Hostinger do zadań, które chcesz, aby wykonywał.

W momencie przygotowywania tej recenzji strona Connector wyróżniała Business Web Hosting i Cloud Startup.

Ceny były wyświetlane przed obowiązującymi podatkami. Ceny promocyjne i stawki odnowienia mogą się zmieniać, więc sprawdź aktualną kwotę przy kasie, zamiast oceniać plan tylko na podstawie reklamowanej miesięcznej stawki.

Wniosek cenowy: Nie kupuj wyższego planu tylko po to, aby uzyskać dostęp do Connector. Wybierz plan zgodnie z liczbą stron internetowych i aplikacji webowych, których potrzebujesz, wymaganymi zasobami oraz poziomem wsparcia, jaki chcesz mieć. Connector jest dołączoną warstwą zarządzania, a nie głównym produktem, za który płacisz.

Hostinger reklamuje 30-dniową gwarancję zwrotu pieniędzy dla kwalifikujących się zakupów hostingu. Nie ma osobnej polityki zwrotów dla Connector, ponieważ Connector nie wiąże się z samodzielną opłatą.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Odwiedź Hostinger

Funkcje

• Wdrażanie aplikacji Node.js
• Wdrażanie PHP i HTML
• Zarządzanie stronami WordPress
• Workflow dla Website Builder i Horizons
• Wdrożenia połączone z GitHub
• Łączenie i organizacja domen
• Inspekcja i aktualizacja DNS
• SSL i diagnostyka strony
• Zarządzanie bazami danych
• Konfiguracja i administracja VPS
• Wdrażanie projektów Docker
• Monitorowanie CPU i pamięci
• Kontrola pasma i miejsca na dysku
• Restart usług i kontenerów
• Skanowanie w poszukiwaniu złośliwego oprogramowania
• Przywracanie kopii zapasowych
• Konfiguracja kampanii e-mailowych
• Inspekcja wdrożeń i buildów

Dokładne dostępne działania zależą od usług Hostinger w Twoim koncie oraz narzędzi udostępnionych podłączonemu klientowi AI.

Hostinger dokumentuje też limity liczby zapytań. Zgodnie z FAQ Connector domyślne limity wynoszą 60 żądań na minutę i 1,000 żądań na godzinę, a informacje o limicie są zwracane w nagłówkach odpowiedzi.

Te limity są bardzo szerokie do interaktywnego użycia, choć zautomatyzowane lub bardzo powtarzalne workflow powinny nadal unikać zbędnych, duplikowanych wywołań.

Łatwość użycia

1. Instalacja i uwierzytelnianie

Zanim mogłem ocenić, czy Hostinger Connector dobrze wdraża i obsługuje hosting, musiałem wiedzieć, co trzeba zrobić, aby w ogóle go uruchomić.

Narzędzie zbudowane wokół pozostawania w edytorze szybko traci sens, jeśli konfiguracja wymaga edycji plików konfiguracyjnych, generowania tokenów API lub wielokrotnego ponownego uwierzytelniania. Ta sekcja dotyczy wyłącznie konfiguracji. Praktyczne testy zadań pojawiają się zaraz potem.

Instalowanie rozszerzenia

Zainstalowałem Hostinger Connector z VS Code Marketplace. Pojawiło się jako pierwszy wynik po wyszukaniu „Hostinger”, wydawcą był Hostinger Official, a instalacja powiodła się za pierwszym razem w mniej niż dwie minuty.

Ten ostatni wiersz warto skomentować. Pięć gwiazdek brzmi dobrze, ale próbka dwóch recenzji nie mówi mi prawie nic o typowym doświadczeniu użytkownika. Nie opierałbym na tej liczbie treści recenzji.

Jedno wymaganie mnie zaskoczyło: Hostinger Connector dostarcza narzędzia Hostinger, ale potrzebuje już aktywnego agenta AI w edytorze, aby w ogóle móc z nich korzystać.

Samo rozszerzenie nie ma z czym się komunikować. W VS Code tym agentem jest GitHub Copilot Chat, ponieważ to obecnie interfejs AI, który VS Code udostępnia do wywołań narzędzi MCP. Ja miałem już aktywnego Copilota, więc nie spowolniło mi to pracy, ale czytelnicy powinni wiedzieć, że Connector jest użyteczny tylko tak bardzo, jak użyteczny jest stojący za nim agent AI w edytorze.

Bez zainstalowanego i zalogowanego agenta nie ma się z czym połączyć.

Instalacja nie wymagała:

• klucza API
• tokena skopiowanego z hPanel
• ręcznej edycji pliku konfiguracyjnego MCP
• lokalnie przechowywanych danych uwierzytelniających
• niestandardowego polecenia serwera

Instalacja samego rozszerzenia była jedną z najłatwiejszych części całego testu. Jedyny prawdziwy haczyk to zależność, którą Hostinger nie eksponuje wystarczająco wyraźnie: rozszerzenie potrzebuje aktywnego agenta AI w edytorze, aby cokolwiek robić.

Gdy rozszerzenie było już zainstalowane, kolejne pytanie brzmiało, czy połączenie go z prawdziwym kontem będzie równie proste.

Łączenie konta

Połączenie konta odbywało się przez OAuth za pomocą przycisku „1-Click Connect”. VS Code otworzył w przeglądarce stronę autoryzacji Hostinger, wykrył moją istniejącą sesję Hostinger i poprosił o zatwierdzenie dostępu dla czegoś oznaczonego jako hostinger-mcp.

Po kliknięciu Allow wróciłem do VS Code z komunikatem „Connected via OAuth”.

Ekran autoryzacji poinformował mnie, że Connector może zarządzać stronami internetowymi, hostingiem, domenami, subskrypcjami i innymi usługami Hostinger.

To lista kategorii, a nie szczegółowy podział uprawnień. Chciałbym tutaj większej granularności, ponieważ „zarządzanie subskrypcjami” i „zarządzanie stronami internetowymi” oznaczają bardzo różne poziomy ryzyka.

To, co dało mi pewną kontrolę, to osobny panel w rozszerzeniu, który wyświetlał każdą kategorię narzędzi i pozwalał włączać lub wyłączać każdą z nich osobno:

To razem 199 narzędzi, z czego 125 było włączonych domyślnie. Zostawiłem Ecommerce i VPS wyłączone, dopóki nie byłem gotowy przetestować ich bezpośrednio, a rozszerzenie respektowało tę granicę przez cały czas testów.

To właśnie ten rodzaj detalu dotyczącego bezpieczeństwa nie pojawia się na stronie marketingowej Hostinger, a jednak ma znaczenie dla każdego, kto decyduje, ile dostępu powierzyć asystentowi AI. Nazwałbym to prawdziwą zaletą.

Odłączenie konta jest dostępne z tego samego panelu, bez potrzeby zmieniania hasła Hostinger czy szukania zapisanego tokena.

Autoryzacja była szybka i nie wymagała ode mnie zarządzania tokenem, ale ekran uprawnień jest ogólny, a nie szczegółowy. Kontrola narzędzi na poziomie kategorii w rozszerzeniu robi więcej, by ograniczyć realne ryzyko, niż ekran OAuth.

Obsługiwane edytory

Hostinger podaje obsługę następujących klientów, zebranych z ekranu onboardingu rozszerzenia:

Używałem VS Code z GitHub Copilot jako głównego środowiska testowego.

Konfiguracja pokazała mi, że Connector łatwo uruchomić. Nie powiedziała jeszcze nic o tym, czy naprawdę dobrze wykonuje zadania po połączeniu, a to trudniejsze pytanie rozpatrzyłem dalej.

2. Hostinger Connector w akcji

Instalacja i połączenie rozszerzenia to łatwa część. Liczy się to, czy wykonuje prawdziwą pracę hostingową poprawnie, więc zbudowałem małą aplikację Express.js o nazwie PulseWatch i poddałem Connector tej samej ścieżce, jaką przeszedłby deweloper po instalacji: sprawdzenie konta, znalezienie celu wdrożenia, wdrożenie projektu, aktualizacja go, sprawdzenie wyników i odzyskanie działania po błędzie, który wprowadziłem celowo.

PulseWatch był celowo prosty: serwer Express, strona główna, skrypt startowy package.json  oraz endpoint /api/health  zwracający JSON. Ten endpoint health okazał się później ważny.

Platforma hostingowa może zgłosić ukończony build, mimo że aplikacja nie uruchamia się poprawnie. Aktywny endpoint dał mi niezależny sposób sprawdzenia, czy wdrożony proces faktycznie odpowiadał, zamiast ufać plakietce statusu.

Odczytywanie danych konta

Zacząłem od promptów tylko do odczytu, zanim pozwoliłem asystentowi zbliżyć się do jakichkolwiek zmian na żywo. Jeśli nie potrafiłby dokładnie opisać mojego konta, miałbym mało powodów, by ufać mu przy wdrożeniach, DNS czy zadaniach VPS.

Narzędzie listujące strony w Connector zwróciło pięć witryn:

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

Moje konto faktycznie zawierało więcej. hPanel pokazywał strony rozłożone na planach Premium, Business i Growth, w tym witryny WordPress, witryny PHP/HTML, projekty Website Builder oraz kilka tymczasowych domen.

W osobnym promptcie, pytając o moje aktywne plany hostingowe, asystent powiedział mi, że mam „jeden aktywny plan hostingowy”. hPanel pokazywał trzy: Premium, Growth i Business.

Sprawiedliwie mówiąc o Connector, gdy zakwestionowałem wynik i wskazałem rozbieżność, poprawił się, wyraźnie oddzielił to, co zweryfikował, od tego, co założył, i nie powtórzył błędnego twierdzenia.

To lepszy sposób reagowania na błąd niż upieranie się przy swoim, ale oznacza to, że pierwszej odpowiedzi na pytanie dotyczące całego konta nie należy brać za pewnik.

Odczyt tylko do wglądu działał, ale pierwsza odpowiedź na jakiekolwiek pytanie dotyczące całego konta była niepełna. Skorygował się po zakwestionowaniu, co ma znaczenie, ale nie powinienem był musieć go kwestionować.

Ta luka w widoczności konta okazała się zapowiedzią większego problemu. Prawdziwy test tego, czy miało to znaczenie, przyszedł następnie, gdy poprosiłem Connector o znalezienie strony internetowej, której nie nazwano mu wcześniej.

Znajdowanie celu wdrożenia

To tutaj test ujawnił najwięcej. Poprosiłem asystenta, aby zidentyfikował nowo utworzoną stronę Node.js bez podawania mi jej domeny i bez dotykania jakiejkolwiek istniejącej strony.

Wybór celu to podstawowy wymóg bezpieczeństwa dla narzędzia, które może działać na żywym koncie, więc chciałem zobaczyć, jak poradzi sobie z niepewnością, a nie z gotową odpowiedzią.

Oto, co się wydarzyło, krok po kroku:

Główny problem: dwa identyfikatory, których użył, były identyfikatorami zasobów domeny, a nie identyfikatorami zamówień hostingowych. Nigdy nie potwierdził tej różnicy, zanim wywołał z ich użyciem narzędzie do tworzenia żywej strony.

Kiedy poprosiłem go o wyjaśnienie, asystent ostatecznie podał trafny opis: miał cały czas dostępne działające narzędzie do listowania stron, ale nie wywołał go ponownie po tym, jak utworzyłem nową stronę przez hPanel, więc wypełnił lukę niezweryfikowaną domeną zamiast odświeżyć dane.

Kiedy poprosiłem go bezpośrednio o ponowne uruchomienie tego narzędzia do listowania i sprawdzenie, czy pojawił się nowy rekord, wywołał trzy niepowiązane narzędzia do wyszukiwania wdrożeń i stwierdził, że „nie pojawiła się żadna nowa strona internetowa”, choć wywołania, których faktycznie użył, nie mogły uzasadniać takiego wniosku.

Nic z tego nie utworzyło żadnej przypadkowej strony w moim koncie. Nieudane wywołania niczego nie pozostawiły. Ale wzorzec warto nazwać wprost. Przy niepełnych danych asystent wypełnił lukę wiarygodnie brzmiącym założeniem, potraktował słaby sygnał jak mocny dowód i działał na żywym koncie, zanim to założenie zostało sprawdzone.

To najważniejsze odkrycie w tej sekcji. Connector będzie zgadywał cel i działał na tym założeniu zamiast się zatrzymać i zapytać. Tutaj nie spowodował szkody, ale nawyk traktowania słabego sygnału jak dowodu to rzecz, na którą trzeba uważać we własnym koncie.

Skoro Connector nie potrafił samodzielnie znaleźć celu, zostało mi jedno wyjście: utworzyć cel samemu i sprawdzić, czy to coś zmieni.

Kończenie konfiguracji w hPanel

Ponieważ Connector nie potrafił wiarygodnie zlokalizować nowego celu samodzielnie, zakończyłem początkową konfigurację ręcznie przez hPanel, aby sprawdzić, co Hostinger przygotowuje, zanim wdrożenie przez Connector stanie się możliwe.

Ścieżka wyglądała tak: Utwórz nową stronę → aplikacja webowa Node.js → tymczasowa domena → Hostinger automatycznie wybrał centrum danych w Wielkiej Brytanii z szacowanym opóźnieniem 147ms → wybór spośród trzech metod wdrożenia.

Ten trzeci ekran warto wyróżnić samodzielnie. Hostinger oferuje „Build with Hostinger Connector” jako metodę wdrożenia obok importu z GitHub i ręcznego przesyłania plików. Wybrałem ją, oczekując, że dokończy konfigurację strony.

Zamiast tego przekierowała mnie na stronę instalacyjną samego Connector, którą już wcześniej ukończyłem. To prawdziwa luka w onboardingu. Opcja przedstawiona jako natywna ścieżka Connector tak naprawdę niczego nie konfigurowała.

Wróciłem i wybrałem zamiast tego ręczne przesyłanie plików. Hostinger zaakceptował archiwum mojego projektu (11.46 KB, z wykluczonym node_modules ), a ekran ustawień pokazał trafne automatyczne rozpoznanie:

• Preset frameworka: Express
• Wersja Node: 22.x
• Katalog główny: ./

Kliknąłem Deploy. Zakończyło się to pomyślnie, a Hostinger przypisał prawdziwą tymczasową domenę: orange-walrus-700988.hostingersite.com. To inna domena niż ta, którą Connector wymyślił wcześniej. Otworzyłem zarówno stronę główną, jak i /api/health ręcznie i potwierdziłem, że obie działają.

Ręczna ścieżka zadziałała bez problemów, gdy przestałem czekać, aż Connector ją znajdzie. Przycisk „Build with Hostinger Connector” na tym ekranie powinien zostać naprawiony albo usunięty. Obecnie obiecuje coś, czego nie robi.

Prawdziwa, potwierdzona strona teraz istniała. Następne pytanie brzmiało, czy Connector zachowa się inaczej, gdy będzie miał coś pewnego do znalezienia.

Wdrażanie i aktualizacja działającej aplikacji

Gdy istniała już prawdziwa, potwierdzona strona, wróciłem do Connector i poprosiłem go o sprawdzenie dokładnie tej domeny. Tym razem zadziałało to poprawnie.

To potwierdziło coś ważnego: wcześniejsze niepowodzenia dotyczyły lokalizowania i tworzenia nowego celu, a nie zdolności Connector do pracy z witryną Node.js, gdy taka już istnieje.

Następnie przetestowałem funkcję, którą Hostinger promuje najmocniej: wprowadzenie lokalnej zmiany w kodzie i opublikowanie jej bez otwierania hPanel.

Poprosiłem asystenta o zmianę jednego wiersza tekstu na stronie głównej z „Monitor Every Service. Catch Every Issue.” na „Monitor Every Service. Resolve Issues Faster.”

Cała aktualizacja zajęła około minuty. Asystent od razu po wysłaniu zgłoszenia podał nowe wdrożenie jako „pending”, po prostu dlatego, że sprawdził zanim Hostinger skończył przetwarzanie.

Do momentu, gdy sam odświeżyłem działającą stronę, nowy nagłówek był już widoczny.

Pobrane później logi buildu były konkretne i użyteczne: dodano 67 pakietów, sprawdzono 68, nie znaleziono żadnych podatności, brak błędów.

W przypadku istniejących witryn jest to bardzo bliskie workflow, które obiecuje Hostinger: edytuj, zweryfikuj lokalnie, opublikuj i potwierdź, wszystko bez opuszczania edytora, w około minutę. To najlepszy wynik w całym teście.

Sprawne wdrożenie mówi mi tylko, że happy path działa. Aby zobaczyć, co Connector robi pod presją, celowo zepsułem aplikację.

Testowanie odzyskiwania po awarii

Narzędzie zasługuje na zaufanie tylko wtedy, gdy poradzi sobie z prawdziwą awarią, a nie tylko z czystą demonstracją. Celowo zepsułem aplikację, aby sprawdzić, czy statusy i logi Connector naprawdę pomogą mi zdiagnozować problem.

Zanim wprowadzono jakiekolwiek zmiany, asystent zrobił kopię zapasową package.json do package.json.bak, co samo w sobie jest dobrym nawykiem.

Następnie poprosiłem go o zmianę skryptu startowego z „start”: „node server.js” na „start”: „node missing-server.js”, plik, który nie istnieje.

Uruchomienie lokalnie potwierdziło rzeczywisty, odtwarzalny błąd: Error: Cannot find module ‘…/missing-server.js’.

Wdrożyłem uszkodzoną wersję mimo wszystko, celowo, aby zobaczyć, co Hostinger zgłosi.

Logi buildu dostępne przez Connector pokazywały pomyślną instalację zależności i nic więcej. Błąd runtime związany z brakującym modułem nie pojawił się w nich. Deweloper patrzący na zieloną plakietkę „completed” nie miałby powodu podejrzewać, że strona jest zepsuta.

Odzyskiwanie przebiegło gładko. Asystent przywrócił package.json z kopii zapasowej, zweryfikował aplikację lokalnie, ponownie wdrożył i potwierdził poprawkę, wywołując bezpośrednio działający endpoint /api/health zamiast ufać statusowi wdrożenia.

Ten endpoint zwrócił odpowiedź operacyjną, a to był jedyny dowód w całym teście, który naprawdę potwierdzał, że aplikacja działała.

To drugie ważne odkrycie. Status „completed” nie jest dowodem na działającą aplikację, a własne logi Connector też tego nie pokażą. Samo odzyskanie działania przebiegło dobrze, gdy już wiedziałem, że istnieje problem do naprawienia.

Po awarii, której plakietka statusu nie potrafiła ujawnić, chciałem sprawdzić, gdzie jeszcze pewność Connector może wyprzedzać jego rzeczywiste możliwości. Następne były zmienne środowiskowe.

Próba konfiguracji zmiennej środowiskowej

Poprosiłem asystenta o dodanie nieszkodliwej zmiennej środowiskowej, potwierdzenie, że ustawienie istnieje jako dedykowana funkcja Connector, zanim cokolwiek zrobi, oraz zatrzymanie się, jeśli nie istnieje.

Przeszukał dostępne narzędzia, nie znalazł żadnej dedykowanej akcji do zarządzania zmiennymi środowiskowymi Node.js i zatrzymał się, zanim wprowadził jakiekolwiek zmiany w kodzie lub wdrożeniu.

To właśnie jest zachowanie, które chciałem widzieć wszędzie indziej w tym teście. W obliczu prawdziwego ograniczenia zatrzymał się zamiast zgadywać. Nie wyciągałbym z tego wniosku, że Hostinger Connector nie ma nigdzie obsługi zmiennych środowiskowych, tylko że podczas tego testu nie udostępniono takiej akcji. 

Podsumowanie testu awarii i odzyskiwania

Co test mówi o niezawodności

Hostinger Connector dobrze wykonywał rutynowe, deterministyczne zadania:

• Odczytywanie znanych rekordów wdrożeń
• Edycja określonego pliku
• Uruchamianie lokalnych poleceń
• Pakowanie projektu
• Wdrażanie do znanej strony internetowej
• Sprawdzanie statusu buildu
• Pobieranie dostępnych logów
• Przywracanie i ponowne wdrażanie znanej dobrej wersji

Był słabszy, gdy zadanie wymagało interpretacji niepełnych danych konta:

• Identyfikacja nowo utworzonej strony internetowej
• Rozróżnienie dostępności domeny od istnienia strony
• Ustalenie, czy ukończony build oznaczał, że aplikacja była sprawna

Taki wzorzec jest przydatny przy decyzji, ile autonomii dać asystentowi.

Używaj szerszych promptów do inspekcji niskiego ryzyka. Używaj precyzyjnych promptów i wyraźnych wymagań potwierdzenia przy działaniach zmieniających aktywną infrastrukturę.

Na przykład zamiast:

użyj:

Drugi prompt zawęża przestrzeń na założenia po stronie asystenta.

Ogólny werdykt na temat łatwości użycia

Uruchomienie Hostinger Connector było łatwe, bez zwykłych tarć związanych z konfiguracją, a szczegółowe sterowanie kategoriami narzędzi dało mi realny wpływ na to, czego AI może dotykać.

Gdy już istniała prawdziwa strona z znaną domeną, narzędzie dobrze wykonało zadanie: jedna zmiana w tekście z edycji do publikacji na żywo zajęła około minuty, a wszystko poparte było użytecznymi logami buildu.

Problem pojawił się wcześniej, a nie później. W obliczu nowego celu, którego nie potrafił znaleźć, Connector wymyślił domenę i działał na niej, zanim ją sprawdził. Oznaczył też zepsute wdrożenie jako „completed”, mimo że aplikacja w rzeczywistości nie działała, a w jego własnych logach nie było błędu w czasie działania. Żadne z tych dwóch zjawisk nie czyni narzędzia niewiarygodnym dla istniejących stron, ale oba oznaczają, że nowe wdrożenia i status po wdrożeniu wymagają dodatkowego sprawdzenia, zanim mu zaufasz.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Odwiedź Hostinger

Poziom wsparcia

Hostinger buduje swoje wsparcie wokół czatu na żywo i samoobsługi, a nie rozmów telefonicznych, więc skupiłem test tam, gdzie większość użytkowników faktycznie trafi: asystent AI wbudowany w hPanel, ludzkie wsparcie za nim oraz baza wiedzy, do której deweloper sięgnie, zanim otworzy czat.

Kanały wsparcia

Ponieważ czat na żywo to kanał, który Hostinger wskazuje deweloperom do spraw pilnych, i ten, z którego najpewniej korzysta się podczas debugowania wdrożenia, przetestowałem tę ścieżkę bezpośrednio zamiast wysyłać zgłoszenie e-mailem.

Czat na żywo: Kodee i przekazanie do człowieka

Otworzyłem czat na żywo przez „Ask AI” w hPanel i zadałem Kodee pytanie z prawdziwą odpowiedzią do zepsucia: czy status ukończonego buildu na wdrożeniu Node.js gwarantuje, że aplikacja faktycznie działa, i gdzie znalazłbym dowód na coś przeciwnego.

Pierwsza odpowiedź Kodee była konkretna i poprawna:

„Completed” zwykle oznacza, że etap buildu zakończył się pomyślnie; nie gwarantuje, że aplikacja jest sprawna po uruchomieniu. Aby wychwycić błędne polecenie startowe lub inny błąd w czasie działania, sprawdź logi runtime: w hPanel przejdź do Websites → Dashboard → Deployments, aby zobaczyć logi buildu, a następnie otwórz plik stderr.log w folderze nodejs w poszukiwaniu błędów startowych, takich jak Port already in use lub Module not found.

Ta pojedyncza odpowiedź rozwiązałaby dokładnie tę niejasność, na którą natknąłem się wcześniej w teście odzyskiwania działania w tej recenzji. Kodee nazwał prawdziwy plik logu, właściwy folder i poprawnie rozróżnił sukces buildu od sprawności runtime.

Chciałem jednak też sprawdzić, czy mogę dostać się do prawdziwego ludzkiego agenta, więc powiedziałem Kodee, że chciałbym potwierdzić to bezpośrednio z pracownikiem wsparcia.

Ale uzyskanie człowieka na linii było trudniejsze, niż się spodziewałem. Poprosiłem bezpośrednio o żywego agenta i zostałem dwa razy przekierowany z powrotem do Kodee, za każdym razem z sugestią, że to szybsze niż czekanie:

Rozumiem, dlaczego chcesz tego. Mogę pomóc Ci zweryfikować build, polecenie startowe i logi runtime tutaj, co zwykle jest najszybszym sposobem ustalenia problemu.

Zanim połączymy Cię ze specjalistą. Mogę rozwiązać problem i oszczędzić Ci czekania.

Minęły dwie bezpośrednie, jednoznaczne prośby, zanim Kodee przestał odsyłać mnie z powrotem do siebie. W przypadku pytania, które mogłem rozwiązać sam, to niewielka niedogodność. Dla kogoś w trakcie awarii, kto chce porozmawiać z człowiekiem, to realny powód frustracji.

To, co stało się później, nie było przekazaniem w czasie rzeczywistym w takim sensie, jaki zwykle kojarzy się z „połącz mnie z człowiekiem”. Kodee wyjaśnił model działania wprost:

Przekazałem Twoją prośbę specjaliście z naszego zespołu, który osobiście przejrzy naszą rozmowę i wyśle mi swoją odpowiedź, a ja przekażę ją Tobie tutaj.

To asynchroniczny przegląd, a nie bezpośrednie przekazanie. Kodee pozostaje interfejsem; człowiek przegląda zapis rozmowy w tle, a Kodee przekazuje odpowiedź, gdy ta nadejdzie. Ta różnica ma znaczenie dla czytelników zastanawiających się nad eskalacją, ponieważ „ludzki agent” tutaj nie oznacza, że nowa osoba dołącza do okna czatu tak jak w większości systemów live-chat.

Pociągnąłem ten sam techniczny wątek dalej, czekając, prosząc Kodee o potwierdzenie dokładnej ścieżki logu i tego, czy stderr.log zawsze jest wypełniony. Odpowiedział poprawnie samodzielnie, zauważając, że log może być pusty, jeśli aplikacja nigdy nie uruchomiła się do końca lub zapisała błąd gdzie indziej.

Odpowiedź specjalisty pojawiła się po około 3 minutach, przypisana w czacie do osoby o imieniu Mayas, i była lepsza niż odpowiedź Kodee, a nie tylko jej powtórzeniem:

domains/[your-domain]/nodejs/stderr.log to właściwa lokalizacja. Nie zawsze jest ona tworzona ani wypełniana. Zobaczysz tam wpisy tylko wtedy, gdy aplikacja zapisuje do stderr, na przykład przy nieobsłużonych wyjątkach lub odrzuconych obietnicach. Jeśli polecenie startowe jest błędne, a proces kończy się bezgłośnie, stderr.log może być pusty albo go nie być.

Mayas dodał też dwa alternatywne sprawdzenia, których Kodee nie wymienił: sprawdzenie stdout.log w poszukiwaniu ostatniego wyjścia przed awarią oraz szukanie brakującej linii potwierdzającej uruchomienie jako oznaki, że aplikacja nigdy się nie rozpoczęła.

Baza wiedzy

Baza wiedzy Hostinger jest podzielona na szerokie kategorie produktów: Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel i About Hostinger.

Żadna z tych kategorii nie jest poświęcona Hostinger Connector. Jedyny sposób, w jaki znalazłem właściwy artykuł, to bezpośrednie wyszukanie „Hostinger Connector”, co zwróciło pięć wyników, z których większość była tylko luźno powiązana, w tym poradnik o wtyczce do marketingu afiliacyjnego oraz ogólny artykuł o hostingu Node.js.

Artykuł, który faktycznie dokumentuje konfigurację Connector, nosi tytuł „How to Set Up Web Hosting MCP on Local IDEs” i znajduje się w Features → General Information.

Wyszukanie marketingowej nazwy produktu go znalazło, ale czytelnik przeglądający kategorie lub szukający „MCP” bez znajomości nazewnictwa Hostinger mógłby go równie łatwo przeoczyć, a rozbieżność między nazwą marketingową a nazwą w dokumentacji warto znać, zanim zaczniesz szukać.

Sam artykuł jest bardzo dobry, gdy już go znajdziesz. Został ostatnio zaktualizowany sześć dni przed moim testem i obejmuje:

• Zalecioną konfigurację OAuth jednym kliknięciem przez rozszerzenie
• Ręczną ścieżkę konfiguracji z użyciem tokena API, dla IDE, których rozszerzenie nie obsługuje bezpośrednio
• Dokładne ścieżki plików konfiguracyjnych dla Mac, Linux i Windows
• Pełne przykłady konfiguracji JSON
• Krok po kroku prompt weryfikacyjny do potwierdzenia, że połączenie działa
• Którzy obsługiwani klienci wykrywają połączenie automatycznie, a którzy wymagają ręcznego wpisania konfiguracji

Ten ostatni punkt zgadzał się z czymś, co sam napotkałem podczas testów: Devin Desktop jest wykrywany automatycznie, a OpenAI Codex wymaga metody ręcznej. Artykuł poprawnie rozróżnia te przypadki.

Ogólny werdykt na temat wsparcia

Pierwsza odpowiedź Kodee na trudne pytanie techniczne była trafna i konkretna, co nie jest czymś, z czym każdy asystent AI do wsparcia sobie radzi. Artykuł w bazie wiedzy, który to potwierdza, jest aktualny i szczegółowy, gdy już go znajdziesz, chociaż marketingowa nazwa produktu i tytuł dokumentacji nie są zgodne, więc wyszukiwanie jest pewniejszą drogą niż przeglądanie kategorii.

Słabszym punktem jest ścieżka eskalacji do człowieka. Kodee dwa razy odsyłał mnie z powrotem do siebie, zanim uznał bezpośrednią prośbę o osobę, a nawet wtedy „ludzki agent” oznacza asynchroniczny przegląd przekazywany przez ten sam czat, a nie bezpośrednie połączenie. Gdy człowiek już się temu przyjrzał, odpowiedź była lepsza niż odpowiedź samego Kodee, bardziej precyzyjna i z dwoma dodatkowymi krokami diagnostycznymi, których Kodee nie zaoferował.

W przypadku większości pytań sam Kodee da Ci szybko trafną odpowiedź. Jeśli naprawdę chcesz, aby człowiek potwierdził odpowiedź, przygotuj się na to, że będziesz musiał poprosić więcej niż raz, i oczekuj krótkiego oczekiwania na odpowiedź przekazaną w wiadomości, a nie na żywą rozmowę.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Odwiedź Hostinger

Końcowy werdykt: czy Hostinger Connector jest wart używania?

Tak, dla deweloperów, którzy już hostują w Hostinger i chcą, aby rutynowe wdrożenia były obsługiwane z poziomu edytora. Konfiguracja zajęła minuty, OAuth wyeliminował potrzebę kluczy API, a gdy istniała już strona z znaną domeną, Connector wypchnął aktualizację na żywo w około minutę z logami potwierdzającymi działanie. Własne odpowiedzi wsparcia Kodee były na tyle trafne, że rozwiązały prawdziwy problem techniczny za pierwszym razem.

Haczyk dotyczy zaufania, nie wygody. Gdy dostał nowy cel, którego nie mógł znaleźć, Connector wymyślił domenę i działał na tym założeniu, zanim je sprawdził.

Oznaczył też zepsute wdrożenie jako „completed”, mimo że aplikacja faktycznie nie działała, a w jego logach nie było błędu w czasie działania. Używaj go, aby przyspieszyć pracę na już istniejących stronach, weryfikuj wszystko, co robi na nowym celu, i sprawdzaj działającą stronę samodzielnie po każdym wdrożeniu, które ma znaczenie.

Hostinger

5.0

2,470 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