A Hostinger által épített Web Apps Hosting egyszerű ígéretre épül: küldd fel a kódodat GitHubról, egy ZIP-fájlból vagy az AI kódoló ügynöködtől, és kapj egy élő, éles alkalmazást nagyjából egy perc alatt, mindenféle kezelendő szerver nélkül. Arra voltam kíváncsi, hogy ebből mennyi állja meg a helyét, amikor tényleg te kattintasz a telepítésre, ezért ezt találtam.

Modern webalkalmazások telepítése gyorsabban a Hostingerrel

Telepíts modern webalkalmazásokat a Hostingerre automatizált buildeléssel, menedzselt infrastruktúrával, globális CDN-nel, SSL-lel, biztonsági eszközökkel és 30 napos pénzvisszafizetési garanciával.

Látogatton el a(z) Hostinger weboldalára

Előnyök és hátrányok

Értékelés bontásban

A Hostinger Web Apps Hosting pontozásához a HostAdvice értékelési módszertanát alkalmaztam, ugyanazt a szabványosított megközelítést, amelyet az oldal minden véleményénél használnak, így a pontszámok a valós tesztelésre támaszkodnak, nem a marketingnyelvre. Így teljesített az egyes paraméterek mentén.

Hostingerrel gyorsabban telepíthetsz webalkalmazásokat

Telepíts modern webalkalmazásokat a Hostingerre automatizált buildeléssel, menedzselt infrastruktúrával, globális CDN-nel, SSL-lel, biztonsági eszközökkel és 30 napos pénzvisszafizetési garanciával.

Látogatton el a(z) Hostinger weboldalára

Tervezetek és árak

A Hostinger a Web Apps Hostingot két csomagban kínálja, Business és Cloud Startup néven, mindkettő kifejezetten Node.js és modern JavaScript alkalmazások telepítésére készült, nem pedig hagyományos weboldalkészítésre.

A Cloud Startup, amelyet teszteltem, a Businesshez képest megduplázza az alkalmazásengedélyt és a CPU-magok számát, és mindkét csomag az első évre ingyenes domaint, ingyenes üzleti emailt és menedzselt SSL-t is tartalmaz a fizetésnél.

Néhány dolog, amit érdemes tudni rendelés előtt:

• Pénzvisszafizetési garancia: A Web Apps Hosting a Hostinger standard hosting-visszatérítési feltételei alá tartozik, vagyis a vásárlástól számított egyszerű 30 napos időszak vonatkozik rá. Ez érezhetően egyszerűbb annál, ami a Hostinger VPS-csomagjaira vonatkozik, ahol további 180 napos várakozási idő van a visszatérítési igények között. Itt ilyen várakozási idő nem érvényes.
• Ingyenes próba: Nem találtam külön ingyenes próbát. Ehelyett a 30 napos pénzvisszafizetési garancia jelenti az értékelési időszakot.
• Fizetési módok: A fizetésnél alapértelmezés szerint bankkártyás fizetés jelent meg, Visa, Mastercard, Amex és Discover logókkal, valamint lehetőséggel más fizetési mód hozzáadására a checkout során.
• Mi van benne az árban: Egy évre ingyenes domain, egy évre ingyenes postafiókok és menedzselt SSL külön költség nélkül járnak a csomag árához, így a címkeár nagyjából megegyezik a teljesen működő, biztonságos telepítés tényleges költségével.
• Az egyetlen feláras opció: A Hostinger Reach, egy email marketing kiegészítő, külön havi árral jelenik meg a kosárban. Könnyű kihagyni, és alapból nincs bejelölve vagy csomagolva.

Ha a Web Apps Hosting csomagot 30 napon belül lemondod, a Hostinger visszatérítési szabályzata szerint ez a standard feltételek alá tartozik, nem pedig a kizárási listába, így a 30 napos időszakon belüli egyszerű lemondásnak visszatérítésre kell jogosítania, a VPS- vagy domainvásárlásokhoz társuló extra feltételek nélkül.

Funkciók

• Keretrendszer és Node-verzió automatikus felismerése
• Menedzselt MySQL adatbázis-létrehozási eszközök
• Globális CDN alapértelmezés szerint aktív
• WAF és DDoS-védelem benne van
• Napi és igény szerinti mentések
• Malware-szkenner és sebezhetőségi vizsgálat
• GitHub-integráció automatikus telepítéssel
• Ingyenes domain, email és SSL
• SSH-hozzáférés haladó felhasználóknak

A kódtól az élő appig a Hostingerrel

Kösd össze a GitHub repository-dat, vagy töltsd fel a projektedet, és tedd online menedzselt infrastruktúrával, automatikus telepítésekkel és napi mentésekkel.

Látogatton el a(z) Hostinger weboldalára

Teljesítmény

Mivel a Web Apps Hosting teljesen menedzselt, soha nem kapsz shell-hozzáférést egy szerverhez, így nincs CPU-, RAM- vagy lemezhasználat, amit közvetlenül benchmarkolni lehetne, mint egy VPS-értékelésnél.

Amit mérni lehet, az az, milyen gyorsan tölt be és válaszol maga a telepített alkalmazás a világ különböző pontjairól. Ezt négy nézőpontból teszteltem: GTmetrix két kontinensről, egy 50+ pontos globális konzisztencia-ellenőrzés és a Hostinger saját beépített sebességtesztje asztali és mobil nézetben is.

A tesztelt alkalmazás az Ease of Use szakaszban lentebb ismertetett Next.js telepítés, amely az ivory-llama-856835.hostingersite.com címen fut, a Cloud Startup csomagon (4 CPU mag, 4096 MB RAM, 100 GB NVMe tárhely), alapértelmezés szerint aktív CDN-nel.

1. GTmetrix, két kontinensről tesztelve

Kétszer futtattam le a GTmetrixet a világ különböző pontjairól, hogy kiderüljön, az eredmény következetesen megállja-e a helyét, vagy csak egy szerencsés nézőpontból mutat jól.

Mindkét futás során tökéletes, 100%-os eredményt kaptam a Performance és Structure pontszámokra is, és mindkét helyről nulla layout shiftet és nulla blokkolási időt mértem, vagyis semmi nem versengett az oldalbetöltés közben a böngésző figyelméért, és semmi nem ugrált el a helyéről.

A valóban érdekes rész az, hogy Frankfurt valójában minden időmérési mutatóban legyőzte Chicagót, pedig szándékosan US szerverhelyszínt választottam ehhez az apphoz. Ez csak a CDN fényében értelmezhető.

Ha egy CDN aktív, ahogy itt alapértelmezés szerint is volt, a látogató nem feltétlenül közvetlenül az origin szervert éri el.

Lehet, hogy a legközelebbi gyorsítótárazott edge node-ot éri el, ezért előfordulhat, hogy egy európai tesztpont gyorsabb, mint egy amerikai, még akkor is, ha a tényleges szerver az Egyesült Államokban található. Ez valódi, gyakorlati megerősítése annak, hogy a Hostinger alapból bekapcsolt CDN-je ténylegesen dolgozik, és nem csak marketingbulletpontként létezik.

2. Globális konzisztencia (Check-Host)

HTTP-ellenőrzést futtattam az élő URL-re a Check-Host által kínált összes ellenőrzőpontról, 54 helyszínről, hat kontinensen. A teljes kép:

Minden sikeres ellenőrzés tiszta 200 OK-t adott vissza, semmilyen hiba, részleges hiba vagy váratlan átirányítás nélkül.

A válaszidők világosan megmutatták, hogyan viselkedik a CDN gyorsítótárazása a valós távolságoknál:

Az európai ellenőrzőpontok rendre a leggyorsabb időket adták vissza, több esetben 50 milliszekundum alatt, míg a legmesszebb lévő, bármely edge node-tól legtávolabbi ellenőrzőpontok, Tokyo, Singapore, Ho Chi Minh City, továbbra is érvényes 200 válaszokat adtak, csak lassabban, 0.3 és 0.8 másodperc közötti tartományban.

Ez a várható minta egy CDN-re épülő telepítésnél: gyors az edge-ek közelében, de távolabb is teljesen működőképes.

A négy időtúllépés, Kazakhstan, Romania és az orosz ellenőrzőpontok közül kettő, nem a Hostinger infrastruktúrájának hibájára utalnak szerintem.

Más ellenőrzőpontok ugyanazokban az országokban sikeresen lefutottak, (Saint Petersburg tiszta 0.063s eredményt adott, miközben két Moscow ellenőrzőpont időtúllépést kapott), ami inkább az ellenőrzőpont oldalán lévő regionális hálózati szűrésre utal, nem a telepített app problémájára.

3. A Hostinger saját sebességtesztje asztali és mobil nézetben

A Hostinger a dashboardon belül saját Page Speed tesztet futtat, ezért az eredményeit az independent GTmetrix-mérésekkel hasonlítottam össze, ahelyett hogy bármelyiknek önmagában hittem volna.

Mindkét eszköztípus tökéletes 100-as értéket kapott, és az asztali számok szorosan egybevágnek azzal, amit a GTmetrix függetlenül mért, és ez az egész lényege annak, hogy két eszközzel is futtassuk. Két különböző eszköz, két különböző módszertan, és egyetértenek egymással.

A mobil minden időzítési mutatóban lassabb lett, ahogy várható volt egy szimulált lassabb kapcsolaton és gyengébb processzoron, de még így is elég gyors ahhoz, hogy a 100-as pontszám valóban erős valós mobilteljesítményt tükrözzön, ne csak egy engedékeny értékelési görbét.

Egy következetlenség magában az eszközben. Bár a pontszám mindkét eszközön tiszta 100, a Diagnostics panel alatta továbbra is néhány elemet szó szerint 0 ponttal jelöl: network dependency tree, document request latency és avoiding multiple redirects, valamint két 50 ponttal értékelt elemet, unused JavaScript és legacy JavaScript.

Ezek az alacsony részpontszámok nem húzták le a fő pontszámot, ezért inkább kisebb, valóban meglévő optimalizálási lehetőségként kezeld őket, nem pedig a telepítés problémájaként.

Emellett a Hostinger az ilyen diagnosztika mellett megjelenített “hasznos linkek” mind WordPresshez íródtak: “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, miközben ez egy Node.js app, amelynek a stackjében egyáltalán nincs WordPress. Ez egy közös diagnosztikai sablonból maradt maradvány, nem pedig a termékhez készült tartalom.

Összegző ítélet a teljesítményről

Menedzselt webalkalmazás-hosting a Hostingerrel

Fókuszálj az alkalmazásod fejlesztésére, miközben a Hostinger gondoskodik a telepítésről, az infrastruktúráról, a biztonságról, az SSL-ről, a mentésekről és a globális kiszállításról.

Látogatton el a(z) Hostinger weboldalára

Könnyű használhatóság

A Hostinger Web Apps Hostingját a landing page-től a checkouton át egészen egy hideg fiókból induló, teljesen élő, működő Node.js telepítésig teszteltem.

Ez lefedte a csomag kiválasztását, a fizetést, a buildelési mód kiválasztását, a GitHubhoz csatlakozást és a build valós idejű figyelését. Így nézett ki a folyamat a valóságban.

1. Regisztráció

A Web Apps Hosting landing page-ről indultam, ahol egyetlen fő CTA van: Start deploying.

Erre kattintva nem egy regisztrációs űrlap nyílik meg. Egyenesen a pricing szekcióhoz görget, így az első valódi döntésed az, melyik csomagot veszed meg, nem az, milyen fiókadatokat töltesz ki.

Két csomag volt egymás mellett:

A Cloud Startupot választottam, mert a belépő szintű csomagnál kétszer annyi alkalmazást és CPU-tartalékot kapok. Egy apró ellentmondás itt megjegyzendő: a pricing oldalon “Cloud Startup” a neve, de amikor a kosárba kerül, ugyanazt a csomagot “Startup plan” címkével jelölik. Nem funkcionális probléma, csak névkülönbség ugyanazon checkout folyamat két képernyője között.

Maga a kosár tiszta volt. Felsorolta a 48 hónapos futamidőt, a megtakarítást, az egy évre ingyenes domaint és a ingyenes postafiókokat, majd felajánlott egyetlen upsell opciót, a Hostinger Reach email marketinget, amely saját kiemelt dobozban jelent meg, nem előre kijelölve.

Kihagytam, és kattintottam a Continue gombra, minden különösebb akadály nélkül.

Ha új ügyfél vagy, nem pedig meglévő, a checkout itt beszúr egy fióklétrehozási lépést, mielőtt elérnéd a számlázási címet és a fizetési oldalt.

Ezután megadod a számlázási címet, kiválasztod a fizetési módot, bankkártya, PayPal vagy más opciók egyike, majd elküldöd. A Submit payment gombra kattintás után néhány pillanaton belül megkaptam a vásárlási visszaigazoló emailt, majd egyenesen az hPanelre kerültem, ahol a csomag már elő volt készítve.

Mit gondoltam: A checkout rövid, az upsell könnyen elutasítható rejtett skip link keresgélése nélkül. A csomagnevek eltérése a pricing oldal és a kosár között apróság, de az a fajta részlet, ami miatt egy első vásárló megáll, és még egyszer ellenőrzi, hogy a megfelelő szintet választotta-e.

2. Dashboard

Amint a fizetés átmegy, az hPanelbe kerülsz, a Hostinger saját, házon belül fejlesztett vezérlőpultjába, amelyet minden általa kínált termék kezelésére épített, nem egy kifejezetten az új Web Appodra szabott oldalra.

Az első oldal, ahová érkezel, a Home, és egy AI prompt sáv köré épül a tetején: “Hi, [your name]! How can I help you today?” egy szövegmezővel alatta és hat gyorsgombbal: Get domain, Create website, Get email, Migrate site, Get VPS és Try email marketing.

Ha lefelé görgetsz, megtalálod:

• Funkciópromóciós csempéket az AI Builderhez, az online bolt eszközhöz, az ingyenes üzleti email állításához, az AI ügynökökhöz, egy automatizálási apphoz és az ingyenes domain állításához
• Egy teendőlistát az olyan feladatok felé terelve, mint a Reach beállításának befejezése, az ingyenes email igénylése, az ingyenes domain igénylése
• Your business, az összes webhelyed, appod és VPS példányod futó listáját a fiókodhoz társítva, mindegyik mellett saját Manage site gombbal
• VPS, egy külön táblázat lejjebb, amely az esetleges VPS-példányokat listázza IP-cím, állapot és lejárati dátum szerint

Egy Agent panel is mindig ott van a jobb felső sarokban minden hPanel oldalon, nem csak a Home-on. Ugyanaz a Kodee asszisztens, amely a támogatásnál is működik, de itt általános műveleti eszközként jelenik meg, előre elkészített promptokkal, például “Deploy my Node.js app” vagy “Harden VPS updates”, amelyeket egy teljes kérdés begépelése nélkül is elindíthatsz.

A Home valóban hasznos, ha az appod már létezik, a Your business alatti minden közvetlenül arra mutat. De nem itt hozol létre új Web Appot, és nem innen éred el a Setup gombot. Ehhez a sidebaron egy másik útvonalat kell követned:

1. Kattints a bal oldali sávban a Websites elemre
2. Egy almenü nyílik alatta: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Kattints a Web Apps elemre

Ez a kattintás egy teljesen más képernyőre visz, mint a Home, egy olyan felületre, amely a valódi hosting csomagjaid köré szerveződik, nem egy prompt sáv köré.

Itt minden csomag külön kártyát kap. Az én fiókomban ez három egymás alá rendezett kártyát jelentett:

A Business kártyán már egy élő app is szerepelt alatta egy korábbi tesztből, orange-walrus-700988.hostingersite.com, saját Tools és Dashboard gombokkal.

Ez önmagában is hasznos észrevétel. Amint egy Web App létezik, a kártyája kap egy ilyen sort, amely közvetlenül mutatja az élő oldalt, pontosan úgy, ahogy a Cloud Startup kártyád fog kinézni, amikor befejezed a beállítást.

Mivel a Cloud Startup volt az épp most megvásárolt, de még be nem állított csomagom, ezen a kártyán egyetlen Setup gomb jelent meg. Ez az a gomb, amely ténylegesen elindítja a Web App létrehozási varázslót, és csak itt jelenik meg, a Websites → Web Apps alatt, nem pedig a Home képernyőről, amelyre alapból érkezel.

Mit gondoltam: Az hPanel érthető, ha egyszer megtalálod a megfelelő képernyőt, de a Web Apps Hostingnak nincs nyilvánvaló belépési pontja. A Home-ra érkezve egy prompt sávot és gyorsgombokat kapsz, nem egy utat az app létrehozásához, tudnod kell, hogy a Websites, majd a Web Apps elemre kattints, mielőtt egyáltalán megjelenik a Setup. Ez néhány extra kattintás egy olyan terméknél, amelyet “egy perc alatt élőbe” szlogennel árulnak. Ha viszont egyszer ott vagy, a csomagkártyák tiszták és őszinték az állapottal kapcsolatban, és egy már futó appot tartalmazó csomag ezt azonnal meg is mutatja a kártyán.

3. Az alkalmazás telepítése

A Setup kattintása a csomagkártyán egy rövid bevezető folyamatot nyitott meg: Where would you like to start? három opcióval, Create a new site, Migrate an existing site, vagy I hired someone to build my site. A Create a new site opciót választottam.

Ez vezetett a How do you want to build your website? képernyőre, amely felül két kezdőknek szánt opcióra oszlott, Hostinger AI Builder és WordPress + AI, alatta pedig egy külön “for advanced users” címsor alatt két opcióra: Node.js web app és PHP/HTML website. A Node.js web app kiválasztása az, ami ténylegesen a Web Apps Hosting termékre visz.

Ez egy fontos szerkezeti megjegyzés mindenkinek, aki összehasonlítja a termékeket: a Web Apps Hostingnak nincs saját, külön regisztrációs folyamata.

Ez csak egy ág ugyanabban az általános webhelylétrehozó varázslóban, amelyet az AI Builder és a WordPress is használ.

Rákattintottam a körre a Node.js web app mellett, majd a Next gombra.

Innen:

• Domain képernyő: a Use temporary domain opciót választottam, a valódi domain helyett, mivel ez egy teszttelepítés volt.

• Szerverhelyszín képernyő: a Hostinger előre Franciaországot választotta, a számlázási országomhoz legközelebbi régiót, és 167ms késleltetést mutatott. Az Egyesült Államok opcióra görgetve 364ms volt látható, vagyis több mint kétszeres érték.

Ennek ellenére az Egyesült Államokat, Massachusetts-t választottam, és ez az a pontos tanulság, amit a Hostinger minden termékének helyszínválasztója megmutat: ott válassz, ahol a valódi látogatóid vannak, ne ott, ahol a lista a legalacsonyabb értéket mutatja.

A tesztappom tervezett közönsége amerikai, így egy US szerver valóban gyorsabban szolgálja ki őket, mint egy francia, függetlenül attól, hogy mit mutatott nekem a választó a saját helyemről nézve. A képernyőn látható szám azt mutatja, milyen gyorsan válaszol a szerver a Hostinger tesztjére, nem azt, milyen gyorsan válaszol majd azokra az emberekre, akik ténylegesen használják az oldaladat.

• Telepítési mód képernyő: két fő opció, Import Git repository (Recommended jelöléssel) vagy Upload your files, alatta pedig egy callout a Claude Code, Cursor vagy VS Code segítségével, a Hostinger Connectoron keresztül történő közvetlen telepítésről. Az Import Git repository opciót választottam, majd a Connect with GitHub gombra kattintottam.

Ez egy valódi GitHub bejelentkezési ablakot nyitott meg, ha még nem voltál bejelentkezve, majd egy engedélyezési képernyőt Install & Authorize Hostinger címmel, ahol a következők közül kellett választani:

• telepítés all repositories esetén az összes repositorydra, a jövőbeliakra is, csak olvasási hozzáféréssel a nyilvános repo-khoz
• telepítés only select repositories esetén, ahol külön kiválasztod az egyes repositorykat, és pontosan felsorolják a megadott engedélyeket: olvasási hozzáférés az actions, metadata és repository hooks elemekhez, valamint olvasási és írási hozzáférés az administration, code és pull requests elemekhez. Amint az Install & Authorize gombra kattintasz, a GitHub automatikusan visszairányít az hPanelbe.

Megérkezel a Select Git repository to import képernyőre, egy görgethető listára a GitHub-fiókodhoz tartozó összes repo-val, mindegyik mellett saját Deploy gombbal. Megtaláltam az előzőleg feltöltött teszt repositoryt, hostadvice-webapps-test, és a mellette lévő Deploy gombra kattintottam.

Attól a kattintástól számítva közel 30 másodperc telt el semmilyen látható előrehaladási jelzés nélkül, mielőtt a következő oldal betöltött, olyan sokáig, hogy az ember azon tűnhet el, egyáltalán regisztrálta-e a kattintást.

Végül egy Review build settings című oldal töltődik be, amely pontosan megmondja, hol fog élni az alkalmazásod, mielőtt bármit véglegesen rögzítenél: “Deploys to ivory-llama-856835.hostingersite.com.” Alatta, anélkül hogy egyetlen mezőt is megérintettél volna, már automatikusan felismerte:

Mindegyik öt sor mellett saját Change vagy Add gomb található, így semmi nincs lezárva, ha a felismerés valamit rosszul talált el.

Rákattintottam az Environment variables melletti Add gombra, és beállítottam egy kulcs-érték párt, hogy később ellenőrizni lehessen, tényleg eljut-e az élő apphoz, majd rákattintottam a párbeszédablakban a Finish gombra, ezután pedig az oldal alján lévő fő Deploy gombra.

A build figyelése

A képernyő egy Deploying… nézetre vált, látható előrehaladási sávval, “Deployment from GitHub” felirattal, amely szakaszosan halad előre, láttam, ahogy 28%-nál, majd 51%-nél jár. Az előrehaladási sáv alatt egy összecsukható Build logs panel van, amelyet kinyitva valódi, élő terminálkimenet jelenik meg, nem egy helykitöltő 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 …

A telepítés befejeződött

Amikor a build elkészül, egy Deployment completed! képernyőre érkezel, ahol az élő appod valós miniatűr előnézete látszik közvetlenül a kártyán, a repository névvel és a hozzárendelt élő URL-lel együtt.

Ebből az oldalból közvetlenül rákattinthatsz a Go to dashboard gombra, ahol aztán kezelheted az appot.

Mit gondoltam: Az automatikus felismerés a legnagyobb erősség itt. A framework, a branch és a Node-verzió egyetlen kézi mező nélkül is helyesen jött ki, az élő buildnapló pedig átláthatóbbá teszi a várakozást, ahelyett hogy fekete doboznak tűnne. Az egyetlen gyenge pont az a 30 másodperces szünet, mielőtt egyáltalán eléred a beállítási képernyőt, elég hosszú ahhoz, hogy azt hidd, valami megakadt, mielőtt a folyamat láthatóan elindul.

4. Az élő telepítés ellenőrzése

Mielőtt bármilyen kezelőeszközt megnéztem volna, ellenőrizni akartam, hogy az app tényleg települt és működik-e, nem csak “Completed” állapotot mutat a képernyőn.

A Deployment completed oldalról egyenesen az élő URL-re kattintottam, ivory-llama-856835.hostingersite.com, a dashboard előnézeti bélyegképe helyett.

Az élő oldal betöltődött, és pontosan azt mutatta, amit az app kódolva megjelenít:

• Server build time, egy élő időbélyeg, amely megerősíti, hogy az oldal frissen épült, nem egy régi cache-ből szolgálják ki
• Environment variable check, amely megmutatja a telepítési képernyőn beállított egyedi változót, helyesen visszaigazolva a tényleges élő oldalon, nem csak a dashboard előnézetében

Ezután rákattintottam az app saját Ping the API route gombjára, amely egy élő backend végpontot hív meg, nem csupán statikus tartalmat renderel. Egy tiszta JSON választ adott vissza:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Ez a válasz fontosabb, mint amilyennek elsőre látszik. Az oldal helyes betöltődése csak azt bizonyítja, hogy a statikus fájlok feltöltődtek.

Egy működő API-hívás azt bizonyítja, hogy maga a Node.js szerver is fut alatta, és valódi kérésekre válaszol, vagyis a “Node.js web app” hosting azon része, amelyet statikus fájllal könnyű eljátszani, de egy élő, a gombnyomás pillanatában generált szerveridőbélyeggel nehéz.

Mit gondoltam: Ez az a kontroll, amit szerintem minden telepítés előtt érdemes lefuttatni ezen a platformon, vagy bármely hasonlón. Egy zöld “Completed” státusz és egy előnézeti bélyegkép azt mondja meg, hogy a build befejeződött. Ha viszont átkattintasz az élő URL-re, és megindítasz valami dinamikusat, egy API-hívást, egy adatbázis-olvasást, bármit, amit nem lehet egy gyorsított statikus oldalból utánozni, az mutatja meg, hogy a szerver valóban él, és azt csinálja, amire építetted.

5. Web App kezelése

Miután az élő app működését megerősítettem, visszamentem az hPanelbe, és végigvizsgáltam az app saját kezelőfelületét, a termék valódi szerverkezelő rétegét, külön a korábban ismertetett általános hPanel Home oldaltól.

Dashboard áttekintés. Amint ide érkezel, négy állapotjelző mutatja a helyzetet egy pillantással:

Mind a négy alapértelmezés szerint zöld volt, semmit sem kellett kézzel bekapcsolnom. Alatta egy Last deployment kártya látható, amely megerősíti az állapotot, a repositoryt, az alkotót, a commitot, a telepítés idejét, a felismerett stack-et és a Node-verziót, mindent, amit az ember egy pillantással szeretne ellenőrizni anélkül, hogy a naplókat bogarássza.

Egy automatikus Page Speed test már lefutott az élő oldalon, a saját kezdeményezésem nélkül, és 99/100-as Desktop pontszámot adott, miközben mellette egy Essentials panel gyorslinkeket kínált az adatbáziskapcsolathoz, mentésekhez, fájlkezelőhöz, futásidejű naplókhoz és cache-hez.

Telepítések, környezeti változók és naplók. Három külön oldal foglalkozik ezzel:

• Deployments megőrizte a push teljes történetét, az alkotót, a branch-et, a commit hash-t és a befejezési állapotot, valódi előzménnyel, nem csak az utolsó bejegyzéssel
• Environment variables helyesen listázta azt az egy változót, amelyet a telepítés során állítottam be, megerősítve, hogy eltárolódott és érvényesült, nem csak egyszer jelent meg a beállításnál és aztán eltűnt
• Runtime logs élőben közvetítette a szerver kimenetét, Next.js indulási sorokat, ready időbélyegeket, valamint a problémák és hibák futó számát, amelyek végig nulla és nulla maradtak, amíg néztem

Biztonság. A Malware Scanner tiszta eredményt adott: “Your website is safe”, egy világosan jelzett korláttal: csak a webhelyfájlokat ellenőrzi, az adatbázistartalmat nem, és létezik fizetős tisztítási opció is, ha mélyebb vizsgálatot szeretnél, amely az adatbázist is érinti. A Vulnerabilities vizsgálat is tiszta lett.

Adatbázisok. Itt van a termék marketingje és a valóság közötti tényleges rés, amit meg kell értened vásárlás előtt. A csomag a managed MySQL-t headline funkcióként hirdeti, de semmi sem jön létre automatikusan helyetted.

A Databases rész egy manuális Create a New MySQL Database And Database User űrlappal nyílik meg, vagyis neked kell elnevezned és létrehoznod az adatbázist, mielőtt az appod használni tudná. Ezt közvetlenül a Kodee-vel is ellenőriztem, erről lentebb a Support részben írok, és a válasz egyértelmű volt: a managed azt jelenti, hogy a Hostinger a háttérben üzemelteti az adatbázis-infrastruktúrát, nem azt, hogy az adatbázis már a telepítés pillanatában készen várna.

Speciális hozzáférés. Az SSH-hozzáférés az Advanced alatt érhető el, saját IP-vel, porttal és felhasználónévvel, de alapból Inactive állapotban van, és manuális Enable kattintást igényel, mielőtt használhatnád. A File Manager lehetőséget ad arra, hogy csak az app fájljait, vagy a teljes hosting terv minden fájlját böngészd.

Mit gondoltam: A napi kezelésre szánt dashboard átgondolt és jól szervezett. Különösen a biztonság és a telepítéstörténet könnyen megtalálható és valóban informatív, a nulla hibás futásidejű napló és a tiszta malware-szkenner pedig valódi bizalmat adott, hogy az app egészséges, nem csak online.

Az egyetlen terület, ahol a felület többet sugall, mint amennyit valójában ad, az adatbázis-rész, ahol a “managed MySQL” a csomagoldalon úgy hangzik, mintha készen várna, holott a gyakorlatban egy kézi létrehozási űrlapot jelent, egyszerű ugyan, de neked kell végigcsinálnod.

Összegző ítélet a könnyű használhatóságról

Alkoss, telepíts és skálázz a Hostingerrel

Host modern webalkalmazásokat GitHub-integrációval, menedzselt MySQL-lel, globális CDN-nel, korlátlan sávszélességgel és beépített biztonsági eszközökkel.

Látogatton el a(z) Hostinger weboldalára

Támogatás szintje

A Hostinger Web Apps Hosting támogatását a hPanelbe épített Kodee AI asszisztensen keresztül teszteltem, majd átnéztem a tudásbázist is, hogy lássam, mennyire fed le mindent anélkül, hogy kérdezned kellene valakitől. A Kodee két helyen jelenik meg, és fontos különbséget tenni köztük: a nyilvános marketingoldalon Ask AI-ként, illetve a hPanelen belül bármelyik oldalról elérhető Agent panelként, beleértve közvetlenül a Web App saját dashboardját is.

1. AI támogatás (Kodee)

Két olyan kérdést tettem fel, amelyek a tesztelés során talált valódi hiányosságokra épültek, nem pedig általános keresésekre, amelyeket a Kodee egyszerűen ki tudna másolni a dokumentációból.

1. kérdés a buildhiba-kezelést és a környezeti változók időzítését tesztelte, két valódi üzemi kérdést mindenki számára, aki erre a platformra telepít:

Ha egy appom buildje félúton elhasal egy GitHub telepítés során, akkor az alkalmazás automatikusan visszaáll az utoljára sikeres verzióra, vagy leáll, amíg ki nem javítom és újra nem telepítem? És tudok-e egyéni környezeti változókat beállítani az első telepítés előtt, vagy csak utána?

A Kodee közvetlenül és helyesen válaszolt mindkét pontra. Egy hibás build nem írja felül a jelenleg futó appot; ha volt korábbi sikeres telepítés, akkor az app továbbra is azt az utoljára működő verziót szolgálja ki. Ha ez az első telepítés, és nincs mire visszaesni, az app leáll, amíg a buildet nem javítod és nem telepíted újra — egyértelmű, őszinte válasz, nem homályos megnyugtatás.

A környezeti változóknál megerősítette, hogy az első telepítés előtt is beállíthatók a deployment beállításaiban, egy már futó app esetén pedig végigvezette a pontos három lépésen: nyisd meg a Settings és Redeploy részt, add hozzá vagy módosítsd a változókat az Environment variables alatt, mentsd el és telepítsd újra.

2. kérdés azokat a réseket célozta, amelyeket magam is találtam a dashboard böngészése közben: a “managed MySQL” megfogalmazást a manuális létrehozási űrlappal szemben, illetve az SSH alapértelmezés szerint inaktív állapotát:

A csomag managed MySQL-t hirdet, de a dashboard egy manuális ‘Create a New MySQL Database’ űrlapot mutat, nem pedig automatikusan létrehozott adatbázist. Minden Web Apphoz alapból létrejön adatbázis, vagy csak akkor, ha én magam hozok létre egyet? Továbbá az SSH-hozzáférés elérhetőként szerepel, de alapból Inactive állapotban van. Ha soha nem aktiválom, az változtat valamit azon, ahogyan az appom működik, vagy az SSH pusztán egy opcionális extra haladó felhasználóknak?

A Kodee válasza pontosan azt erősítette meg, amit a felületen is láttam, nem egy enyhébb verzióját. Nem jön létre automatikusan adatbázis minden Web Apphoz; a “managed” azt jelenti, hogy a Hostinger kezeli az adatbázisszolgáltatást és az infrastruktúrát, miközben egy valódi adatbázis létrehozása és beállítása rád hárul, ugyanazon a Create a New MySQL Database képernyőn keresztül, majd neked kell hozzáadnod a kapcsolati adatokat az appod környezeti változóihoz.

Az SSH-ról azt is megerősítette, hogy ha inaktívan hagyod, az semmit sem változtat azon, ahogyan az app fut, települ vagy az adatbázishoz kapcsolódik. Ez kizárólag opcionális eszköz CLI-parancsokhoz, migrációkhoz vagy közvetlen fájlhűsökhöz, nem pedig valami olyan, amire a platform a háttérben csendben támaszkodik.

Mit gondoltam: Mindkét válasz pontosan azt tükrözte, amit már kézzel is ellenőriztem a dashboardon, ahelyett hogy ellentmondott volna neki vagy elkeni volna a dolgot, és ez annak a jele, hogy a támogatási eszköz tényleg a valódi termékállapotot nézi, nem egy szkriptet ismételget. Egyik kérdést sem lehetett volna pusztán egy általános FAQ-ból kimásolni, és a Kodee mindkettőt konkrét, strukturált, két részből álló válaszokkal kezelte, nagyjából egy perc alatt.

2. Tudásbázis

A Hostinger tudásbázisa egy kategorizált rácsnézettel nyílik meg, összesen 20 kategóriával, mindegyiknél cikkdarabszám látható. Néhány a legnagyobbak közül: az AI Builder 330 cikket tartalmaz, a VPS 276-ot, az Email 127-et, a Website pedig 103-at.

A Web Apps Hosting nem kap saját, külön kategóriát. A tartalma a Getting Started, hPanel és Website területeken szóródik szét, ami valódi megállapítás mindazok számára, akik egy külön központot várnának, mint amilyet a VPS vagy az Email kap.

A “Web Apps” keresés közvetlenül 71 találatot adott 8 oldalon. A top találatok között voltak kifejezetten releváns és csak lazán kapcsolódó tartalmak is:

• How to deploy apps built with Codex on Hostinger, közvetlenül releváns
• Hostinger AI Builder: How to create a web app in agentic mode, kapcsolódó, de más termék
• How to add a Node.js Web App in Hostinger, közvetlenül releváns
• How to install Flutter Web on a VPS at Hostinger, egy teljesen más termék
• Számos Website Builder fizetési mód cikk (PayPal, WeChat Pay, BLIK), amelyek csak annyiban kapcsolódnak, hogy a “web” és “app” szavak valahol szerepelnek bennük

Megnyitottam az egyik top találatot, a How to deploy apps built with Codex on Hostinger cikket, hogy megnézzem a mélységét. Kiderült, hogy alapos, jól strukturált útmutató: az elején felsorolt támogatott keretrendszerek, lépésről lépésre képernyőképek a GitHub-import és ZIP-feltöltés útvonalhoz, egy szakasz a build beállításokról példaparancsokkal, a fájlszerkezet áttekintése a telepítés után, adatbáziskapcsolati varázsló bemutatása, sebezhetőségi monitorozási rész és egy záró FAQ blokk.

Bár Codexre fókuszál, az alapul szolgáló platform ugyanaz, mint az általános Node.js Web App termék mögött, így a legtöbb része közvetlenül alkalmazható.

Mit gondoltam: A keresés alatti cikkdarabszám papíron erősnek tűnik, 71 találat egy kifejezésre, de a mennyiség jelentős része zaj, a hasonló szóhasználat miatt más termékekből érkező találatokkal. Az egyetlen cikk, amelyet teljes egészében megnyitottam, minőségben jól teljesített: világos lépések, valódi képernyőképek és egy tényleges FAQ szekció, de megtalálni ezt úgy kellett, hogy át kellett görgetnem olyan eredményeken, amelyeknek semmi közük nem volt ahhoz, amit valójában telepíteni akartam.

Összegző ítélet az ügyfélszolgálatról

Egyszerű hosting modern webalkalmazásokhoz

Telepíts React, Next.js, Vue, Node.js és más modern alkalmazásokat szerverek vagy összetett infrastruktúra kezelése nélkül.

Látogatton el a(z) Hostinger weboldalára

Ajánljuk a Hostinger Web Apps Hostingot?

Igen. A telepítési folyamat a termék legerősebb része: a stack, a branch és a Node-verzió pontos automatikus felismerése, egy valódi, élő buildnapló a spinner helyett, valamint egy élő app, amely minden teljesítményteszten átment, tökéletes GTmetrix pontszámokkal két különböző kontinensről, tiszta 54 pontos globális konzisztencia-ellenőrzéssel és a Hostinger saját eszközének egyező 100/100 pontszámaival asztali és mobil nézetben. A Kodee ezt megerősítette pontos, konkrét válaszokkal valódi technikai kérdésekre, nem pedig általános szkriptválaszokkal.

A kisebb hibák érdemesek arra, hogy tudd róluk, mielőtt veszel. A “Managed MySQL” a csomagoldalon úgy hangzik, mintha az appod élőbe kerülésének pillanatában készen várna, a valóságban viszont egy manuális létrehozási űrlapot jelent. A dashboardon a Web Apps Hostingnak sincs nyilvánvaló belépési pontja a fő Home képernyőről, tudnod kell, hogy a Websites menübe lépj be először.

Egy fejlesztőnek, aki gyors, keretrendszer-agnosztikus telepítést akar ilyen jól teljesítő infrastruktúrán, ez könnyű ajánlás. Annak, aki azt várja, hogy minden hirdetett funkció azonnal működjön a checkout után, számolnia kell néhány extra perccel az adatbázis kézi beállítására.

Hostinger

5.0

2,471 user reviews

500 Ft /mo

Kezdő ár

Látogatton el a(z) Hostinger weboldalára

Rating based on expert review

• Felhasználóbarát
  4.9
• Támogatás
  4.9
• Szolgáltatások
  4.8
• Megbízhatóság
  4.7
• Ár
  4.5