Hostinger vytvořil Web Apps Hosting kolem jednoduché myšlenky: nahrajte svůj kód z GitHubu, ZIP souboru nebo svého AI kódovacího agenta a během zhruba minuty získáte živou produkční aplikaci bez serveru, o který byste se museli starat. Chtěl jsem zjistit, kolik z toho opravdu platí, když jste to vy, kdo kliká na nasazení, takže tady je, co jsem zjistil.

Nasazujte webové aplikace rychleji s Hostingerem

Nasazujte moderní webové aplikace na Hostingeru s automatizovanými sestaveními, spravovanou infrastrukturou, globálním CDN, SSL, bezpečnostními nástroji a 30denní zárukou vrácení peněz.

Navštivte Hostinger

Klady a zápory

Rozpis hodnocení

Pro hodnocení Hostinger Web Apps Hosting jsem použil metodiku hodnocení HostAdvice rating methodology, stejný standardizovaný postup, který se používá u každé recenze na webu, takže výsledky zůstávají ukotvené v reálném testování, ne v marketingových frázích. Tady je, jak si vedl v jednotlivých parametrech.

Hostujte své webové aplikace bez starostí s DevOps

Nasazujte moderní webové aplikace na plně spravovaném hostingu s automatizovanými nasazeními, spravovaným SSL, globálním CDN a vestavěným zabezpečením.

Navštivte Hostinger

Plány a ceny

Hostinger prodává Web Apps Hosting ve dvou úrovních, Business a Cloud Startup, přičemž obě jsou postavené konkrétně pro nasazování Node.js a moderních JavaScript aplikací, nikoli pro tradiční tvorbu webů.

Cloud Startup, tedy úroveň, kterou jsem testoval, má dvojnásobný počet aplikací a CPU jader oproti Business a oba plány zahrnují zdarma doménu, firemní e-mail a spravované SSL na první rok přímo v rámci objednávky.

Několik věcí, které byste měli vědět před objednáním:

• Záruka vrácení peněz: Web Apps Hosting spadá pod standardní storno podmínky Hostingeru, tedy do jednoduchého 30denního okna od data nákupu. To je výrazně jednodušší než u VPS plánů Hostingeru, které mají navíc 180denní cooldown mezi žádostmi o refundaci. Na tento produkt se žádný takový cooldown nevztahuje.
• Zkušební verze zdarma: Žádnou vyhrazenou bezplatnou zkušební verzi jsem nenašel. Vaším hodnoticím obdobím je místo toho 30denní záruka vrácení peněz.
• Platební metody: Pokladna jako výchozí způsob platby nabízela kartu a zobrazovala loga Visa, Mastercard, Amex a Discover, plus možnost přidat jinou platební metodu během objednávky.
• Co je v balíčku: Zdarma doména na jeden rok, zdarma poštovní schránky na jeden rok a spravované SSL jsou všechny zahrnuty bez dalších nákladů nad rámec ceny plánu, takže výsledná cena je velmi blízko skutečným nákladům na zprovoznění kompletně funkční a zabezpečené aplikace.
• Jediný doplněk: Hostinger Reach, doplněk pro e-mail marketing, se v košíku zobrazuje jako samostatný zvýrazněný box s vlastní měsíční cenou. Dá se snadno přeskočit a není ve výchozím stavu ani zahrnut, ani předvybrán.

Pokud Web Apps Hosting zrušíte do 30 dnů, refundční politika Hostingeru potvrzuje, že spadá pod standardní podmínky, nikoli pod seznam výjimek, takže běžné zrušení v tomto období by mělo nárok na vrácení peněz bez dodatečných podmínek, které se vztahují na VPS nebo doménové nákupy.

Funkce

• Automatická detekce frameworku a verze Node
• Nástroje pro vytvoření spravované databáze MySQL
• Globální CDN aktivní ve výchozím stavu
• Součástí je WAF a ochrana proti DDoS
• Denní i on-demand zálohy
• Skener malwaru a kontrola zranitelností
• Integrace s GitHubem a automatické nasazování
• Zdarma doména, e-mail a SSL
• SSH přístup pro pokročilé uživatele

Od kódu k živé aplikaci s Hostingerem

Připojte svůj GitHub repozitář nebo nahrajte svůj projekt a dostaňte ho online se spravovanou infrastrukturou, automatickými nasazeními a denními zálohami.

Navštivte Hostinger

Výkon

Protože Web Apps Hosting je plně spravovaný, nikdy nedostanete shell přístup k serveru, takže CPU, RAM ani disk nemůžete benchmarkovat přímo tak, jak by to šlo u recenze VPS.

Můžete ale měřit, jak rychle se nasazená aplikace načítá a reaguje z reálných míst po celém světě. Testoval jsem to ze čtyř různých úhlů: GTmetrix ze dvou kontinentů, globální konzistenci přes více než 50 bodů a vlastní vestavěný speed test Hostingeru pro desktop i mobil.

Testovaná aplikace je nasazení Next.js popsané v sekci Snadnost použití níže, běžící na plánu Cloud Startup (4 CPU jádra, 4096 MB RAM, 100 GB NVMe úložiště), s CDN aktivní ve výchozím stavu.

1. GTmetrix testovaný ze dvou kontinentů

Spustil jsem GTmetrix dvakrát z různých částí světa, abych zjistil, zda výsledek platí konzistentně, nebo vypadal dobře jen z jednoho šťastného pohledu.

Oba běhy dosáhly dokonalých 100 % jak v Performance, tak ve Structure, s nulovým layout shift a nulovým blocking time v obou lokalitách, což znamená, že se při načítání nic nehádalo o pozornost prohlížeče ani neposkakovalo po obrazovce.

Opravdu zajímavý detail je, že Frankfurt ve skutečnosti porazil Chicago ve všech časových metrikách, i když jsem záměrně zvolil umístění serveru v USA. To dává smysl jen ve spojení s CDN.

Jakmile je CDN aktivní, což zde byla ve výchozím stavu, nemusí se návštěvník připojovat přímo na origin server.

Připojuje se na nejbližší cache edge node, takže evropský testovací bod může být rychlejší než americký, i když skutečný server leží v USA. Je to reálné, praktické potvrzení, že CDN Hostingeru, která je zapnutá ve výchozím stavu, skutečně něco dělá, a není to jen marketingová položka.

2. Globální konzistence (Check-Host)

Spustil jsem HTTP kontrolu na živé URL ze všech checkpointů, které Check-Host nabízí, tedy z 54 míst na šesti kontinentech. Celkový obraz:

Každá úspěšná kontrola vrátila čisté 200 OK, žádné chyby, žádné částečné selhání, žádné neočekávané přesměrování.

Doby odezvy ukázaly jasný obrázek toho, jak CDN caching funguje v reálné vzdálenosti:

Evropské checkpointy vracely konzistentně nejrychlejší časy, několik z nich pod 50 milisekund, zatímco checkpointy fyzicky nejdále od jakéhokoli edge nodu, Tokio, Singapur, Ho Či Minovo Město, stále vracely platné odpovědi 200, jen pomaleji, v rozmezí 0.3 až 0.8 sekundy.

To je očekávaný obraz CDN-backed nasazení: rychlé u okrajových bodů, stále plně funkční i daleko od nich.

Čtyři timeouty, Kazachstán, Rumunsko a dva ze čtyř ruských checkpointů, bych nečetl jako problém infrastruktury Hostingeru.

Další checkpointy ve stejných zemích uspěly (Sankt Petěrburg se vrátil čistě s 0.063s, zatímco dva moskevské checkpointy timeoutovaly), což spíš ukazuje na regionální filtrování sítě na straně checkpointu než na cokoliv špatného s nasazenou aplikací.

3. Vlastní speed test Hostingeru, desktop i mobil

Hostinger má vlastní Page Speed test přímo v dashboardu aplikace, takže jsem jeho čísla porovnal s nezávislým výsledkem GTmetrix, místo abych věřil jednomu nebo druhému samostatně.

Oba typy zařízení získaly perfektních 100 a desktopová čísla se blízce shodují s tím, co nezávisle naměřilo GTmetrix, což je ten hlavní důvod, proč má smysl používat oba nástroje. Dva různé nástroje, dvě různé metodiky a shodují se.

Mobil vyšel pomaleji ve všech časových metrikách, jak se dalo čekat na simulovaném pomalejším připojení a slabším procesoru, ale stále dost rychle na to, že skóre 100 odráží opravdu silný reálný mobilní výkon, ne jen velkorysou stupnici hodnocení.

Jedna nesrovnalost přímo v nástroji. I když je skóre na obou zařízeních čistých 100, panel Diagnostics níže stále označuje několik položek s doslova 0 body, network dependency tree, document request latency a avoiding multiple redirects, spolu se dvěma položkami se skóre 50, unused JavaScript a legacy JavaScript.

Žádné z těchto nízkých dílčích skóre nesrazilo hlavní číslo, takže je berte jako drobné, skutečně přítomné příležitosti k optimalizaci, ne jako něco špatného s nasazením.

Navíc „helpful links“, které Hostinger zobrazuje vedle těchto diagnostik, jsou všechny napsané pro WordPress, „Speed up WordPress in 9 easy steps“, „How to optimize images for your WordPress site“, přestože jde o Node.js aplikaci bez jediného WordPressu v celém stacku. To je pozůstatek ze sdílené šablony diagnostiky, ne obsah vytvořený pro tento produkt.

Celkové hodnocení výkonu

Spravovaný webapp hosting od Hostingeru

Soustřeďte se na tvorbu své aplikace, zatímco Hostinger se postará o nasazení, infrastrukturu, zabezpečení, SSL, zálohy a globální doručování.

Navštivte Hostinger

Snadnost použití

Testoval jsem Hostinger Web Apps Hosting od vstupní stránky přes objednávku až po chladný účet a plně živé, funkční nasazení Node.js aplikace.

To zahrnovalo výběr plánu, platbu, volbu způsobu sestavení, připojení GitHubu a sledování dokončení sestavení v reálném čase. Tady je, jak celý proces ve skutečnosti vypadal.

1. Registrace

Začal jsem na landing page Web Apps Hosting, která má jedno hlavní CTA: Start deploying.

Kliknutí na něj neotevře registrační formulář. Přejde to rovnou dolů do sekce s cenami, takže první skutečné rozhodnutí je, který plán koupit, ne jaké údaje vyplnit pro účet.

Vedle sebe byly dva plány:

Vybral jsem Cloud Startup kvůli dvojnásobné kapacitě aplikací a větší rezervě CPU oproti základní úrovni. Jedna malá nesrovnalost, na kterou je třeba upozornit: stránka s cenami ji nazývá „Cloud Startup“, ale jakmile se dostane do košíku, stejný plán je označen jako „Startup plan“. Není to funkční problém, jen nesoulad v názvu mezi dvěma obrazovkami ve stejném procesu objednávky.

Košík byl přehledný. Uváděl 48měsíční období, úsporu, zdarma doménu na rok a poštovní schránky zdarma, a pak nabídl jeden upsell, Hostinger Reach email marketing, umístěný ve vlastním zvýrazněném boxu místo toho, aby byl předvybraný.

Přeskočil jsem ho a klikl na Continue bez jakýchkoli překážek.

Pokud jste nový zákazník, objednávka zde vloží krok vytvoření účtu ještě předtím, než se dostanete na stránku s fakturační adresou a platbou.

Poté přidáte fakturační adresu, zvolíte způsob platby, kartu, PayPal nebo některou z dalších možností, a odešlete. Potvrzení nákupu jsem dostal e-mailem během několika okamžiků po kliknutí na Submit payment a pak jsem se dostal přímo do hPanelu, kde byl plán už zprovozněn.

Co jsem si myslel: Objednávka je krátká a upsell se dá snadno odmítnout bez hledání skrytého odkazu pro přeskočení. Nesoulad v názvu plánu mezi stránkou s cenami a košíkem je drobnost, ale právě takové detaily způsobí, že si první kupující raději znovu zkontroluje, zda vybral správnou úroveň.

2. Dashboard

Jakmile platba projde, ocitnete se v hPanelu, vlastním interním ovládacím panelu Hostingeru, který byl postaven pro správu všech produktů, které prodává, ne jako stránka specificky navržená pro vaši novou Web App.

Stránka, na které se ocitnete jako první, je Home, a je postavená kolem AI prompt baru nahoře: „Hi, [your name]! How can I help you today?“ s textovým polem pod ním a šesti zkratkami: Get domain, Create website, Get email, Migrate site, Get VPS a Try email marketing.

Po posunutí níže najdete:

• Propagační dlaždice funkcí pro AI Builder, online store tool, claimující zdarma firemní e-mail, AI agents, automation app a claimující zdarma doménu
• To-do checklist navádějící vás k úkolům nastavení, dokončení Reach setup, claimnutí zdarma e-mailu, claimnutí zdarma domény
• Your business, běžící seznam všech webů, aplikací a VPS instancí spojených s vaším účtem, každá s vlastním tlačítkem Manage site
• VPS, samostatná tabulka níže, která uvádí případné VPS instance podle IP adresy, stavu a data expirace

Panel Agent je také trvale umístěn v pravém horním rohu každé stránky hPanelu, nejen na Home. Je to stejný asistent Kodee používaný pro podporu, ale zde je umístěn jako obecný nástroj pro akce s předpřipravenými dotazy jako „Deploy my Node.js app“ nebo „Harden VPS updates“, které můžete spustit bez psaní celé otázky.

Home je skutečně užitečný, jakmile vaše aplikace už existuje, všechno v sekci Your business odkazuje přímo na ni. Ale není to místo, kde byste vytvořili novou Web App nebo našli tlačítko Setup. K tomu potřebujete jinou cestu přes postranní menu:

1. Klikněte na Websites v levém postranním panelu
2. Pod tím se rozbalí submenu: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Klikněte na Web Apps

Toto kliknutí vás přenese na úplně jinou obrazovku než Home, na obrazovku uspořádanou kolem vašich skutečných hostingových plánů, ne kolem prompt baru.

Každý plán, který vlastníte, zde dostane vlastní kartu. Na mém účtu to znamenalo tři karty svisle pod sebou:

Karta Business už také měla pod sebou uvedenou živou aplikaci z předchozího testování, orange-walrus-700988.hostingersite.com, s vlastními tlačítky Tools a Dashboard.

To je samo o sobě užitečné si všimnout. Jakmile Web App existuje, její karta dostane řádek jako tento, který přímo zobrazuje živý web, přesně tak, jak bude vypadat vaše karta Cloud Startup, jakmile dokončíte nastavení.

Protože Cloud Startup byl plán, který jsem právě koupil a ještě nenastavil, jeho karta ukazovala místo toho jediné tlačítko Setup. To je tlačítko, které skutečně spustí průvodce vytvořením Web App, a objeví se jen tady, pod Websites → Web Apps, ne na domovské obrazovce Home, na kterou se dostanete jako první.

Co jsem si myslel: hPanel je přehledný, jakmile najdete správnou obrazovku, ale Web Apps Hosting nemá žádný zřejmý vstupní bod. Přistání na Home vám ukáže prompt bar a zkratky, ne cestu k vytvoření aplikace, musíte vědět, že máte kliknout na Websites a pak na Web Apps, teprve potom se vůbec objeví Setup. To je pár kliknutí navíc pro produkt, který je prodáván jako „live in a minute“. Jakmile jste ale uvnitř, karty plánů jsou čisté a poctivě ukazují stav, a plán s již běžící aplikací ji přímo zobrazuje na kartě.

3. Nasazení aplikace

Kliknutí na Setup na kartě plánu otevřelo krátký onboarding flow: Where would you like to start? s třemi možnostmi, Create a new site, Migrate an existing site nebo I hired someone to build my site. Zvolil jsem Create a new site.

To vedlo na How do you want to build your website?, rozdělené na dvě začátečnické možnosti nahoře, Hostinger AI Builder a WordPress + AI, a dvě možnosti pod samostatným nadpisem „for advanced users“ níže: Node.js web app a PHP/HTML website. Výběr Node.js web app je to, co vás skutečně dostane k produktu Web Apps Hosting.

Tohle je důležitá strukturální poznámka pro každého, kdo porovnává produkty: Web Apps Hosting nemá vlastní samostatný signup flow.

Je to jen jedna větev ve stejném obecném průvodci tvorby webu, který Hostinger používá pro AI Builder i WordPress.

Klikl jsem na kolečko vedle Node.js web app a pak na Next.

Odtud:

• Obrazovka domény: Zvolil jsem Use temporary domain místo závazku k reálné doméně, protože šlo o testovací nasazení.

• Obrazovka umístění serveru: Hostinger předem vybral Francii, nejbližší region k mé fakturační zemi, a ukázal 167ms latenci. Po scrollování dolů na možnost Spojených států bylo vidět 364ms, tedy více než dvojnásobek.

Přesto jsem zvolil United States, Massachusetts, a to je přesně ta lekce, kterou vám výběr lokace u Hostingeru u každého produktu dá: vybírejte podle toho, kde jsou vaši skuteční návštěvníci, ne podle nejnižšího čísla v seznamu.

Má cílová skupina testovací aplikace je v USA, takže server v USA ji bude skutečně obsluhovat rychleji, než by ji kdy obsloužil server ve Francii, bez ohledu na to, co mi ukázal výběr z mé vlastní lokace. Číslo na obrazovce říká, jak rychle server reaguje na Hostingerův test, ne jak rychle zareaguje na lidi, kteří váš web budou skutečně používat.

• Obrazovka způsobu nasazení: dvě hlavní možnosti, Import Git repository (označené jako Recommended) nebo Upload your files, plus výzva níže pro nasazení přímo z Claude Code, Cursor nebo VS Code přes Hostinger Connector. Vybral jsem Import Git repository a klikl na Connect with GitHub.

To otevřelo skutečné přihlašovací okno GitHubu, pokud jste už nebyli přihlášeni, a pak obrazovku oprávnění s názvem Install & Authorize Hostinger, která vám nabídla volbu mezi:

• Instalací na all repositories všechna úložiště, která vlastníte, včetně budoucích, s přístupem jen pro čtení k veřejným repozitářům
• Instalací pouze na only select repositories která si vyberete jednotlivě a s přesným výčtem oprávnění, která udělujete: přístup pro čtení k actions, metadata a repository hooks a přístup pro čtení i zápis k administration, code a pull requests. Jakmile kliknete na Install & Authorize, GitHub vás automaticky přesměruje zpět do hPanelu.

Dostanete se na Select Git repository to import, posuvný seznam všech repozitářů spojených s vaším účtem GitHub, každý s vlastním tlačítkem Deploy vedle něj. Našel jsem testovací repozitář, který jsem předtím nahrál, hostadvice-webapps-test, a klikl na Deploy vedle něj.

Od kliknutí na toto tlačítko trvalo skoro 30 sekund bez jakéhokoli ukazatele průběhu na obrazovce, než se načetla další stránka, což je dost dlouho na to, aby vás napadlo, zda kliknutí vůbec proběhlo.

Stránka, která se nakonec načte, se jmenuje Review build settings a přesně vám řekne, kde vaše aplikace poběží, ještě než cokoli potvrdíte: „Deploys to ivory-llama-856835.hostingersite.com.“ Níže, bez jakéhokoli zásahu z vaší strany, už automaticky rozpoznala:

Každý z těchto pěti řádků má vedle sebe vlastní tlačítko Change nebo Add, takže nic není zablokované, pokud detekce něco určí špatně.

Klikl jsem na Add vedle Environment variables a nastavil jednu klíč-hodnotu dvojici, abych potvrdil, že se skutečně dostane do běžící aplikace, pak jsem v dialogu klikl na Finish a potom na hlavní tlačítko Deploy dole na stránce.

Sledování sestavení

Obrazovka se přepne na zobrazení Deploying… s označeným progress barem, „Deployment from GitHub“, který postupně roste v reálných fázích, sledoval jsem ho, jak se posouvá na 28 %, pak 51 %, směrem k dokončení. Pod progress barem je rozbalovací panel Build logs, a po jeho otevření se zobrazí skutečný živý terminálový výstup, ne žádný placeholder 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 …

Nasazení dokončeno

Jakmile se build dokončí, dostanete se na obrazovku Deployment completed! s živým náhledem vaší skutečně běžící aplikace vykresleným přímo v kartě, vedle souhrnu zobrazujícího název repozitáře a přiřazenou živou URL.

Odtud můžete kliknout přímo na Go to dashboard, což je místo, kde aplikaci spravujete dál.

Co jsem si myslel: Automatické rozpoznání je zde největším tahákem. Framework, branch i verze Node se rozpoznaly správně bez jediného ručního pole a živý build log dělá čekání průhledným místo neprůhledného. Jediným slabším místem je 30sekundová pauza ještě předtím, než se vůbec dostanete na obrazovku s nastavením, dost dlouhá na to, že si můžete myslet, že se proces zasekl, než se nápadně rozběhne.

4. Potvrzení živého nasazení

Než jsem se pustil do správy, chtěl jsem potvrdit, že aplikace byla skutečně nasazena a funguje, ne jen označena na obrazovce jako „Completed“.

Z obrazovky Deployment completed jsem klikl rovnou na živou URL, ivory-llama-856835.hostingersite.com, místo abych se spoléhal jen na náhledovou miniaturu v dashboardu.

Živá stránka se načetla a ukázala přesně to, co měla podle kódu zobrazovat:

• Server build time, živý časový údaj potvrzující, že stránka byla právě sestavena, ne servírována ze staré cache
• Kontrola proměnné prostředí, ukazující vlastní proměnnou, kterou jsem nastavil během nasazování, a která se na skutečném živém webu potvrdila správně, ne jen v náhledu v dashboardu

Pak jsem klikl na vlastní tlačítko aplikace Ping the API route, které volá živý backend endpoint, ne jen vykresluje statický obsah. Vrátilo čistou JSON odpověď:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Ta odpověď je důležitější, než se možná zdá. Samotné správné načtení stránky jen dokazuje, že statické soubory byly nahrány.

Funkční API volání dokazuje, že skutečný Node.js server běží pod tím vším a odpovídá na reálné požadavky, tedy ta část „Node.js web app“ hostingu, kterou lze snadno napodobit statickým souborem a těžko napodobit živým serverovým časem generovaným přesně ve chvíli, kdy kliknete na tlačítko.

Co jsem si myslel: To je kontrola, kterou bych vám doporučil před důvěrou v jakékoli nasazení na této platformě, nebo na jakékoli podobné. Zelený stav „Completed“ a náhledová miniatura vám říkají, že sestavení skončilo. Kliknutí na živou URL a spuštění něčeho dynamického, volání API, čtení z databáze, cokoli, co nelze předstírat pomocí uložené statické stránky, vám říká, že server je skutečně naživu a dělá to, co jste pro něj postavili.

5. Správa webové aplikace

Jakmile jsem potvrdil, že živá aplikace funguje, vrátil jsem se do hPanelu a prošel jsem dashboard aplikace odshora dolů, tedy skutečnou serverovou vrstvu správy tohoto produktu, oddělenou od obecné domovské obrazovky hPanelu popsané výše.

Přehled dashboardu. V okamžiku, kdy sem vstoupíte, vám čtyři stavové štítky ukážou stav věcí na první pohled:

Všechny čtyři byly ve výchozím nastavení zelené, bez nutnosti cokoli ručně přepínat. Pod tím je karta Last deployment, která potvrzuje stav, repozitář, autora, commit, čas nasazení, rozpoznaný stack a verzi Node, tedy vše, co chcete mít přehledně po ruce bez hledání v logách.

Automatický test Page Speed už byl sám od sebe spuštěn na živém webu a vrátil 99/100 pro Desktop, aniž bych ho sám spouštěl, a vedle toho je panel Essentials s rychlými odkazy na připojení databáze, zálohy, správce souborů, runtime logy a cache.

Nasazení, proměnné prostředí a logy. Tři samostatné stránky pokrývají tuto oblast:

• Deployments uchovávají úplný záznam o pushi, autorovi, branchi, hashi commitu a stavu dokončení, tedy skutečnou historii, ne jen poslední nasazení
• Environment variables správně uvádějí proměnnou, kterou jsem nastavil při nasazení, což potvrzuje, že byla uložena a aplikována, ne jen jednou zobrazena při nastavení a zapomenuta
• Runtime logs v reálném čase streamují výstup serveru, startovací řádky Next.js, ready timestamps a běžící počty problémů a chyb, které po celou dobu, co jsem je sledoval, zůstaly na nule a nule

Zabezpečení. Malware Scanner vrátil čistý výsledek, „Your website is safe“, s jednou výhradou jasně uvedenou místo toho, aby byla schovaná v drobném písmu: kontroluje pouze soubory webu, ne obsah databáze, a existuje placená možnost čištění, pokud chcete hlubší kontrolu včetně databáze. Kontrola Vulnerabilities také dopadla čistě.

Databáze. Tady je místo, kde vlastní marketing produktu vytváří skutečnou mezeru, kterou byste měli před nákupem chápat. Plán inzeruje spravované MySQL jako hlavní funkci, ale nic se vám samo automaticky nevytvoří.

Sekce Databases se otevírá ručním formulářem Create a New MySQL Database And Database User, což znamená, že databázi pojmenujete a vytvoříte sami, než ji vaše aplikace může používat. To jsem si ověřil přímo s Kodeem, což je popsáno níže v sekci Podpora, a odpověď byla přímá: spravované znamená, že Hostinger provozuje databázovou infrastrukturu na pozadí, ne že se vám databáze vytvoří ve chvíli, kdy jde aplikace poprvé online.

Pokročilý přístup. SSH přístup je v sekci Advanced k dispozici, včetně IP, portu a uživatelského jména, ale je ve výchozím stavu Inactive a musíte ho ručně zapnout kliknutím na Enable, než ho můžete použít. File Manager nabízí možnost procházet jen soubory této aplikace, nebo všechny soubory v celém hostingovém plánu.

Co jsem si myslel: Každodenní dashboard je důkladný a dobře uspořádaný. Zejména bezpečnost a historie nasazení jsou snadno k nalezení a skutečně informativní a runtime log bez chyb spolu s čistým malware scanem mi daly reálnou jistotu, že aplikace je zdravá, ne jen online.

Jediné místo, kde rozhraní trochu přehání, je sekce databáze, kde „managed MySQL“ na stránce plánu zní jako něco, co na vás čeká hned po zprovoznění aplikace, ale ve skutečnosti dostanete ruční formulář pro vytvoření, jednoduchý na použití, ale stále to musíte udělat sami.

Celkové hodnocení snadnosti použití

Vybudujte, nasazujte a škálujte s Hostingerem

Hostujte moderní webové aplikace s integrací GitHubu, spravovaným MySQL, globálním CDN, neomezeným provozem a vestavěnými bezpečnostními nástroji.

Navštivte Hostinger

Úroveň podpory

Testoval jsem podporu Hostingeru pro Web Apps Hosting přes Kodee, AI asistenta zabudovaného v hPanelu, a pak jsem prošel znalostní bázi, abych zjistil, jak velký rozsah pokrývá bez toho, aby bylo nutné se ptát někoho dalšího. Kodee se objevuje na dvou místech, která je dobré rozlišovat: jako Ask AI na veřejném marketingovém webu a jako panel Agent dostupný z libovolné stránky přímo v hPanelu, včetně dashboardu vlastní Web App.

1. AI podpora (Kodee)

Položil jsem dvě otázky postavené na skutečných mezerách, které jsem během testování našel, ne na obecných dotazech, na které by Kodee mohl odpovědět zkopírováním dokumentace.

Otázka 1 testovala chování při selhání nasazení a načasování proměnných prostředí, tedy skutečné provozní starosti každého, kdo na tuto platformu nasazuje:

Pokud se sestavení mé aplikace v polovině GitHub nasazení pokazí, vrátí se aplikace automaticky na poslední verzi, nebo bude mimo provoz, dokud chybu neopravím a nenasadím znovu? A mohu nastavit vlastní proměnné prostředí ještě před prvním nasazením, nebo až po něm?

Kodee odpověděl přímo a správně v obou bodech. Neúspěšné sestavení nenahradí aktuálně běžící aplikaci, pokud předchozí nasazení bylo úspěšné, aplikace dál obsluhuje poslední funkční verzi. Pokud jde o první nasazení a není odkud se vrátit, aplikace zůstane mimo provoz, dokud není build opraven a znovu nasazen, což je jasná a poctivá odpověď, ne vágní uklidnění.

U proměnných prostředí potvrdil, že je lze nastavit ještě před prvním nasazením v nastavení deploymentu, a u již běžící aplikace popsal přesně tři kroky: otevřít Settings a Redeploy, přidat nebo upravit proměnné v Environment variables, uložit a znovu nasadit.

Otázka 2 se zaměřila na dvě mezery, které jsem sám našel v dashboardu, na formulaci „managed MySQL“ oproti ručnímu formuláři pro vytvoření a na SSH, které je ve výchozím stavu neaktivní:

Tento plán inzeruje managed MySQL, ale dashboard ukazuje ruční formulář „Create a New MySQL Database“ místo databáze, která by byla vytvořena automaticky. Je databáze vytvořena pro každou Web App ve výchozím stavu, nebo jen když si ji vytvořím sám? A také SSH přístup je uveden jako dostupný, ale ve výchozím stavu zobrazuje stav Inactive. Pokud ho nikdy nezapnu, změní to něco na tom, jak moje aplikace běží, nebo je SSH čistě volitelný doplněk pro pokročilé uživatele?

Odpověď Kodee přesně potvrdila to, co jsem našel v rozhraní, a ne nějakou mírnější verzi. Databáze se pro každou Web App nevytváří automaticky, „managed“ označuje to, že Hostinger provozuje databázovou službu a infrastrukturu, zatímco vytvoření a konfigurace skutečné databáze je na vás, přes stejnou obrazovku Create a New MySQL Database, a následné přidání připojovacích údajů do proměnných prostředí aplikace.

U SSH potvrdil, že ponechání ve stavu inactive nic nemění na běhu aplikace, nasazování ani připojení k databázi. Je prezentováno čistě jako volitelný nástroj pro CLI příkazy, migrace nebo přímé ladění souborů, nikoli jako něco, na čem platforma tiše závisí na pozadí.

Co jsem si myslel: Obě odpovědi přesně odpovídaly tomu, co jsem už ověřil ručně v dashboardu, místo aby tomu odporovaly nebo to zjemňovaly, a to je známka podpůrného nástroje, který skutečně kontroluje stav reálného produktu, místo aby recitoval skript. Ani jedna otázka nešla zodpovědět prostým zkopírováním obecného FAQ, a Kodee si s oběma poradil specificky a strukturovaně ve dvoudílných odpovědích zhruba do minuty.

2. Znalostní báze

Znalostní báze Hostingeru se otevírá jako mřížka kategorií, celkem 20 kategorií, každá se zobrazeným počtem článků. Některé z největších: AI Builder má 330 článků, VPS 276, Email 127 a Website 103.

Web Apps Hosting nemá vlastní samostatnou kategorii. Jeho obsah je rozptýlen napříč Getting Started, hPanel a Website, což je skutečný poznatek pro každého, kdo očekává jedno vyhrazené centrum podobně jako u VPS nebo Email.

Vyhledání „Web Apps“ přímo vrátilo 71 výsledků na 8 stránkách. Nejlepší výsledky byly směs přímo relevantních a jen volně souvisejících článků:

• How to deploy apps built with Codex on Hostinger, přímo relevantní
• Hostinger AI Builder: How to create a web app in agentic mode, blízký, ale jiný produkt
• How to add a Node.js Web App in Hostinger, přímo relevantní
• How to install Flutter Web on a VPS at Hostinger, úplně jiný produkt
• Několik článků o platbách pro Website Builder (PayPal, WeChat Pay, BLIK), nesouvisejících kromě toho, že někde v textu obsahují slova „web“ a „app“

Otevřel jsem jeden z nejlepších výsledků, How to deploy apps built with Codex on Hostinger, abych zkontroloval jeho hloubku. Ukázal se jako důkladný, dobře strukturovaný návod, s podporovanými frameworky uvedenými hned nahoře, krok za krokem se screenshoty pro GitHub import i ZIP upload, sekcí o konfiguraci build settings s ukázkovými příkazy, rozborem struktury souborů po nasazení, průvodcem připojením databáze, sekcí o monitorování zranitelností a závěrečným blokem FAQ.

Přestože je zaměřen konkrétně na Codex, základní platforma je stejná jako u obecného produktu Node.js Web App, takže většina obsahu platí přímo.

Co jsem si myslel: Počet článků ve vyhledávání vypadá na papíře silně, 71 výsledků pro jeden výraz, ale významná část toho objemu je šum z nesouvisejících produktů, které sdílejí podobné znění. Jeden článek, který jsem otevřel celý, kvalitou obstál, když jsem se do něj dostal, jasné kroky, skutečné screenshoty a opravdová sekce FAQ, ale najít ho znamenalo projít výsledky, které neměly s tím, co jsem vlastně chtěl nasadit, nic společného.

Celkové hodnocení zákaznické podpory

Jednoduchý hosting pro moderní webové aplikace

Nasazujte React, Next.js, Vue, Node.js a další moderní aplikace bez správy serverů nebo složité infrastruktury.

Navštivte Hostinger

Doporučujeme Hostinger Web Apps Hosting?

Ano. Proces nasazení je nejsilnější částí tohoto produktu: správné automatické rozpoznání mého stacku, branch a verze Node, skutečný streamovaný build log místo spinneru a živá aplikace, která prošla všemi testy výkonu, jež jsem jí hodil, perfektní skóre GTmetrix ze dvou různých kontinentů, čistá 54bodová globální kontrola konzistence a shodné skóre 100/100 z vlastních nástrojů Hostingeru na desktopu i mobilu. Kodee to podpořil přesnými, konkrétními odpověďmi na skutečné technické otázky místo obecných skriptových reakcí.

Drobná slabá místa stojí za znalost před nákupem. „Managed MySQL“ na stránce plánu zní, jako by bylo vše připravené ve chvíli, kdy vaše aplikace půjde online, ale ve skutečnosti znamená ruční formulář pro vytvoření databáze. Dashboard také nedává Web Apps Hosting žádný vlastní vstupní bod z hlavní obrazovky Home, musíte vědět, že nejdřív kliknete na Websites.

Pro vývojáře, který chce rychlé nasazení bez ohledu na framework a infrastrukturu, které tyto benchmarky vycházejí tak dobře, je to snadné doporučení. Pro někoho, kdo očekává, že každá inzerovaná funkce bude zapnutá okamžitě po dokončení objednávky, si vyhraďte pár minut navíc na ruční nastavení databáze.

Hostinger

5.0

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