Správa hostingu obvykle přerušuje vývoj. Píšete kód v editoru, otevřete hostingový panel, abyste vytvořili web, přepnete do terminálu, abyste projekt zabalili nebo odeslali, vrátíte se do panelu, abyste zkontrolovali nasazení, a otevřete další nástroje, když je potřeba řešit DNS, logy nebo zdroje serveru.

Hostinger Connector toto přepínání mezi kontexty omezuje. Propojuje služby Hostinger s AI nástroji pro kódování prostřednictvím Model Context Protocol (MCP), takže se můžete zeptat AI asistenta na kontrolu nebo správu podporovaných hostingových zdrojů, aniž byste opustili svůj editor.

To zní pohodlně. Zároveň to vyvolává důležitější otázku: Můžete důvěřovat AI asistentovi, že bude přesně vykonávat skutečné hostingové úkoly?

Abych to zjistil, otestoval jsem Hostinger Connector s VS Code a GitHub Copilot na skutečném účtu Hostinger. Použil jsem malou Express.js aplikaci s názvem PulseWatch a postupoval jsem workflow od instalace až po živé nasazení. Testoval jsem také opakovaná nasazení, záznamy buildů, logy a zotavení po záměrném rozbití startovacího příkazu aplikace.

Hostinger Connector Plans with Hostinger

Integrujte Hostinger s aplikacemi a službami, které již používáte, abyste automatizovali úkoly, zlepšili workflow a spravovali svůj web efektivněji.

Navštivte Hostinger

Klady a zápory Hostinger Connector

Tip

Odborný tip: Před testováním nasazovacích promptů si vytvořte dedikovaný dočasný web. Hostinger Connector pracuje s živými zdroji účtu, takže testovací cíl vám dá prostor naučit se workflow bez rizika pro zavedený web.

Rozpis hodnocení

Zde je, jak jsem ohodnotil Hostinger Connector v oblastech, které jsou pro vývojáře při rozhodování, zda nástroj používat, nejdůležitější: cena, rozsah funkcí, každodenní použitelnost, jak přesně vykonává skutečné úkoly, a podpora, která za ním stojí, když se něco pokazí. Každé skóre odráží to, co jsem skutečně zjistil během testování, ne marketingovou stránku.

Parametr	Skóre	Proč toto skóre
Ceny	9.7/10	Connector nemá žádný samostatný poplatek za předplatné a je zdarma součástí každého plánu. Jediné náklady jsou za samotný hostingový ресурс, který byste potřebovali tak jako tak.
Funkce	9.5/10	Rozsah funkcí sahá za nasazování až k webům, doménám, DNS, databázím, e-mailovým kampaním, VPS zdrojům, logům a diagnostice, takže pokrývá více oblastí než běžný nástroj pro nasazování.
Snadnost použití	9.1/10	Instalace a OAuth byly rychlé a nevyžadovaly ruční konfiguraci, a opakovaná nasazení byla snadná. Počáteční nastavení webu Node.js vyžadovalo hPanel poté, co AI nedokázala identifikovat platný cíl, což je jediný skutečný nedostatek jinak plynulého nastavení.
Přesnost provedení	8.5/10	Analýza projektu, úpravy kódu, balení, nasazení a zotavení fungovaly dobře. AI znovu použila vymyšlenou doménu a předtím, než takový cíl existoval, si příliš vyložila kontrolu přístupnosti.
Podpora	9.5/10	Kodee dal přesnou a konkrétní odpověď na skutečnou technickou otázku hned napoprvé a následná odpověď lidského specialisty byla ještě přesnější. Eskalace vyžadovala dva přímé požadavky, ale jak AI, tak lidské odpovědi byly spolehlivé, jakmile se k nim dostaly.
Celkem	9.3/10	Užitečný pracovní nástroj pro uživatele Hostinger, kteří pracují v editorech s podporou AI. Nestojí nic navíc, pokrývá širokou škálu funkcí a jak nastavení, tak podpora v testu obstály dobře. Přesnost provedení u nových nasazovacích cílů je oblast, na kterou je třeba dávat pozor.

Plány a ceny Hostinger Connector

Hostinger Connector se neprodává jako samostatný produkt. Hostinger uvádí, že Connector je zdarma součástí každého plánu, což znamená, že k vašemu hostingovému účtu nepřidává žádný samostatný měsíční poplatek.

„Zdarma“ ale potřebuje kontext. Connector spravuje zdroje Hostinger; nenahrazuje je. Stále potřebujete způsobilý hosting, cloud, VPS, doménu, e-mail nebo jinou službu Hostinger pro úkoly, které má vykonávat.

V době této recenze stránka Connectoru zvýrazňovala Business Web Hosting a Cloud Startup.

Plán	Akční cena	Zobrazená předplacená délka	Obnovovací cena	Web appy	Weby
Business	$3.79/month	$181.92 for 48 months	$16.99/month	5	50
Cloud Startup	$7.99/month	$383.52 for 48 months	$25.99/month	10	Unlimited

Ceny byly zobrazeny před příslušnými daněmi. Akční ceny a obnovovací sazby se mohou změnit, proto si zkontrolujte aktuální částku při pokladně, místo abyste soudili plán jen podle inzerované měsíční ceny.

Poznámka k cenám: Nepoužívejte vyšší plán jen kvůli přístupu k Connectoru. Vyberte plán podle počtu webů a web app, které potřebujete, podle zdrojů, jež vyžadují, a podle úrovně podpory, kterou chcete. Connector je zahrnutá vrstva pro správu, ne hlavní produkt, za který se platí.

Hostinger uvádí 30denní záruku vrácení peněz pro způsobilé hostingové nákupy. Neexistuje žádná samostatná politika vrácení peněz za Connector, protože Connector nemá samostatný poplatek.

Hostinger Connector Plans with Hostinger

Integrujte Hostinger s aplikacemi a službami, které již používáte, abyste automatizovali úkoly, zlepšili workflow a spravovali svůj web efektivněji.

Navštivte Hostinger

Funkce

• Nasazování aplikací Node.js
• Nasazování PHP a HTML
• Správa webů WordPress
• Workflow pro Website Builder a Horizons
• Nasazování propojené s GitHubem
• Připojení a organizace domén
• Kontrola a aktualizace DNS
• SSL a diagnostika webu
• Správa databází
• Nastavení a správa VPS
• Nasazování Docker projektů
• Sledování CPU a paměti
• Kontrola přenosu dat a disku
• Restartování služeb a kontejnerů
• Kontrola malwaru
• Obnova záloh
• Nastavení e-mailových kampaní
• Kontrola nasazení a buildů

Konkrétní dostupné akce závisí na službách Hostinger ve vašem účtu a na nástrojích zpřístupněných připojenému AI klientovi.

Hostinger také dokumentuje limity rychlosti. Podle FAQ k Connectoru je výchozí limit 60 požadavků za minutu a 1,000 požadavků za hodinu, přičemž informace o limitu se vrací v hlavičkách odpovědí.

Tyto limity jsou pro interaktivní použití štědré, ale automatizované nebo vysoce opakované workflow by se přesto měly vyhýbat zbytečným duplicitním voláním.

Snadnost použití

1. Instalace a autentizace

Než jsem mohl posoudit, zda Hostinger Connector dobře nasazuje a spravuje hosting, potřeboval jsem zjistit, co je potřeba k jeho spuštění.

Nástroj postavený na tom, že zůstáváte v editoru, rychle ztratí své kouzlo, pokud nastavení znamená editaci konfiguračních souborů, generování API tokenů nebo opakovanou reautentizaci. Tato sekce se věnuje pouze nastavení. Praktické testování úloh přichází hned potom.

Instalace rozšíření

Hostinger Connector jsem nainstaloval z VS Code Marketplace. Při hledání „Hostinger“ se objevil jako první výsledek, vydavatel byl uveden jako Hostinger Official a instalace proběhla na první pokus za méně než dvě minuty.

Detail	Výsledek
Vyhledávání na marketplace	Prošlo, zobrazilo se okamžitě
Ověření vydavatele	Hostinger Official
Instalace	Dokončena za méně než dvě minuty
Verze rozšíření v době testování	1.3.1
Instalace z marketplace	8,140
Hodnocení uživatelů	5 hvězdiček, na základě dvou hodnocení

Poslední řádek stojí za upozornění. Pět hvězdiček zní silně, ale vzorek dvou recenzí mi neříká téměř nic o běžné uživatelské zkušenosti. Na toto číslo bych se v textu recenze nespoléhal.

Jedna podmínka mě překvapila: Hostinger Connector dodává nástroje Hostinger, ale ke skutečnému volání potřebuje v editoru už aktivního AI agenta.

Samotné rozšíření nemá s čím komunikovat. Ve VS Code je tímto agentem GitHub Copilot Chat, protože je to v současnosti AI rozhraní, které VS Code pro volání nástrojů MCP zpřístupňuje. Copilot jsem už měl aktivní, takže mě to nezpomalilo, ale čtenáři by měli vědět, že Connector je užitečný jen tehdy, když za ním v editoru běží odpovídající AI agent.

Bez nainstalovaného a přihlášeného agenta není na co se napojit.

Co instalace nevyžadovala:

• API klíč
• Token zkopírovaný z hPanel
• Ruční úpravu konfiguračního souboru MCP
• Lokálně uložené přihlašovací údaje
• Vlastní serverový příkaz

Instalace samotného rozšíření byla jednou z nejplynulejších částí celého testu. Jediný skutečný háček je závislost, kterou Hostinger nezdůrazňuje: rozšíření potřebuje aktivního AI agenta ve vašem editoru, aby vůbec něco dělalo.

Jakmile bylo rozšíření nainstalováno, další otázka zněla, zda bude připojení ke skutečnému účtu stejně jednoduché.

Připojení účtu

Připojení účtu proběhlo přes OAuth pomocí tlačítka „1-Click Connect“. VS Code otevřel v prohlížeči autorizační stránku Hostinger, rozpoznal mou existující relaci Hostinger a požádal mě o schválení přístupu pro něco označeného jako hostinger-mcp.

Po kliknutí na Allow jsem se vrátil do VS Code, kde bylo zobrazeno „Connected via OAuth“.

Kontrola	Výsledek
Jednoklikové připojení	Prošlo
Prohlížeč se otevřel automaticky	Prošlo
Byla detekována existující relace Hostinger	Prošlo
Vyžadován ruční API token	Ne
Zobrazena autorizační obrazovka	Ano
Oprávnění byla vysvětlena	Ano, ale obecně
Návrat do VS Code proběhl úspěšně	Prošlo

Autorizační obrazovka mi řekla, že Connector může spravovat weby, hosting, domény, předplatná a další služby Hostinger.

To je seznam kategorií, ne rozpis oprávnění po jednotlivých položkách. Tady bych ocenil větší granularitu, protože „spravovat předplatná“ a „spravovat weby“ představuje velmi odlišnou úroveň rizika.

Co mi dalo trochu víc kontroly, byl samostatný panel v rozšíření, který vypisoval všechny kategorie nástrojů a umožňoval každou z nich samostatně povolit nebo zakázat:

Kategorie nástrojů	Dostupné nástroje	Výchozí stav
Weby	80	Povoleno
Domény	26	Povoleno
Předplatné a platby	7	Povoleno
E-mailový marketing	12	Povoleno
E-commerce	12	Zakázáno
VPS	62	Zakázáno

To je celkem 199 nástrojů, z toho 125 povolených ve výchozím nastavení. E-commerce a VPS jsem nechal vypnuté, dokud jsem je nebyl připraven testovat přímo, a rozšíření toto omezení během testování respektovalo.

To je druh bezpečnostního detailu, který se na marketingové stránce Hostinger neobjeví, ale je důležitý pro každého, kdo se rozhoduje, kolik přístupu dát AI asistentovi k účtu. To bych označil za skutečnou přednost.

Tip

Před prvním skutečným promptem si zkontrolujte kategorie nástrojů. Vypnutí přístupu k VPS nebo E-commerce, dokud je skutečně nepotřebujete, omezuje, co může chybný prompt zasáhnout.

Odpojení účtu je dostupné ze stejného panelu, bez nutnosti měnit heslo Hostinger nebo hledat uložený token.

Autorizace byla rychlá a nevyžadovala, abych spravoval token sám, ale obrazovka s oprávněními je spíše široká než detailní. Opravdový způsob omezení rizika představují spíš kontroly kategorií nástrojů uvnitř rozšíření než samotná OAuth obrazovka.

Podporované editory

Hostinger uvádí podporu pro následující klienty, převzatou z úvodní obrazovky rozšíření:

Jako hlavní testovací prostředí jsem použil VS Code s GitHub Copilot.

Nastavení mi ukázalo, že Connector je snadno dostupný. Ještě nic neříkalo o tom, jestli skutečně dobře funguje, jakmile je připojen, což je těžší otázka, na kterou jsem se zaměřil dál.

2. Hostinger Connector v praxi

Instalace a připojení rozšíření je ta snadná část. Skutečně důležité je, jestli zvládá reálnou hostingovou práci správně, takže jsem postavil malou Express.js aplikaci PulseWatch a podrobil Connector stejné cestě, kterou by vývojář následoval po instalaci: zkontrolovat účet, najít nasazovací cíl, nasadit projekt, aktualizovat ho, zkontrolovat výsledky a zotavit se z poruchy, kterou jsem záměrně způsobil.

PulseWatch byl záměrně jednoduchý: Express server, domovská stránka, startovací skript v package.json a endpoint /api/health vracející JSON. Ten health endpoint se později ukázal jako důležitý.

Hostingová platforma může hlásit dokončený build, i když se aplikace při spuštění zhroutí. Živý endpoint mi dal nezávislý způsob, jak ověřit, zda nasazený proces skutečně odpovídá, místo abych věřil pouze stavové značce.

Čtení údajů o účtu

Začal jsem s pouze čtecími prompty, než jsem asistentovi povolil cokoli na živých změnách. Pokud nedokázal přesně popsat můj účet, měl bych jen malý důvod mu důvěřovat při nasazování, DNS nebo VPS akcích.

Nástroj Connectoru pro výpis webů vrátil pět webů:

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

Můj účet ve skutečnosti obsahoval víc. hPanel ukazoval weby rozložené přes plány Premium, Business a Growth, včetně WordPress webů, PHP/HTML webů, projektů Website Builder a několika dočasných domén.

V samostatném promptu, který se ptal na mé aktivní hostingové plány, mi asistent řekl, že mám „one active hosting plan“. hPanel ukazoval tři: Premium, Growth a Business.

Abych byl k Connectoru spravedlivý, když jsem ho upozornil na nesrovnalost, opravil se, jasně oddělil to, co ověřil, od toho, co předpokládal, a nesprávné tvrzení už neopakoval.

To je lepší selhání než tvrdohlavé trvání na omylu, ale znamená to, že první odpověď na otázku týkající se celého účtu by se neměla brát za bernou minci.

Čtecí přístup fungoval, ale první odpověď na jakoukoli otázku týkající se celého účtu byla neúplná. Po konfrontaci se opravil, což je důležité, ale neměl jsem ho k tomu nutit.

Tenhle nedostatek přehledu o účtu se ukázal jako předzvěst většího problému. Skutečný test, zda na tom záleží, přišel hned poté, když jsem Connector požádal, aby našel web, o kterém mu nebylo nic řečeno jménem.

Hledání nasazovacího cíle

Tady test odhalil nejvíc. Požádal jsem asistenta, aby identifikoval nově vytvořený web Node.js, aniž bych uvedl jeho doménu, a aniž by zasáhl do jakéhokoli existujícího webu.

Výběr cíle je základní bezpečnostní požadavek u nástroje, který může jednat na živém účtu, takže jsem chtěl vidět, jak si poradí s nejistotou, ne s jasnou odpovědí.

Takto to probíhalo, v pořadí:

Jádro problému: dvě ID, která použil, byla ID doménových zdrojů, ne hostingová order ID. Nikdy nepotvrdil rozdíl, než zavolal živý nástroj pro vytvoření webu s těmito údaji.

Když jsem ho požádal, aby to vysvětlil, asistent nakonec podal přesný popis: po celou dobu měl k dispozici funkční nástroj pro výpis webů, ale po vytvoření nového webu přes hPanel ho znovu nezavolal, takže místo obnovy dat vyplnil mezeru neověřenou doménou.

Když jsem ho přímo požádal, aby znovu spustil výpisový nástroj a zkontroloval nový záznam, místo toho zavolal tři nesouvisející nástroje pro vyhledání nasazení a oznámil, že „no new website appeared,“ přestože volání, která skutečně provedl, k takovému závěru nemohla vést.

Nic z toho nevytvořilo v mém účtu žádný nechtěný web. Neúspěšná volání po sobě nic nezanechala. Ale ten vzorec stojí za to pojmenovat naplno. Při neúplných datech asistent vyplnil mezeru pravděpodobně znějícím předpokladem, považoval slabý signál za silný důkaz a jednal na živém účtu ještě před tím, než byl tento předpoklad ověřen.

To je nejdůležitější zjištění této části. Connector si bude cíl domýšlet a jednat podle tohoto odhadu, místo aby se zastavil a zeptal. Tady selhal bezpečně, ale právě tento zvyk považovat slabý signál za důkaz je něco, na co si ve vlastním účtu dávejte pozor.

Protože Connector nedokázal nový cíl najít sám, zbývala mi jen jedna možnost: vytvořit cíl ručně a zjistit, jestli se tím něco změní.

Dokončení nastavení v hPanel

Protože Connector nedokázal spolehlivě najít nový cíl sám, dokončil jsem počáteční nastavení ručně v hPanel, abych zjistil, co Hostinger připravuje před tím, než je možné nasazení pomocí Connectoru.

Postup byl: Create a new site → Node.js web app → dočasná doména → Hostinger automaticky vybral datové centrum ve Spojeném království s odhadovanou latencí 147ms → na výběr byly tři způsoby nasazení.

Třetí obrazovka si zaslouží vlastní upozornění. Hostinger nabízí „Build with Hostinger Connector“ jako způsob nasazení přímo vedle importu z GitHubu a ručního nahrání souborů. Vybral jsem ji s očekáváním, že dokončí nastavení webu.

Místo toho mě přesměrovala na vlastní instalační stránku Connectoru, kterou jsem už dokončil. To je skutečná mezera v onboarding procesu. Možnost, která měla být cestou nativní pro Connector, ve skutečnosti nic neprovisionovala.

Vrátil jsem se zpět a místo toho zvolil ruční upload souborů. Hostinger přijal můj archiv projektu (11.46 KB, s vyloučeným node_modules ), a obrazovka nastavení ukázala přesnou automatickou detekci:

• Framework preset: Express
• Node version: 22.x
• Root directory: ./

Klikl jsem na Deploy. Proběhlo to úspěšně a Hostinger přidělil skutečnou dočasnou doménu: orange-walrus-700988.hostingersite.com. To je jiná doména, než kterou Connector předtím vymyslel. Ručně jsem otevřel jak homepage, tak /api/health a potvrdil, že obě fungují.

Ruční cesta fungovala bez problémů, jakmile jsem přestal čekat, že cílový web najde Connector. Tlačítko „Build with Hostinger Connector“ na této obrazovce by se mělo opravit nebo odstranit. Teď slibuje něco, co nedělá.

Teď už existoval skutečný, potvrzený web. Další otázka zněla, zda se Connector bude chovat jinak, když má k nalezení něco skutečného.

Nasazení a aktualizace živé aplikace

Jakmile existoval skutečný, potvrzený web, vrátil jsem se do Connectoru a požádal ho, aby zkontroloval přesně tuto doménu. Tentokrát to fungovalo čistě.

To potvrdilo něco důležitého: předchozí selhání se týkala nalezení a vytvoření nového cíle, ne schopnosti Connectoru pracovat se stránkou Node.js, jakmile existuje.

Pak jsem otestoval funkci, kterou Hostinger propaguje nejvíce: provést změnu kódu lokálně a publikovat ji bez otevírání hPanel.

Požádal jsem asistenta, aby změnil jeden řádek textu na domovské stránce, z „Monitor Every Service. Catch Every Issue.“ na „Monitor Every Service. Resolve Issues Faster.“

Celá aktualizace trvala asi jednu minutu. Asistent hned po odeslání hlásil nové nasazení jako „pending“, jednoduše proto, že kontroloval dřív, než Hostinger dokončil zpracování.

Ve chvíli, kdy jsem si obnovil živý web ručně, byl nový nadpis už na místě.

Build logy, které později získal, byly konkrétní a užitečné: 67 balíčků přidáno, 68 auditováno, žádné zranitelnosti, žádné chyby.

Pro zavedené weby je to velmi blízko workflow, které Hostinger slibuje. Upravit, ověřit lokálně, odeslat a potvrdit, to vše bez opuštění editoru, asi za minutu. To je nejsilnější výsledek celého testu.

Dobrý deploy mi říká jen to, že funguje šťastná cesta. Abych zjistil, co Connector skutečně dělá pod tlakem, rozbil jsem aplikaci záměrně.

Test obnovy po selhání

Nástroj si důvěru zaslouží teprve tehdy, když obstojí při skutečné chybě, ne jen v čisté ukázce. Úmyslně jsem aplikaci rozbil, abych zjistil, zda stavové hlášení a logy Connectoru opravdu pomohou diagnostikovat problém.

Před jakoukoli změnou asistent zálohoval package.json na package.json.bak, což je samo o sobě dobrý zvyk.

Pak jsem ho nechal změnit startovací skript z „start\”: \”node server.js“ na „start\”: \”node missing-server.js“, což je soubor, který neexistuje.

Lokální spuštění potvrdilo skutečné, reprodukovatelné selhání: Error: Cannot find module ‘…/missing-server.js’.

Rozbitou verzi jsem záměrně nasadil, abych viděl, co Hostinger nahlásí.

Build logy dostupné přes Connector ukazovaly úspěšnou instalaci závislostí a nic víc. Chybějící runtime chyba modulu se v nich nikdy neobjevila. Vývojář, který by se podíval na zelený badge „completed“, by neměl důvod tušit, že web nefunguje.

Obnova proběhla hladce. Asistent obnovil package.json ze zálohy, ověřil aplikaci lokálně, znovu ji nasadil a potvrdil opravu tím, že zavolal živý endpoint /api/health přímo, místo aby věřil samotnému stavu nasazení.

Ten endpoint vrátil odpověď o provozuschopnosti, což byl v celém testu jediný důkaz, který skutečně prokazoval, že aplikace běží.

To je druhé hlavní zjištění. Dokončený stav neprokazuje fungující aplikaci a vlastní logy Connectoru vám to neřeknou. Samotná obnova fungovala dobře, jakmile jsem věděl, že existuje problém, který je třeba obnovit.

Po selhání, které stavová značka nedokázala odhalit, jsem chtěl vědět, kde jinde by se mohla jistota Connectoru přelévat přes jeho skutečné schopnosti. Další test byly proměnné prostředí.

Pokus o konfiguraci proměnných prostředí

Požádal jsem asistenta, aby přidal neškodnou proměnnou prostředí, nejprve potvrdil, že existuje dedikovaná funkce Connectoru pro danou věc, a zastavil se, pokud neexistuje.

Prohledal dostupné nástroje, nenašel žádnou dedikovanou akci pro správu proměnných prostředí Node.js a zastavil se ještě před jakoukoli změnou kódu nebo nasazení.

To je chování, které jsem chtěl v celém testu vidět. Když narazil na skutečný limit, zastavil se místo toho, aby hádal. Nevyvozoval bych z toho, že Hostinger Connector nemá podporu proměnných prostředí nikde ve své sadě nástrojů, jen to, že žádná taková akce nebyla během tohoto testu zpřístupněna. 

Souhrn testu selhání a obnovy

Co test vypovídá o spolehlivosti

Hostinger Connector zvládl rutinní, deterministické úkoly dobře:

• Čtení známých záznamů nasazení
• Úpravu konkrétního souboru
• Spouštění lokálních příkazů
• Balení projektu
• Nasazení na známý web
• Kontrolu stavu buildu
• Získávání dostupných logů
• Obnovení a znovunasazení známé funkční verze

Byl slabší, když úkol vyžadoval interpretaci nad neúplnými daty účtu:

• Identifikaci nově vytvořeného webu
• Rozlišení mezi dostupností domény a existencí webu
• Určení, zda dokončený build znamenal, že aplikace běží zdravě

Tento vzorec je užitečný při rozhodování, kolik autonomie asistovi dát.

Pro nízkorizikové kontroly použijte širší prompty. Pro akce, které mění živou infrastrukturu, použijte přesné prompty a výslovné požadavky na potvrzení.

Například místo:

použijte:

Druhý prompt omezuje prostor asistenta pro domněnky.

Celkový verdikt na snadnost použití

Zprovoznění Hostinger Connector bylo snadné, bez obvyklého tření při nastavování, a detailní ovládání kategorií nástrojů mi dalo skutečnou možnost rozhodovat o tom, co může AI zasáhnout.

Jakmile existoval skutečný web se známou doménou, zvládl práci dobře: jedna změna textu vedla od úpravy k živému nasazení asi za minutu, s užitečnými build logy jako důkazem.

Problém nastal dříve v procesu, ne později. Když čelil novému cíli, který nedokázal najít, Connector si vymyslel doménu a jednal na jejím základě dřív, než ji ověřil. Také označil rozbité nasazení jako „completed“, i když aplikace ve skutečnosti neběžela, a v jeho vlastních logách se runtime chyba neukázala. Ani jeden problém neznamená, že je nástroj nespolehlivý pro zavedené weby, ale oba znamenají, že nové nasazení a stav po nasazení je potřeba před důvěrou ještě jednou zkontrolovat.

Hostinger Connector Plans with Hostinger

Integrujte Hostinger s aplikacemi a službami, které již používáte, abyste automatizovali úkoly, zlepšili workflow a spravovali svůj web efektivněji.

Navštivte Hostinger

Úroveň podpory

Hostinger staví podporu na živém chatu a samoobsluze, ne na telefonních hovorech, takže jsem testoval tam, kde většina uživatelů skutečně skončí: AI asistenta zabudovaného v hPanel, lidskou eskalaci za ním a znalostní bázi, ke které by se vývojář obrátil dřív, než otevře chat.

Kanály podpory

Vzhledem k tomu, že živý chat je kanál, na který Hostinger směruje vývojáře pro cokoli naléhavého, a ten, který je nejpravděpodobnější používat při ladění nasazení, testoval jsem tuto cestu přímo místo toho, abych poslal e-mailový tiket.

Živý chat: Kodee a předání člověku

Otevřel jsem živý chat přes „Ask AI“ v hPanel a položil Kodee otázku, u které se snadno dá udělat chyba: zda dokončený stav buildu u nasazení Node.js zaručuje, že aplikace skutečně běží, a kde bych našel důkaz o opaku.

První odpověď Kodee byla konkrétní a správná:

„Completed“ obvykle znamená, že fáze buildu proběhla úspěšně; nezaručuje to, že je aplikace po spuštění zdravá. Abyste zachytili špatný startovací příkaz nebo jiný runtime pád, zkontrolujte runtime logy: v hPanel přejděte na Websites → Dashboard → Deployments pro build logy a poté otevřete stderr.log vaší aplikace ve složce nodejs pro chyby při spuštění, jako je Port already in use nebo Module not found.

Ta jediná odpověď by vyřešila přesně tu nejasnost, na kterou jsem narazil v testu obnovy po selhání dříve v této recenzi. Kodee pojmenoval skutečný log soubor, správnou složku a správně oddělil úspěch buildu od zdraví runtime.

Chtěl jsem ale také zjistit, zda se mohu dostat ke skutečnému lidskému operátorovi, takže jsem Kodee řekl, že bych rád tuto věc potvrdil přímo se specialistou podpory.

Jenže dostat člověka na linku bylo těžší, než jsem čekal. Žádal jsem přímo o živého agenta a dvakrát jsem byl přesměrován zpět na Kodee, pokaždé s tím, že je to rychlejší než čekání:

Rozumím, proč byste to chtěl. Mohu vám pomoci ověřit build, startovací příkaz a runtime logy přímo tady, což je obvykle nejrychlejší způsob, jak problém najít.

Než zapojíme specialistu. Mohu problém vyřešit a ušetřit vám čekání.

Trvalo dvě přímé, výslovné žádosti, než Kodee přestal přesměrovávat zpět na sebe. U otázky, kterou jsem si mohl vyřešit sám, je to jen malé zdržení. Pro někoho uprostřed výpadku, kdo chce člověka, je to skutečný zdroj frustrace.

To, co následovalo, nebylo živé předání v tom smyslu, jaký obvykle znamená „připojte mě k člověku“. Kodee vysvětlil skutečný model zcela otevřeně:

Vaši žádost jsem předal specialistovi z našeho týmu, který si náš chat osobně projde a zašle mi svou odpověď, kterou vám zde poté předám.

To je asynchronní kontrola, ne živé předání. Kodee zůstává rozhraním; člověk v pozadí zkontroluje přepis a Kodee pak předá odpověď, až dorazí. Tento rozdíl je důležitý pro čtenáře, kteří se rozhodují, zda eskalovat, protože „lidský agent“ zde neznamená, že se v okně chatu připojí nová osoba tak, jak by to bylo u běžného live chatu.

Pokračoval jsem v tématu, zatímco jsem čekal, a požádal Kodee, aby potvrdil přesnou cestu k logům a zda stderr.log je vždy vyplněn. Dal mi sám o sobě solidní odpověď a správně poznamenal, že log může být prázdný, pokud se aplikace nikdy úplně nespustila nebo zapisovala chybu jinam.

Recenze specialisty dorazila asi za 3 minutes, byla v chatu připsána kolegovi jménem Mayas a odpověď byla přesnější než odpověď Kodee, nikoli jen její opakování:

domains/[your-domain]/nodejs/stderr.log je správné umístění. Není vždy vytvořený nebo vyplněný. Záznamy v něm uvidíte pouze tehdy, když aplikace zapisuje na stderr, například při neodchycených výjimkách nebo neobsloužených odmítnutích. Pokud je startovací příkaz špatný a proces skončí tiše, stderr.log může být prázdný nebo chybět.

Mayas také přidal dvě záložní kontroly, které Kodee nezmínil: kontrolu stdout.log pro poslední výstup před pádem a hledání chybějící potvrzovací řádky spuštění jako známky toho, že se aplikace nikdy nespustila.

Knowledge Base

Knowledge Base Hostinger je uspořádaná do širokých kategorií produktů: 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 a About Hostinger.

Žádná z těchto kategorií není věnována Hostinger Connector. Jediný způsob, jak jsem našel správný článek, bylo hledat přímo „Hostinger Connector“, což vrátilo pět výsledků, z nichž většina s tím souvisela jen volně, včetně průvodce affiliate marketingovým pluginem a obecného článku o hostingu Node.js.

Článek, který Connector skutečně dokumentuje, se jmenuje „How to Set Up Web Hosting MCP on Local IDEs“ a je zařazen pod Features → General Information.

Hledání podle marketingového názvu produktu ho našlo, ale čtenář procházející kategorie nebo hledající „MCP“ bez znalosti branding Hostingeru by ho mohl snadno minout a nesoulad mezi marketingovým a dokumentačním názvem je dobré vědět před tím, než se začnete dívat.

Samotný článek je po nalezení velmi dobrý. Byl aktualizován šest dní před mým testem a pokrývá:

• Doporučené jednoklikové nastavení přes OAuth v rozšíření
• Ruční cestu nastavení pomocí API tokenu pro IDE, která rozšíření přímo nepodporují
• Přesné cesty ke konfiguračním souborům pro Mac, Linux a Windows
• Plné příklady JSON konfigurace
• Postupný ověřovací prompt pro potvrzení, že připojení fungovalo
• Které podporované klienty připojení automaticky detekují a které vyžadují ruční zadání konfigurace

Tento poslední bod odpovídal něčemu, na co jsem narazil přímo při testování: Devin Desktop je detekován automaticky, zatímco OpenAI Codex vyžaduje ruční metodu. Článek tento rozdíl uvádí správně.

Celkový verdikt na podporu

První odpověď Kodee na obtížnou technickou otázku byla přesná a konkrétní, což není něco, co každému AI podpůrnému asistentovi vychází. Článek v knowledge base, který ji podporuje, je aktuální a podrobný, jakmile ho najdete, i když marketingový název produktu a název dokumentace se neshodují, takže vyhledávání je spolehlivější než procházení kategorií.

Slabším místem je cesta lidské eskalace. Kodee mě dvakrát přesměroval zpět na sebe, než respektoval přímý požadavek na člověka, a i pak „lidský agent“ znamená asynchronní kontrolu předanou přes stejný chat, ne živý přenos. Jakmile se na to člověk podíval, odpověď byla lepší než Kodeeho vlastní, přesnější a se dvěma dalšími diagnostickými kroky, které Kodee nenabídl.

Na většinu otázek vám Kodee sám dá rychlou a přesnou odpověď. Pokud ale skutečně chcete, aby člověk odpověď ověřil, počítejte s tím, že se budete muset zeptat více než jednou, a s krátkým čekáním na odpověď předanou zpět přes chat, nikoli na živou konverzaci.

Hostinger Connector Plans with Hostinger

Integrujte Hostinger s aplikacemi a službami, které již používáte, abyste automatizovali úkoly, zlepšili workflow a spravovali svůj web efektivněji.

Navštivte Hostinger

Konečný verdikt: Vyplatí se Hostinger Connector používat?

Ano, pro vývojáře, kteří už hostují u Hostinger a chtějí běžná nasazení řešit přímo z editoru. Nastavení trvalo minuty, OAuth odstranil potřebu API klíčů a jakmile existoval web se známou doménou, Connector doručil živou aktualizaci asi za minutu s logy jako důkazem. Odpovědi Kodeeho podpory byly dostatečně přesné, aby vyřešily skutečný technický problém hned napoprvé.

Háček je důvěra, ne pohodlí. Když dostal nový cíl, který nedokázal najít, Connector si vymyslel doménu a jednal na jejím základě, než ji ověřil.

Také označil rozbité nasazení jako „completed“, zatímco aplikace ve skutečnosti nefungovala, a v jeho vlastních logách se runtime chyba neobjevila. Používejte ho k urychlení práce na webech, které už existují, ověřujte cokoli, co dělá na zcela novém cíli, a po každém nasazení, na kterém záleží, si živý web zkontrolujte sami.

Hostinger

5.0

2,470 user reviews

40 Kč /mo

Počáteční cena

Navštivte Hostinger

Rating based on expert review

• Uživatelská přívětivost
  4.9
• Podpora
  4.9
• Vlastnosti
  4.8
• Spolehlivost
  4.7
• Cena
  4.5