Hostinger sukurtas Web Apps Hosting remiasi paprastu pažadu: įkelkite savo kodą iš GitHub, ZIP failo arba savo DI kodavimo agento ir maždaug per minutę gaukite gyvą, paruoštą naudoti gamybinį app’ą, be jokio serverio, kurį jums reikėtų prižiūrėti. Norėjau sužinoti, kiek iš to iš tikrųjų pasitvirtina, kai deploy’inti pradedi pats, tad štai ką išsiaiškinau.

Diegkite Web Apps greičiau su Hostinger

Deployinkite modernias web aplikacijas Hostinger platformoje su automatizuotais build’ais, valdoma infrastruktūra, pasauliniu CDN, SSL, saugumo įrankiais ir 30 dienų pinigų grąžinimo garantija.

Aplankykite Hostinger

Privalumai ir trūkumai

Įvertinimo suskirstymas

Vertindamas Hostinger Web Apps Hosting, taikiau HostAdvice įvertinimo metodologiją, tą pačią standartizuotą metodiką, naudojamą visose svetainės apžvalgose, kad balai būtų paremti realiais testais, o ne rinkodaros kalba. Štai kaip jis įvertintas pagal kiekvieną parametrą.

Host jūsų web apps be DevOps rūpesčių

Deployinkite modernias web aplikacijas valdomoje hostingo aplinkoje su automatizuotais deploy’ais, valdomu SSL, pasauliniu CDN ir įmontuotais saugumo įrankiais.

Aplankykite Hostinger

Planai ir kainodara

Hostinger Web Apps Hosting parduodamas kaip du lygiai: Business ir Cloud Startup, abu specialiai sukurti Node.js ir modernioms JavaScript aplikacijoms deploy’inti, o ne tradiciniam svetainių kūrimui.

Cloud Startup, mano testuotas lygis, padvigubina app’ų skaičių ir CPU branduolių skaičių, palyginti su Business, o abu planai į paketą įtraukia nemokamą domeną, nemokamą verslo el. paštą ir valdomą SSL pirmaisiais metais tiesiai perkant.

Keli dalykai, kuriuos verta žinoti prieš užsisakant:

• Pinigų grąžinimo garantija: Web Apps Hosting taikomos standartinės Hostinger hostingo grąžinimo sąlygos, t. y. 30 dienų langas nuo pirkimo datos. Tai gerokai paprasčiau nei Hostinger VPS planams taikoma papildoma 180 dienų pertrauka tarp grąžinimo prašymų. Čia tokia pertrauka netaikoma.
• Bandomasis laikotarpis: Neradau jokio atskiro nemokamo bandomojo laikotarpio. Vietoj jo jūsų vertinimo langas yra 30 dienų pinigų grąžinimo garantija.
• Mokėjimo būdai: Užsakymo lange kaip numatytasis mokėjimo būdas rodoma kortelė, o matomi Visa, Mastercard, Amex ir Discover logotipai, taip pat galimybė checkout metu pridėti kitą mokėjimo būdą.
• Kas įtraukta: Nemokamas domenas vieniems metams, nemokamos pašto dėžutės vieniems metams ir valdomas SSL įtraukti be papildomo mokesčio prie plano kainos, todėl lipduko kaina beveik atitinka realią kainą, kad gautumėte visiškai veikiantį, apsaugotą deploy’ą.
• Vienintelis papildomas pasiūlymas: Hostinger Reach, el. pašto rinkodaros priedas, atsiranda krepšelyje kaip atskiras paryškintas langelis su atskira mėnesine kaina. Jį lengva praleisti, ir jis nėra įtrauktas automatiškai ar pažymėtas iš anksto.

Jei atšauksite Web Apps Hosting planą per 30 dienų, Hostinger pinigų grąžinimo politika patvirtina, kad jis patenka į standartines sąlygas, o ne į išimčių sąrašą, todėl paprastas atšaukimas per tą laikotarpį turėtų suteikti teisę į pinigų grąžinimą be papildomų sąlygų, taikomų VPS ar domenų pirkimams.

Funkcijos

• Automatinis framework ir Node versijos aptikimas
• Valdomo MySQL duomenų bazės kūrimo įrankiai
• Pasaulinis CDN įjungtas pagal numatymą
• Įtrauktos WAF ir DDoS apsaugos
• Kasdienės ir pagal poreikį daromos atsarginės kopijos
• Kenksmingų programų skeneris ir pažeidžiamumų skenavimas
• GitHub integracija su auto-deploy
• Nemokamas domenas, el. paštas ir SSL
• SSH prieiga pažengusiems naudotojams

Nuo kodo iki gyvo app’o su Hostinger

Prijunkite savo GitHub repozitoriją arba įkelkite projektą ir paleiskite jį internete su valdoma infrastruktūra, automatizuotais deploy’ais ir kasdienėmis atsarginėmis kopijomis.

Aplankykite Hostinger

Veikimas

Kadangi Web Apps Hosting yra visiškai valdomas, jūs niekada negaunate shell prieigos prie serverio, todėl CPU, RAM ar disko tiesiogiai benchmark’inti taip, kaip VPS apžvalgoje, nėra galimybės.

Ką galima matuoti, tai kaip greitai pats deploy’intas app’as kraunasi ir atsako iš realių vietų visame pasaulyje. Testavau tai iš keturių skirtingų kampų: GTmetrix iš dviejų žemynų, 50+ taškų pasaulinį nuoseklumo patikrinimą ir Hostinger įmontuotą greičio įrankį tiek desktop, tiek mobile.

Testuojamas app’as yra Next.js deploy’as, aptartas žemiau esančiame Naudojimo paprastumo skyriuje, gyvai adresu ivory-llama-856835.hostingersite.com, veikiantis Cloud Startup plane (4 CPU branduoliai, 4096 MB RAM, 100 GB NVMe saugykla), su CDN įjungtu pagal numatymą.

1. GTmetrix, testuotas iš dviejų žemynų

GTmetrix paleidau du kartus iš skirtingų pasaulio vietų, kad pamatyčiau, ar rezultatas išlieka stabilus, ar gerai atrodo tik iš vieno sėkmingo taško.

Abu paleidimai tiek Performance, tiek Structure gavo tobulus 100%, o abiejose vietose buvo nulis layout poslinkio ir nulis blokavimo laiko, vadinasi, niekas puslapyje nekonkuravo dėl naršyklės dėmesio ir nešokinėjo įkraunant.

Iš tiesų įdomi detalė ta, kad Frankfurtas netgi aplenkė Čikagą visose laiko metrikose, nors šiam app’ui sąmoningai pasirinkau JAV serverio vietą. Toks rezultatas įmanomas tik atsižvelgiant į CDN.

Kai CDN aktyvus, kaip čia buvo pagal numatymą, jūsų lankytojas nebūtinai jungiasi tiesiai prie origin serverio.

Jis jungiasi prie artimiausio cache edge mazgo, todėl Europos testavimo taškas gali pasirodyti greitesnis nei JAV taškas, net jei tikrasis serveris yra JAV. Tai tikras, praktiškas patvirtinimas, kad Hostinger pagal numatymą įjungtas CDN iš tiesų dirba, o ne tik egzistuoja kaip rinkodaros punktas.

2. Pasaulinis nuoseklumas (Check-Host)

Paleidau HTTP patikrą prieš gyvą URL iš kiekvieno Check-Host siūlomo taško, 54 vietų, apimančių šešis žemynus. Bendras vaizdas:

Kiekvienas sėkmingas patikrinimas grąžino švarų 200 OK, jokių klaidų, jokių dalinių nesėkmių, jokių netikėtų peradresavimų.

Atsakymo laikai aiškiai parodė, kaip CDN cache elgiasi realiame atstume:

Europos tikrinimo taškai nuosekliai grąžino greičiausius laikus, keli iš jų buvo mažesni nei 50 milisekundžių, o toliausiai nuo bet kurio edge mazgo esantys taškai, Tokijas, Singapūras, Ho Či Minas, vis tiek grąžino galiojančius 200 atsakymus, tik lėčiau, maždaug 0.3–0.8 sekundės ribose.

Tai ir yra tikėtina CDN pagrindu veikiančio deploy’o forma: greita arti edge mazgų, bet vis tiek visiškai veikianti toli nuo jų.

Keturi timeout’ai, Kazachstanas, Rumunija ir du iš keturių Rusijos tikrinimo taškų, nėra tai, ką laikyčiau Hostinger infrastruktūros problema.

Kiti tų pačių šalių taškai sėkmingai veikė (Sankt Peterburgas atsakė švariai per 0.063s, o du Maskvos taškai „timed out“), o tai labiau rodo regioninį tinklo filtravimą tikrinimo taško pusėje, o ne kažką negero su deploy’intu app’u.

3. Hostinger nuosavas greičio įrankis, desktop ir mobile

Hostinger savo Page Speed testą paleidžia tiesiai app’o valdymo skydelyje, tad palyginau jo skaičius su nepriklausomais GTmetrix rezultatais, o ne pasiklioviau vien tik juo.

Abu įrenginių tipai gavo tobulą 100, o desktop skaičiai glaudžiai sutampa su tuo, ką nepriklausomai matavo GTmetrix, ir tai yra svarbiausia paleidus abu. Du skirtingi įrankiai, dvi skirtingos metodikos ir jie sutaria tarpusavyje.

Mobile buvo lėtesnis visose laiko metrikose, kaip ir tikėtasi esant lėtesniam simuliuotam ryšiui ir silpnesniam procesoriui, tačiau vis tiek pakankamai greitas, kad 100 balų atspindėtų tikrai stiprų realų mobile našumą, o ne tik atlaidesnę vertinimo skalę.

Vienas paties įrankio nenuoseklumas. Nors balas abiem įrenginiams yra švarus 100, Diagnostics skydelis apačioje vis tiek pažymi kelis punktus su tiesioginiu 0 balu: network dependency tree, document request latency ir avoiding multiple redirects, kartu su dviem 50 balais įvertintais punktais, unused JavaScript ir legacy JavaScript.

Nė vienas iš tų žemų sub-balų nesumažino bendro įvertinimo, todėl laikykite juos nedidelėmis, realiai esančiomis optimizavimo galimybėmis, o ne kažkuo negeru deploy’e.

Atskirai, „helpful links“, kuriuos Hostinger rodo šalia šių diagnostikos punktų, yra parašyti WordPress temomis: „Speed up WordPress in 9 easy steps“, „How to optimize images for your WordPress site“, nors čia yra Node.js app’as, visiškai nesusijęs su WordPress. Tai likutis iš bendro diagnostikos šablono, o ne šiam produktui pritaikytas turinys.

Bendras veikimo verdiktas

Valdomas Web App hostingo sprendimas iš Hostinger

Susitelkite į savo app’o kūrimą, o Hostinger pasirūpins deploy’u, infrastruktūra, saugumu, SSL, atsarginėmis kopijomis ir pasauliniu pristatymu.

Aplankykite Hostinger

Naudojimo paprastumas

Testavau Hostinger Web Apps Hosting nuo nukreipiamojo puslapio iki checkout ir tada nuo tuščios paskyros iki visiškai gyvo, veikiančio Node.js deploy’o.

Tai apėmė plano pasirinkimą, mokėjimą, būdą, kaip kurti, GitHub prijungimą ir build stebėjimą realiu laiku. Štai koks iš tikrųjų buvo šis procesas.

1. Registracija

Pradėjau Web Apps Hosting nukreipiamajame puslapyje, kuriame pagrindinis kvietimas veikti yra Start deploying.

Paspaudus jo, neatsidaro registracijos forma. Jus tiesiog nukelia į kainodaros skyrių, tad pirmasis tikras sprendimas yra, kurį planą pirkti, o ne kokius paskyros duomenis pildyti.

Greta vienas kito buvo du planai:

Pasirinkau Cloud Startup dėl dvigubai didesnio app’ų limito ir CPU atsargos, palyginti su pradiniu lygiu. Vienas nedidelis nenuoseklumas, kurį verta paminėti: kainodaros puslapyje jis vadinamas „Cloud Startup“, bet patekęs į krepšelį tas pats planas pavadintas „Startup plan“. Ne funkcionalumo problema, tik pavadinimo neatitikimas tarp dviejų to paties checkout’o ekranų.

Pats krepšelis buvo tvarkingas. Jame rodytas 48 mėnesių terminas, sutaupymai, nemokamas domenas vieniems metams ir nemokamos pašto dėžutės, o tada siūlytas vienintelis papildomas pasiūlymas — Hostinger Reach el. pašto rinkodara, pateikta atskirame paryškintame laukelyje, o ne pažymėta iš anksto.

Jį praleidau ir spustelėjau Continue be jokios trinties.

Jei esate naujas klientas, o ne esamas, checkout čia įterpia paskyros kūrimo žingsnį prieš pasiekiant atsiskaitymo adresą ir mokėjimo puslapį.

Tada pridedate mokėjimo adresą, pasirenkate mokėjimo būdą — kortelę, PayPal ar vieną iš kitų variantų — ir pateikiate. Patvirtinimo el. laišką gavau per kelias akimirkas po to, kai spustelėjau Submit payment, ir tada tiesiai patekau į hPanel, o planas jau buvo provisionintas.

Ką manau: Checkout’as trumpas, o papildomą pasiūlymą lengva atmesti nereikia ieškoti paslėpto skip link’o. Plano pavadinimo neatitikimas tarp kainodaros puslapio ir krepšelio yra smulkmena, bet būtent tokia detalė priverčia pirmą kartą perkančiam žmogui sustoti ir dar kartą patikrinti, ar tikrai pasirinko tinkamą lygį.

2. Valdymo skydelis

Kai tik mokėjimas praeina, patenkate į hPanel — Hostinger vidinį valdymo skydelį, sukurtą visiems jo produktams valdyti, o ne į puslapį, specialiai pritaikytą jūsų naujam Web App.

Pirmas puslapis, į kurį patekote, yra Home, ir jis sukurtas aplink DI užklausų juostą viršuje: „Hi, [your name]! How can I help you today?“ su teksto laukeliu apačioje ir šešiais greitojo pasiekiamumo mygtukais: Get domain, Create website, Get email, Migrate site, Get VPS ir Try email marketing.

Žemiau rasite:

• Funkcijų reklaminius blokus AI Builder, internetinės parduotuvės įrankiui, reklamuojančius nemokamą verslo el. paštą, AI agents, automatizavimo programėlę ir nemokamą domeną
• Užduočių sąrašą, skatinantį atlikti sąrankos veiksmus, užbaigti Reach sąranką, atsiimti nemokamą el. paštą, atsiimti nemokamą domeną
• Your business, visų prie paskyros prijungtų svetainių, app’ų ir VPS instancijų sąrašą, prie kiekvienos su savo Manage site mygtuku
• VPS, atskirą lentelę apačioje, kurioje pateikiamos VPS instancijos pagal IP adresą, būseną ir galiojimo datą

Agent skydelis taip pat nuolat matomas viršutiniame dešiniajame kiekvieno hPanel puslapio kampe, ne tik Home. Tai tas pats Kodee asistentas, naudojamas palaikymui, bet čia pateikiamas kaip bendroji veiksmų priemonė su paruoštais scenarijais, tokiais kaip „Deploy my Node.js app“ arba „Harden VPS updates“, kuriuos galite paleisti neįvesdami viso klausimo.

Home iš tiesų naudinga, kai jūsų app’as jau egzistuoja: viskas skiltyje Your business tiesiogiai nuveda į jį. Tačiau tai nėra vieta, kur kuriamas naujas Web App ar randamas Setup mygtukas. Tam reikia eiti kitu keliu per šoninę juostą:

1. Spustelėkite Websites kairėje šoninėje juostoje
2. Atsidarys poskyris žemiau: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Spustelėkite Web Apps

Tas paspaudimas nukelia į visiškai kitą ekraną nei Home, organizuotą pagal jūsų tikrus hostingo planus, o ne pagal užklausų juostą.

Čia kiekvienas jūsų turimas planas turi savo kortelę. Mano paskyroje tai reiškė tris vertikaliai išdėstytas korteles:

Business kortelėje taip pat jau buvo gyvas app’as iš ankstesnio testavimo, orange-walrus-700988.hostingersite.com, su savo Tools ir Dashboard mygtukais.

Tai savaime naudinga detalė. Kai Web App jau egzistuoja, jo kortelėje atsiranda tokia eilutė, rodanti gyvą svetainę tiesiai ten, ir būtent taip atrodys jūsų Cloud Startup kortelė, kai baigsite sąranką.

Kadangi Cloud Startup buvo planas, kurį ką tik nusipirkau ir dar nebuvau nustatęs, jo kortelėje vietoj to buvo vienintelis Setup mygtukas. Būtent šis mygtukas iš tikrųjų pradeda Web App kūrimo vedlį, ir jis atsiranda tik čia, skiltyje Websites → Web Apps, o ne Home ekrane, kuris rodomas pagal numatymą.

Ką manau: hPanel yra aiškus, kai surandate tinkamą ekraną, bet Web Apps Hosting neturi akivaizdžių vartų į pradžią. Patekus į Home matote užklausų juostą ir sparčiuosius mygtukus, o ne kelią į app’o kūrimą, todėl reikia žinoti, kad pirmiausia reikia spustelėti Websites, tada Web Apps, ir tik tada atsiranda Setup. Tai keli papildomi paspaudimai produktui, kuris reklamuojamas kaip „live in a minute“. Vis dėlto, kai jau esate ten, planų kortelės yra tvarkingos ir sąžiningai rodo būseną, o planas su jau veikiančiu app’u tai aiškiai parodo tiesiai kortelėje.

3. App’o deploy’inimas

Spustelėjus Setup ant plano kortelės, atsidarė trumpas onboarding srautas: Where would you like to start? su trimis pasirinkimais: Create a new site, Migrate an existing site arba I hired someone to build my site. Pasirinkau Create a new site.

Tai nuvedė į How do you want to build your website?, kuriame viršuje pateikiamos dvi pradedantiesiems skirtos parinktys: Hostinger AI Builder ir WordPress + AI, o po atskira „for advanced users“ antrašte apačioje yra dvi parinktys: Node.js web app ir PHP/HTML website. Pasirinkus Node.js web app, iš tikrųjų patenkate į patį Web Apps Hosting produktą.

Tai tikras struktūrinis pastebėjimas visiems, lyginantiems produktus: Web Apps Hosting neturi atskiro registracijos srauto.

Tai viena šaka to paties bendro svetainės kūrimo vedlio, naudojamo AI Builder ir WordPress.

Spustelėjau apskritimą šalia Node.js web app, tada spustelėjau Next.

Nuo ten:

• Domeno ekranas: pasirinkau Use temporary domain, užuot įsipareigojęs tikram domenui, nes tai buvo testinis deploy’as.

• Serverio vietos ekranas: Hostinger iš anksto parinko Prancūziją, artimiausią regioną mano sąskaitos šaliai, ir rodė 167ms vėlavimą. Paslinkus iki Jungtinių Valstijų varianto buvo rodoma 364ms, daugiau nei dvigubai.

Vis tiek pasirinkau United States, Massachusetts, ir tai yra būtent pamoka, kurią Hostinger vietos pasirinkimo sąsaja pateikia visuose produktuose: rinkitės pagal tai, kur yra jūsų realūs lankytojai, o ne pagal mažiausią skaičių sąraše.

Mano testinio app’o numatoma auditorija yra JAV, todėl serveris JAV jiems iš tikrųjų tarnaus greičiau nei serveris Prancūzijoje, nepaisant to, ką man rodė sąsaja iš mano vietos. Ekrane esantis skaičius parodo, kaip greitai serveris atsako Hostinger testui, o ne kaip greitai jis atsakys žmonėms, kurie naudosis jūsų svetaine.

• Deploy metodo ekranas: dvi pagrindinės parinktys — Import Git repository (pažymėta kaip Recommended) arba Upload your files, taip pat žemiau esantis pasiūlymas deploy’inti tiesiai iš Claude Code, Cursor arba VS Code per Hostinger Connector. Pasirinkau Import Git repository ir spustelėjau Connect with GitHub.

Tai atidarė tikrą GitHub prisijungimo langą, jei jau nebuvote prisijungę, tada leidimų ekraną „Install & Authorize Hostinger“, kuriame reikėjo pasirinkti tarp:

• Įdiegimo į all repositories, kuriuos valdote, įskaitant būsimus, su tik skaitymo prieiga prie viešų repo
• Įdiegimo tik į only select repositories, kuriuos pasirinksite individualiai, ir tiksliai išvardytų leidimų, kuriuos suteikiate: read access to actions, metadata, and repository hooks, ir read-and-write access to administration, code, and pull requests. Spustelėjus Install & Authorize, GitHub automatiškai grąžina jus atgal į hPanel.

Patenkate į Select Git repository to import, slankiojamą visų su jūsų GitHub paskyra susietų repo sąrašą, prie kiekvieno esantį Deploy mygtuką. Radau anksčiau įkeltą testinę repozitoriją, hostadvice-webapps-test, ir šalia jos spustelėjau Deploy.

Nuo to momento, kai paspaudžiau tą mygtuką, iki kito puslapio įkrovimo praėjo beveik 30 sekundžių be jokio progreso indikatoriaus ekrane, tiek ilgai, kad galėjai net pagalvoti, jog paspaudimas nebuvo užregistruotas.

Pagaliau įkeltas puslapis vadinasi Review build settings, ir jis tiksliai nurodo, kur gyvens jūsų app’as, prieš jums kažką patvirtinant: „Deploys to ivory-llama-856835.hostingersite.com.“ Po juo, jums neliečiant nė vieno laukelio, jau buvo automatiškai aptikta:

Kiekviena iš šių penkių eilučių turi savo Change arba Add mygtuką šalia, tad niekas čia nėra užrakinta, jei aptikimas ką nors neteisingai nustatytų.

Spustelėjau Add šalia Environment variables ir nustatiau vieną key-value porą, kad patikrinčiau, ar ji tikrai pasieks veikiantį app’ą vėliau, tada dialoge spustelėjau Finish, po to pagrindinį Deploy mygtuką puslapio apačioje.

Build stebėjimas

Ekranas persijungia į Deploying… vaizdą su pažangos juosta, „Deployment from GitHub“, kuri kyla etapais; stebėjau, kaip ji pasiekia 28%, tada 51%, pakeliui į pabaigą. Po pažangos juosta yra išskleidžiamas Build logs skydelis, ir jį išskleidus matyti tikra, gyva terminalo išvestis vykstant procesui, ne laikina sukamėlė:

> 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 …

Deployment completed

Kai build’as baigiasi, patenkate į Deployment completed! ekraną su tiesiogine jūsų tikro veikiančio app’o miniatiūra, pateikta kortelėje, šalia santraukos, kurioje matomas repozitorijos pavadinimas ir priskirtas gyvas URL.

Iš šio puslapio galite iškart spustelėti Go to dashboard, kur vėliau valdote app’ą.

Ką manau: Svarbiausia čia yra automatinis aptikimas. Framework, branch ir Node versija visi buvo nustatyti teisingai be nė vieno rankinio laukelio, o gyvas build log’as daro laukimą skaidrų, o ne nepermatomą. Viena silpnesnė vieta yra tas 30 sekundžių tarpas dar prieš pasiekiant nustatymų ekraną — tiek ilgai, kad gali pasirodyti, jog kažkas užstrigo, kol procesas akivaizdžiai neprasideda.

4. Gyvo deploy’o patvirtinimas

Prieš tyrinėdamas bet kokius valdymo įrankius, norėjau patvirtinti, kad app’as tikrai buvo deploy’intas ir veikė, o ne tik pažymėtas kaip „Completed“ ekrane.

Iš Deployment completed puslapio spustelėjau tiesiai į gyvą URL, ivory-llama-856835.hostingersite.com, o ne pasiklioviau vien dashboard’o miniatiūra.

Gyvas puslapis įsikrovė ir parodė būtent tai, ką app’as turėjo rodyti:

• Serverio build laikas, gyvas laiko žymeklis, patvirtinantis, kad puslapis buvo ką tik sukurtas, o ne rodomas iš seno cache
• Aplinkos kintamojo patikra, rodanti pasirinktinį kintamąjį, kurį nustatiau deploy ekrane, ir kuris buvo teisingai patvirtintas tikrame gyvame puslapyje, o ne vien dashboard’o peržiūroje

Tada paspaudžiau paties app’o mygtuką Ping the API route, kuris iškviečia gyvą backend endpoint’ą, o ne tik atvaizduoja statinį turinį. Jis grąžino švarų JSON atsakymą:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Šis atsakymas svarbesnis, nei gali pasirodyti. Puslapio įkrovimas teisingai įrodo tik tai, kad statiniai failai buvo įkelti.

Veikiantis API iškvietimas įrodo, kad po apačia veikia tikras Node.js serveris ir atsako į realius užklausimus — būtent ta „Node.js web app“ hostingo dalis, kurią lengva suklastoti su statiniu failu ir sunku suklastoti su gyvu serverio laiko žymeniu, sugeneruotu tuo pačiu momentu, kai paspaudžiate mygtuką.

Ką manau: Tai yra patikrinimas, kurį rekomenduočiau jums atlikti prieš pasitikint bet kokiu deploy’u šioje platformoje ar panašioje. Žalias „Completed“ statusas ir peržiūros miniatiūra parodo, kad build’as baigėsi. Perėjus į gyvą URL ir paleidus ką nors dinaminio — API iškvietimą, duomenų bazės nuskaitymą ar bet ką, ko negali suklastoti cache’intas statinis puslapis — matosi, kad serveris iš tikrųjų gyvas ir daro tai, kam buvo sukurtas.

5. Web App valdymas

Patvirtinęs, kad gyvas app’as veikia, grįžau į hPanel ir ištyriau paties app’o valdymo skydelį nuo pradžios iki galo — tikrą šio produkto serverio valdymo sluoksnį, atskirą nuo anksčiau aprašyto bendrojo hPanel Home ekrano.

Dashboard apžvalga. Vos patekus čia, keturi būsenos ženkliukai iš karto parodo situaciją:

Visi keturi pagal numatymą buvo žali, nieko nereikėjo jungti rankiniu būdu. Žemiau yra Last deployment kortelė, patvirtinanti būseną, repozitoriją, autorių, commit’ą, deploy laiką, aptiktą stack’ą ir Node versiją — viską, ko reikia greitai patikrinti be gilinimosi į log’us.

Automatinis Page Speed test jau buvo pats paleistas prieš gyvą svetainę ir grąžino 99/100 Desktop balą man nieko papildomai nepaleidus, šalia stovint Essentials skydeliui su greitomis nuorodomis į duomenų bazės prijungimą, atsargines kopijas, failų tvarkyklę, runtime log’us ir cache.

Deployments, aplinkos kintamieji ir log’ai. Šią sritį dengia trys atskiri puslapiai:

• Deployments saugojo visą push’ų istoriją, autorių, branch’ą, commit hash’ą ir užbaigimo būseną — tikrą istoriją, o ne tik naujausią įrašą
• Environment variables teisingai rodė mano deploy metu nustatytą kintamąjį, patvirtindamas, kad jis saugomas ir pritaikomas, o ne tik vieną kartą parodytas sąrankoje ir pamirštas
• Runtime logs rodė gyvą serverio išvestį jai vykstant: Next.js paleidimo eilutes, ready laiko žymas ir veikiančią issues bei errors skaitiklį, kuris visą laiką, kol stebėjau, liko 0 ir 0

Saugumas. Malware Scanner grąžino švarų rezultatą: „Your website is safe“, su viena aiškiai nurodyta išlyga — jis tikrina tik svetainės failus, ne duomenų bazės turinį, o jei norite gilesnės patikros, įtraukiant duomenų bazę, yra mokama išvalymo galimybė. Vulnerabilities skenavimas taip pat buvo švarus.

Duomenų bazės. Čia produkto rinkodara sukuria tikrą spragą, kurią turėtumėte suprasti prieš pirkdami. Plane reklamuojamas valdomas MySQL kaip pagrindinė funkcija, bet niekas jums nesukuriama automatiškai.

Skiltis Databases atsidaro su rankine Create a New MySQL Database And Database User forma, o tai reiškia, kad duomenų bazę sukuriate ir pavadinate patys, prieš app’ui galint ja naudotis. Tai patvirtinau tiesiogiai su Kodee, apie ką rašau Support skyriuje žemiau, ir atsakymas buvo tiesus: valdoma reiškia, kad Hostinger rūpinasi duomenų bazės infrastruktūra fone, o ne tai, kad duomenų bazė sukuriama jums vos tik app’as pradeda veikti.

Išplėstinė prieiga. SSH prieiga yra skiltyje Advanced, su IP, portu ir username, bet pagal numatymą yra Inactive ir turi būti rankiniu būdu įjungta, jei norite ja naudotis. File Manager leidžia pasirinkti, ar naršyti tik šio app’o failus, ar visus failus visame hostingo plane.

Ką manau: Kasdienis dashboard’as yra išsamus ir gerai suskirstytas. Ypač saugumas ir deploy istorija yra lengvai randami ir tikrai informatyvūs, o nulinės problemos runtime log’as kartu su švariu malware skenavimu man suteikė tikro pasitikėjimo, kad app’as yra sveikas, o ne tik online.

Vienintelė vieta, kur sąsaja šiek tiek perdeda, yra duomenų bazės skyrius, kur „managed MySQL“ planų puslapyje skamba kaip kažkas, kas laukia jūsų vos app’as pradeda veikti, o realybėje reiškia valdymo pultą, kuriame duomenų bazę turite susikurti patys.

Bendras naudojimo paprastumo verdiktas

Statykite, deploy’inkite ir plėskite su Hostinger

Hostinkite modernias web aplikacijas su GitHub integracija, valdomu MySQL, pasauliniu CDN, neribotu srautu ir įmontuotais saugumo įrankiais.

Aplankykite Hostinger

Palaikymo lygis

Hostinger Web Apps Hosting palaikymą testavau per Kodee — DI asistentą, integruotą į hPanel, o tada peržvelgiau žinių bazę, kad pamatyčiau, kiek daug ji aprėpia be poreikio klausti žmogaus. Kodee pasirodo dviejose vietose, kurias verta atskirti: kaip Ask AI viešoje rinkodaros svetainėje ir kaip Agent skydelis, pasiekiamas iš bet kurio hPanel puslapio, įskaitant patį Web App dashboard’ą.

1. DI palaikymas (Kodee)

Uždaviau du klausimus, paremtus realiomis spragomis, kurias pats pastebėjau testuodamas, o ne bendrus užklausimus, į kuriuos Kodee galėtų atsakyti nukopijuodamas dokumentaciją.

1 klausimas tikrino deploy nesėkmės elgseną ir aplinkos kintamųjų nustatymo laiką — tai tikros gamybinės problemos kiekvienam, kuris deploy’ina į šią platformą:

Jei mano app’o build’as nutrūksta GitHub deploy’o viduryje, ar app’as automatiškai grįžta prie paskutinės sėkmingos versijos, ar jis sustoja, kol ištaisysiu problemą ir paleisiu iš naujo? Ir ar galiu nustatyti pasirinktinius aplinkos kintamuosius prieš pirmą deploy, ar tik po jo?

Kodee atsakė tiesiai ir teisingai abiem klausimais. Jei build’as nepavyksta, jis nepakeičia šiuo metu veikiančio app’o; jei ankstesnis deploy buvo sėkmingas, app’as ir toliau aptarnauja tą paskutinę veikiančią versiją. Jei tai pirmas deploy ir nėra prie ko grįžti, app’as lieka neaktyvus, kol problema neišspręsta ir deploy’as nepakartotas — aiškus, nuoširdus atsakymas, o ne miglotas nuraminimas.

Dėl aplinkos kintamųjų jis patvirtino, kad juos galima nustatyti prieš pirmą deploy deployment settings skyriuje, o jau veikiantį app’ą atveju jis nurodė tikslius tris žingsnius: atidaryti Settings ir Redeploy, pridėti arba redaguoti kintamuosius skiltyje Environment variables, išsaugoti ir redeploy’inti.

2 klausimas tikrino dvi spragas, kurias pats radau naršydamas dashboard’e: „managed MySQL“ formuluotę prieš rankinio kūrimo formą ir SSH, kuris pagal numatymą yra neaktyvus:

Šis planas reklamuoja managed MySQL, bet dashboard’e rodoma rankinė „Create a New MySQL Database“ forma, o ne automatiškai provisioninta duomenų bazė. Ar kiekvienam Web App pagal numatymą sukuriama duomenų bazė, ar tik jei ją susikuriu pats? Taip pat SSH prieiga nurodyta kaip prieinama, bet pagal numatymą rodo Inactive. Jei jos niekada neįjungsiu, ar tai ką nors pakeis, kaip mano app’as iš tikrųjų veikia, ar SSH yra tik pasirinktinis priedas pažengusiems naudotojams?

Kodee atsakymas tiksliai patvirtino tai, ką pats pamačiau sąsajoje, be jokių švelninimų. Duomenų bazė nėra sukuriama automatiškai kiekvienam Web App; „managed“ reiškia, kad Hostinger valdo duomenų bazės paslaugą ir infrastruktūrą, o tikros duomenų bazės sukūrimas ir konfigūravimas yra jūsų darbas per tą pačią Create a New MySQL Database formą, po to prijungiant jos duomenis prie app’o aplinkos kintamųjų patiems.

Dėl SSH jis patvirtino, kad palikus ją neaktyvią, niekas nekeičiasi app’o veikime, deploy procese ar prisijungime prie duomenų bazės. Tai pateikiama tik kaip pasirinktinis įrankis CLI komandoms, migracijoms ar tiesioginiam failų derinimui, o ne kaip kažkas, nuo ko platforma slapta priklauso.

Ką manau: Abu atsakymai visiškai atitiko tai, ką jau patvirtinau rankiniu būdu dashboard’e, užuot tam prieštaravę ar švelninę situaciją, ir būtent tai rodo, kad palaikymo įrankis tikrai tikrina realią produkto būseną, o ne kartoja scenarijų. Nei vieno klausimo nebuvo galima atsakyti paprasčiausiai įklijuojant standartinį DUK, o Kodee abu kartus pateikė konkrečius, struktūruotus, dviejų dalių atsakymus maždaug per minutę.

2. Žinių bazė

Hostinger žinių bazė atsidaro kaip suskirstytas tinklelis, iš viso 20 kategorijų, kiekvienoje rodoma straipsnių skaičius. Keletas didžiausių: AI Builder turi 330 straipsnių, VPS turi 276, Email turi 127, o Website turi 103.

Web Apps Hosting neturi atskiros, jam skirtos kategorijos. Jo turinys išbarstytas tarp Getting Started, hPanel ir Website, ir tai yra tikras atradimas visiems, kurie tikisi vieno atskiro centro, kaip kad VPS ar Email turi savo.

Paieška pagal „Web Apps“ grąžino 71 rezultatą per 8 puslapius. Pagrindiniai rezultatai buvo mišrūs: dalis tiesiogiai aktualūs, dalis tik laisvai susiję:

• How to deploy apps built with Codex on Hostinger, tiesiogiai aktualu
• Hostinger AI Builder: How to create a web app in agentic mode, artimas, bet kitas produktas
• How to add a Node.js Web App in Hostinger, tiesiogiai aktualu
• How to install Flutter Web on a VPS at Hostinger, visiškai kitas produktas
• Keli Website Builder mokėjimo metodų straipsniai (PayPal, WeChat Pay, BLIK), nesusiję, išskyrus tai, kad tekste kažkur pasitaiko žodžiai „web“ ir „app“

Atidariau vieną iš geriausių rezultatų — How to deploy apps built with Codex on Hostinger — kad įvertinčiau jo gylį. Jis pasirodė esąs išsamus, gerai struktūruotas gid’as: pradžioje nurodyti palaikomi framework’ai, pateikti žingsniai su ekrano nuotraukomis tiek GitHub importo, tiek ZIP įkėlimo keliams, skyrius apie build nustatymų konfigūravimą su pavyzdinėmis komandomis, failų struktūros po deploy apžvalga, duomenų bazės prijungimo vedlio peržiūra, pažeidžiamumų stebėjimo skyrius ir pabaigoje FAQ blokas.

Nors jis pristatomas kaip skirtas būtent Codex, po juo esanti platforma yra ta pati, kuri naudojama bendram Node.js Web App produktui, todėl didžioji dalis turinio tinka tiesiogiai.

Ką manau: Straipsnių skaičius paieškoje atrodo įspūdingai popieriuje — 71 rezultatas vienam terminui, tačiau reikšminga dalis to kiekio yra triukšmas iš nesusijusių produktų, kurie tiesiog dalijasi panašia terminologija. Vienas pilnai peržiūrėtas straipsnis kokybės požiūriu pasirodė geras: aiškūs žingsniai, tikros ekrano nuotraukos ir tikras FAQ skyrius, bet jį surasti reikėjo peršokant per rezultatus, kurie su tuo, ką norėjau deploy’inti, visai nesusiję.

Bendras klientų palaikymo verdiktas

Paprastas hostingo sprendimas moderniems web app’ams

Deployinkite React, Next.js, Vue, Node.js ir kitas modernias aplikacijas be serverių valdymo ar sudėtingos infrastruktūros.

Aplankykite Hostinger

Ar rekomenduojame Hostinger Web Apps Hosting?

Taip. Deploy procesas yra stipriausia šio produkto dalis: teisingas mano stack’o, branch’o ir Node versijos automatinis aptikimas, tikras transliuojamas build log’as vietoj sukamėlės ir gyvas app’as, kuris perėjo visus mano atliktus veikimo testus — tobuli GTmetrix įvertinimai iš dviejų skirtingų žemynų, švarus 54 taškų pasaulinis nuoseklumo patikrinimas ir sutampantys 100/100 įvertinimai iš Hostinger nuosavų įrankių tiek desktop, tiek mobile. Kodee tai papildė tiksliais, konkrečiais atsakymais į tikrus techninius klausimus, o ne bendrais scenarijaus atsakymais.

Nelygios vietos yra nedidelės, bet jas verta žinoti prieš perkant. „Managed MySQL“ planų puslapyje skamba tarsi kažkas, kas jau paruošta vos jūsų app’ui pradedant veikti, o praktiškai reiškia rankinę kūrimo formą. Dashboard’as taip pat nesuteikia Web Apps Hosting atskiro įėjimo iš pagrindinio Home ekrano — reikia žinoti, kad pirmiausia eiti į Websites.

Programuotojui, kuris nori greito, nuo framework nepriklausomo deploy’o su infrastruktūra, kuri taip gerai benchmark’inama, tai yra paprastas rekomendavimas. Jei tikitės, kad kiekviena reklamuojama funkcija bus įjungta vos pasibaigus checkout’ui, numatykite keliomis minutėmis daugiau, kad duomenų bazę susikurtumėte patys.

Hostinger

5.0

2,473 user reviews

1.42 € /mo

Pradinė kaina

Aplankykite Hostinger

Rating based on expert review

• Patogumas
  4.9
• Techninė parama
  4.9
• Funkcijos
  4.8
• Patikimumas
  4.7
• Kainos
  4.5