Hostinger izveidoja Web Apps Hosting ap vienkāršu solījumu: nospiediet savu kodu no GitHub, ZIP failu vai savu AI kodēšanas aģentu un aptuveni minūtes laikā iegūstiet dzīvu, ražošanā gatavu lietotni, bez servera, ko jums pašiem būtu jāuztur. Es gribēju noskaidrot, cik daudz no tā patiesībā atbilst realitātei, kad deploy poga ir jānospiež pašam, tāpēc lūk, ko es atklāju.

Deploy Web Apps Faster with Hostinger

Deploy modern web apps on Hostinger with automated builds, managed infrastructure, global CDN, SSL, security tools, and a 30-day money-back guarantee.

Apmeklēt Hostinger

Plusi un mīnusi

Vērtējuma sadalījums

Lai novērtētu Hostinger’s Web Apps Hosting, es piemēroju HostAdvice vērtēšanas metodoloģiju, to pašu standartizēto pieeju, ko vietnē izmanto visos apskatos, tāpēc rezultāti balstās uz reālu testēšanu, nevis mārketinga valodu. Lūk, kā tas tika novērtēts katrā parametrā.

Host Your Web Apps Without the DevOps Hassle

Deploy modern web applications on fully managed hosting with automated deployments, managed SSL, global CDN, and built-in security.

Apmeklēt Hostinger

Plāni un cenas

Hostinger pārdod Web Apps Hosting kā divus līmeņus, Business un Cloud Startup, abi ir īpaši veidoti Node.js un modernu JavaScript lietotņu izvietošanai, nevis tradicionālai vietņu veidošanai.

Cloud Startup, līmenis, ko testēju es, dubulto lietotņu limitu un CPU kodolu skaitu salīdzinājumā ar Business, un abos plānos pirmajam gadam ir iekļauts bezmaksas domēns, bezmaksas biznesa e-pasts un pārvaldīts SSL tieši noformēšanas laikā.

Dažas lietas, kas jāzina pirms pasūtīšanas:

• Naudas atmaksas garantija: Web Apps Hosting ietilpst Hostinger standarta hostinga atmaksas noteikumos — vienkāršs 30 dienu logs no iegādes datuma. Tas ir ievērojami vienkāršāk nekā Hostinger VPS plāniem, kuriem ir papildu 180 dienu nogaidīšanas periods starp atmaksas pieprasījumiem. Šeit šāds nogaidīšanas periods netiek piemērots.
• Bezmaksas izmēģinājums: Es neatradu atsevišķu bezmaksas izmēģinājumu. Jūsu izvērtēšanas logs ir 30 dienu naudas atmaksas garantija.
• Maksājumu metodes: Noformēšanā kā noklusējuma metode bija kartes maksājums ar Visa, Mastercard, Amex un Discover logotipiem, kā arī iespēja pievienot citu maksājumu metodi noformēšanas laikā.
• Kas ir iekļauts: Bezmaksas domēns uz vienu gadu, bezmaksas pastkastītes uz vienu gadu un pārvaldīts SSL ir iekļauti bez papildu maksas virs plāna cenas, tāpēc uzlīmes cena ir ļoti tuva patiesajām izmaksām, lai tiešsaistē palaistu pilnībā strādājošu un drošu izvietojumu.
• Vienīgais papildpārdošanas piedāvājums: Hostinger Reach, e-pasta mārketinga papildinājums, grozā parādās kā atsevišķs izcelts bloks ar savu ikmēneša cenu. To ir viegli izlaist, un tas netiek iekļauts komplektā vai atzīmēts pēc noklusējuma.

Ja atceļat Web Apps Hosting plānu 30 dienu laikā, Hostinger atmaksas politika apstiprina, ka tas ietilpst standarta noteikumos, nevis izņēmumu sarakstā, tāpēc vienkārša atcelšana šajā logā, visticamāk, kvalificēsies atmaksai bez papildu nosacījumiem, kas attiecas uz VPS vai domēna iegādi.

Funkcijas

• Automātiska ietvara un Node versijas noteikšana
• Pārvaldīti MySQL datubāzes izveides rīki
• Globāls CDN ir aktīvs pēc noklusējuma
• Iekļauta WAF un DDoS aizsardzība
• Dienas un pēc pieprasījuma dublējumkopijas
• Malware skeneris un ievainojamību skenēšana
• GitHub integrācija ar automātisku deploy
• Bezmaksas domēns, e-pasts un SSL
• SSH piekļuve pieredzējušiem lietotājiem

From Code to Live App with Hostinger

Connect your GitHub repository or upload your project and get it online with managed infrastructure, automatic deployments, and daily backups.

Apmeklēt Hostinger

Veiktspēja

Tā kā Web Apps Hosting ir pilnībā pārvaldīts, jums nekad nav piekļuves shell serverim, tāpēc nav iespējams tieši izmērīt CPU, RAM vai disku tā, kā to dara VPS apskatā.

To, ko var izmērīt, ir tas, cik ātri izvietotā lietotne ielādējas un atbild no reālām vietām visā pasaulē. Es to testēju no četriem dažādiem skatpunktiem: GTmetrix no diviem kontinentiem, 50+ punktu globālu konsekvences pārbaudi un Hostinger paša iebūvēto ātruma rīku gan desktop, gan mobile.

Pārbaudāmā lietotne ir Next.js izvietojums, kas aprakstīts zemāk sadaļā Lietošanas ērtums, pieejams vietnē ivory-llama-856835.hostingersite.com, darbojas uz Cloud Startup plāna (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage), ar CDN aktīvu pēc noklusējuma.

1. GTmetrix, testēts no diviem kontinentiem

Es palaidu GTmetrix divreiz no dažādām pasaules vietām, lai redzētu, vai rezultāts ir konsekvents vai labi izskatās tikai no viena veiksmes punkta.

Abi testi abās vietās uzrādīja nevainojamus 100% gan Performance, gan Structure, ar nulles layout shift un nulles blocking time abās atrašanās vietās, kas nozīmē, ka lapā nekas nekonkurēja par pārlūkprogrammas uzmanību un nekas nelēkāja ielādes laikā.

Patiešām interesantā detaļa ir tā, ka Frankfurte pat pārspēja Čikāgu visos laika mērījumos, lai gan es apzināti izvēlējos ASV servera atrašanās vietu šai lietotnei. Šis rezultāts ir saprotams tikai, ņemot vērā CDN.

Kad CDN ir aktīvs, kā tas šeit bija pēc noklusējuma, jūsu apmeklētājs ne vienmēr sasniedz origin serveri tieši.

Viņš sasniedz tuvāko kešoto edge mezglu, tāpēc Eiropas testpunkts var būt ātrāks nekā ASV punkts, pat ja īstais serveris atrodas ASV. Tas ir reāls, praktisks apliecinājums, ka Hostinger pēc noklusējuma ieslēgtais CDN patiešām dara savu darbu, nevis vienkārši pastāv kā mārketinga punkts.

2. Globālā konsekvence (Check-Host)

Es palaidu HTTP pārbaudi pret dzīvo URL no katra Check-Host piedāvātā kontrolpunkta, 54 vietām sešos kontinentos. Pilns attēls:

Katrs veiksmīgais pārbaudes rezultāts atgrieza tīru 200 OK, bez kļūdām, bez daļējām neveiksmēm, bez negaidītām pāradresācijām.

Atbildes laiki skaidri parādīja, kā CDN kešošana uzvedas reālās distances apstākļos:

Eiropas kontrolpunkti konsekventi uzrādīja ātrākos laikus, vairāki zem 50 milisekundēm, savukārt kontrolpunkti, kas fiziski atrodas vistālāk no jebkura edge mezgla, Tokija, Singapūra, Hošimina, joprojām atgrieza derīgas 200 atbildes, tikai lēnāk, 0.3 līdz 0.8 sekundžu diapazonā.

Tas ir sagaidāmais CDN atbalstīta izvietojuma raksturs: ātri pie edge mezgliem, joprojām pilnībā funkcionāls tālu no tiem.

Četri noildzes gadījumi, Kazahstānā, Rumānijā un divos no četriem Krievijas kontrolpunktiem, nav kaut kas tāds, ko es uztvertu kā Hostinger infrastruktūras problēmu.

Citi kontroles punkti tajās pašās valstīs veiksmīgi atbildēja (Sanktpēterburga atbildēja tīri ar 0.063s, kamēr divi Maskavas kontrolpunkti noildza), kas norāda uz reģionālu tīkla filtrēšanu kontrolpunkta pusē, nevis uz problēmu izvietotajā lietotnē.

3. Hostinger paša ātruma rīks, desktop un mobile

Hostinger nodrošina savu Page Speed testu tieši lietotnes panelī, tāpēc es salīdzināju tā skaitļus ar neatkarīgajiem GTmetrix rezultātiem, nevis pieņēmu kādu no tiem uzreiz par patiesību.

Abām ierīču kategorijām bija nevainojami 100, un desktop rādītāji cieši sakrīt ar to, ko neatkarīgi mērīja GTmetrix, un tas ir īstais iemesls, kāpēc jāizmanto abi rīki. Divas dažādas metodoloģijas, un tās viena ar otru saskan.

Mobile bija lēnāks visos laika rādītājos, kā jau sagaidāms simulētā lēnākā savienojumā un vājākā procesorā, taču joprojām pietiekami ātrs, lai 100 rezultāts atspoguļotu patiešām spēcīgu reālo mobile veiktspēju, nevis tikai piedodošu vērtēšanas sistēmu.

Paša rīka viena neatbilstība. Lai gan rezultāts abās ierīcēs ir tīrs 100, Diagnostics panelis zem tā joprojām atzīmē vairākas rindas ar burtisku 0 rezultātu — network dependency tree, document request latency un avoiding multiple redirects — kā arī divus elementus ar 50, unused JavaScript un legacy JavaScript.

Neviens no šiem zemajiem apakšrezultātiem nenovāca kopējo rezultātu, tāpēc uztveriet tos kā nelielas, patiešām esošas optimizācijas iespējas, nevis kā problēmu ar izvietojumu.

Atsevišķi “helpful links”, ko Hostinger rāda blakus šīm diagnostikām, visi ir rakstīti WordPress vajadzībām — “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site” — lai gan šī ir Node.js lietotne, kurā WordPress vispār nav nevienā slānī. Tas ir atlieks no koplietota diagnostikas šablona, nevis saturs, kas veidots šim produktam.

Kopējais secinājums par veiktspēju

Managed Web App Hosting by Hostinger

Focus on building your app while Hostinger takes care of deployment, infrastructure, security, SSL, backups, and global delivery.

Apmeklēt Hostinger

Lietošanas ērtums

Es testēju Hostinger Web Apps Hosting no sākumlapas līdz checkout, pēc tam no jauna konta līdz pilnībā dzīva, strādājoša Node.js izvietojuma izveidei.

Tas ietvēra plāna izvēli, maksāšanu, izvēli, kā būvēt, GitHub pieslēgšanu un build procesa vērošanu reāllaikā. Lūk, kā šis process patiesībā noritēja.

1. Reģistrācija

Es sāku Web Apps Hosting sākumlapā, kurā galvenais aicinājums ir Start deploying.

Nospiežot to, netiek atvērta reģistrācijas forma. Jūs tiekat aizritināts tieši uz leju līdz cenu sadaļai, tāpēc pirmais īstais lēmums ir, kuru plānu pirkt, nevis kādus konta datus ievadīt.

Blakus bija divi plāni:

Es izvēlējos Cloud Startup, jo tas piedāvā divreiz vairāk lietotņu un lielāku CPU rezervi nekā sākuma līmenis. Viena neliela neatbilstība, ko vērts pieminēt: cenu lapā tas saucas “Cloud Startup”, bet, kad tas nonāk grozā, tas pats plāns ir apzīmēts kā “Startup plan”. Tas nav funkcionāls trūkums, tikai nosaukuma neatbilstība starp diviem soļiem tajā pašā checkout plūsmā.

Grozs bija vienkāršs. Tajā bija uzskaitīts 48 mēnešu termiņš, ietaupījums, bezmaksas domēns uz gadu un bezmaksas pastkastes, un tad bija viens papildpārdošanas piedāvājums — Hostinger Reach e-pasta mārketings — kas atradās savā izceltā blokā, nevis bija iepriekš atzīmēts.

Es to izlaidu un bez problēmām noklikšķināju Continue.

Ja esat jauns klients, nevis esošs lietotājs, checkout šeit ievieto konta izveides soli, pirms nonākat līdz rēķina adresei un maksājuma lapai.

Tālāk jūs pievienojat rēķina adresi, izvēlaties maksājuma metodi — karti, PayPal vai kādu citu iespēju — un nosūtāt pieprasījumu. Es saņēmu pirkuma apstiprinājuma e-pastu dažu mirkļu laikā pēc Submit payment nospiešanas, pēc tam nonācu tieši hPanel, kur plāns jau bija sagatavots.

Ko es domāju: Checkout ir īss, un papildpārdošanas piedāvājumu ir viegli noraidīt, nemeklējot slēptu skip saiti. Plāna nosaukuma neatbilstība starp cenu lapu un grozu ir sīkums, taču tieši tāds sīkums, kas pirmreizējam pircējam liek apstāties un vēlreiz pārbaudīt, vai izvēlēts pareizais līmenis.

2. Panelis

Pēc maksājuma apstiprināšanas jūs nonākat hPanel, Hostinger paša izveidotajā vadības panelī, kas paredzēts visu tā produktu pārvaldībai, nevis lapā, kas būtu īpaši veidota jūsu jaunajai Web App.

Pirmā lapa, kurā jūs nonākat, ir Home, un tā ir veidota ap AI uzvedņu joslu augšpusē: “Hi, [your name]! How can I help you today?” ar teksta lauku zem tās un sešām īsceļu pogām: Get domain, Create website, Get email, Migrate site, Get VPS un Try email marketing.

Pārejot zemāk, jūs atradīsiet:

• Funkciju reklāmas flīzes AI Builder, tiešsaistes veikala rīkam, apgalvojot bezmaksas biznesa e-pastu, AI aģentus, automatizācijas lietotni un bezmaksas domēnu
• Darāmo darbu sarakstu , kas mudina pabeigt Reach iestatīšanu, saņemt bezmaksas e-pastu, saņemt bezmaksas domēnu
• Your business, visu vietņu, lietotņu un VPS instanču sarakstu, kas saistīts ar jūsu kontu, katrai ar savu Manage site pogu
• VPS, atsevišķu tabulu zemāk, kurā uzskaitītas jebkuras VPS instances pēc IP adreses, statusa un derīguma termiņa

Agent panelis arī pastāvīgi atrodas katras hPanel lapas augšējā labajā stūrī, ne tikai Home. Tas ir tas pats Kodee asistents, ko izmanto atbalstam, bet šeit tas ir izvietots kā vispārējs darbību rīks ar gatavām uzvednēm, piemēram, “Deploy my Node.js app” vai “Harden VPS updates”, ko var palaist bez pilna jautājuma rakstīšanas.

Home ir patiešām noderīgs, kad jūsu lietotne jau pastāv, viss, kas atrodas sadaļā Your business, ved tieši uz to. Taču tā nav vieta, kur izveidot jaunu Web App vai atrast Setup pogu. Tam jāiet caur citu sānu izvēlnes ceļu:

1. Sānu joslā noklikšķiniet uz Websites
2. Zem tā atveras apakšizvēlne: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Noklikšķiniet uz Web Apps

Šis klikšķis jūs aizved uz pavisam citu ekrānu nekā Home — ekrānu, kas organizēts ap jūsu faktiskajiem hostinga plāniem, nevis uzvedņu joslu.

Šeit katram jūsu īpašumā esošajam plānam ir sava karte. Manā kontā tas nozīmēja trīs vertikāli sakārtotas kartes:

Business kartē zem tās jau bija redzama dzīva lietotne no agrākiem testiem — orange-walrus-700988.hostingersite.com — ar savām Tools un Dashboard pogām.

Patiesībā tas ir noderīgi pamanīt. Tiklīdz Web App pastāv, tās kartē parādās šāda rinda, kur tieši redzama dzīva vietne, un tieši tā izskatīsies jūsu Cloud Startup karte, kad pabeigsiet iestatīšanu.

Tā kā Cloud Startup bija tikko iegādātais plāns, kuru vēl nebiju iestatījis, tā kartē bija tikai viena Setup poga. Tā ir poga, kas faktiski sāk Web App izveides vedni, un tā parādās tikai šeit, zem Websites → Web Apps, nevis Home ekrānā, kurā jūs nonākat pēc noklusējuma.

Ko es domāju: hPanel ir skaidrs, kad atrodat pareizo ekrānu, taču Web Apps Hosting nav acīmredzamas priekšējās durvis. Nonākšana Home rāda uzvedņu joslu un īsceļus, nevis ceļu uz lietotnes izveidi; jums ir jāzina, ka jānoklikšķina Websites, tad Web Apps, lai Setup vispār parādītos. Tas ir pāris lieku klikšķu produktam, kas tiek pārdots kā “live in a minute.” Taču, kad tur nonākat, plānu kartes ir skaidras un godīgi parāda statusu, un plāns ar jau darbojošos lietotni to parāda tieši kartē.

3. Lietotnes deploy

Noklikšķinot uz Setup plāna kartē, atvērās īss onboarding process: Where would you like to start? ar trim opcijām — Create a new site, Migrate an existing site vai I hired someone to build my site. Es izvēlējos Create a new site.

Tas noveda pie How do you want to build your website?, kas bija sadalīts divās iesācējiem paredzētās opcijās augšpusē, Hostinger AI Builder un WordPress + AI, un divās opcijās zem atsevišķas “for advanced users” virsraksta apakšā: Node.js web app un PHP/HTML website. Izvēloties Node.js web app, jūs faktiski nonākat pie paša Web Apps Hosting produkta.

Šī ir svarīga strukturāla piezīme ikvienam, kas salīdzina produktus: Web Apps Hosting nav sava atsevišķa reģistrācijas plūsma.

Tā ir tikai viena atzare tajā pašā vispārējā vietnes izveides vednī, ko izmanto AI Builder un WordPress.

Es noklikšķināju uz aplīša blakus Node.js web app, tad nospiedu Next.

No turienes:

• Domēna ekrāns: Es izvēlējos Use temporary domain, nevis piesaistīt īstu domēnu, jo tas bija testa izvietojums.

• Servera atrašanās vietas ekrāns: Hostinger pēc noklusējuma izvēlējās France, tuvāko reģionu manai norēķinu valstij, un rādīja 167ms latentumu. Ritinot līdz United States opcijai, tika parādīts 364ms, vairāk nekā divreiz lēnāk.

Es tik un tā izvēlējos United States, Massachusetts, un šī ir tieši tā mācība, ko katra Hostinger produkta atrašanās vietas izvēlne parāda: izvēlieties pēc tā, kur atrodas jūsu īstie apmeklētāji, nevis pēc zemākā skaitļa sarakstā.

Mana testa lietotnes paredzētā auditorija ir ASV lietotāji, tāpēc serveris ASV viņiem būs ātrāks nekā serveris Francijā, neatkarīgi no tā, ko izvēlne rādīja man no manas atrašanās vietas. Ekrānā redzamais skaitlis parāda, cik ātri serveris atbild Hostinger testam, nevis cik ātri tas atbildēs cilvēkiem, kas lietos jūsu vietni.

• Deploy metodes ekrāns: divas galvenās opcijas, Import Git repository (atzīmēts kā Recommended) vai Upload your files, plusa zem tā bija paziņojums par izvietošanu tieši no Claude Code, Cursor vai VS Code, izmantojot Hostinger Connector. Es izvēlējos Import Git repository un nospiedu Connect with GitHub.

Tas atvēra īstu GitHub pieteikšanās logu, ja jūs vēl nebijāt ielogojies, pēc tam atvēra atļauju ekrānu ar nosaukumu Install & Authorize Hostinger, kurā bija jāizvēlas starp:

• Instalāciju all repositories režīmā, kur ietilpst arī nākotnes repo, ar tikai lasīšanas piekļuvi publiskajiem repo
• Instalāciju only select repositories režīmā, kur jūs individuāli izvēlaties repo un kurā ir precīzi uzskaitītas piešķirtās atļaujas: lasīšanas piekļuve actions, metadata un repository hooks, un lasīšanas-rakstīšanas piekļuve administration, code un pull requests. Kad noklikšķināt Install & Authorize, GitHub automātiski jūs pāradresē atpakaļ uz hPanel.

Jūs nonākat lapā Select Git repository to import, ritināmā sarakstā ar visiem ar jūsu GitHub kontu saistītajiem repozitorijiem, katram ar savu Deploy pogu. Es atradu testa repozitoriju, ko biju iepriekš nosūtījis, hostadvice-webapps-test, un noklikšķināju uz Deploy blakus tam.

No klikšķa līdz nākamajai lapai pagāja gandrīz 30 sekundes bez nekāda progresa indikatora ekrānā, pietiekami ilgi, lai šķistu, ka klikšķis varbūt nav reģistrēts vispār.

Beidzot ielādētā lapa saucas Review build settings, un tā precīzi parāda, kur jūsu lietotne dzīvos, pirms jūs kaut ko apstiprināt: “Deploys to ivory-llama-856835.hostingersite.com.” Zem tā, jums nepieskaroties nevienam laukam, jau bija automātiski noteikts:

Katrai no šīm piecām rindām blakus ir sava Change vai Add poga, tāpēc šeit nekas nav bloķēts, ja noteikšana kaut ko sajauc.

Es noklikšķināju uz Add blakus Environment variables un iestatīju vienu key-value pāri, lai pārbaudītu, vai tas patiešām nonāks strādājošajā lietotnē vēlāk, pēc tam dialogā noklikšķināju Finish, un tad nospiedu galveno Deploy pogu lapas apakšā.

Build vērošana

Ekrāns pārslēdzas uz Deploying… skatu ar marķētu progresa joslu — “Deployment from GitHub” — kas virzās pa posmiem; es vēroju, kā tā sasniedz 28%, tad 51%, ceļā uz pabeigšanu. Zem progresa joslas ir salokāms Build logs panelis, un, to atverot, redzams reāls, tiešsaistē plūstošs termināļa izvads, nevis vietturis ar spinneri:

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

Deploy pabeigts

Kad build ir pabeigts, jūs nonākat ekrānā Deployment completed! ar dzīvu jūsu faktiskās lietotnes sīktēla priekšskatījumu pašā kartē, blakus kopsavilkumam ar repozitorija nosaukumu un piešķirto dzīvo URL.

No šīs lapas jūs varat tieši noklikšķināt uz Go to dashboard, kur turpmāk pārvaldāt lietotni.

Ko es domāju: Automātiskā noteikšana ir šī produkta galvenais ieguvums. Framework, branch un Node versija visi tika noteikti pareizi bez manuālas ievades, un dzīvais build žurnāls padara gaidīšanu pārredzamu, nevis noslēpumainu. Vienīgā vājā vieta ir 30 sekunžu pauze, pirms jūs vispār nonākat iestatījumu ekrānā — pietiekami ilgi, lai šķistu, ka process varbūt ir iestrēdzis, pirms tas vizuāli sākas.

4. Dzīvā deploy apstiprināšana

Pirms izpētīt pārvaldības rīkus, es gribēju pārliecināties, ka lietotne tiešām ir deployota un darbojas, nevis tikai atzīmēta kā “Completed” uz ekrāna.

No Deployment completed lapas es uzreiz noklikšķināju uz dzīvo URL, ivory-llama-856835.hostingersite.com, nevis uzticējos tikai paneļa priekšskatījuma sīktēlam.

Dzīvā lapa ielādējās un parādīja tieši to, ko lietotne bija ieprogrammēta rādīt:

• Server build time, tiešs laika zīmogs, kas apstiprina, ka lapa ir tikko būvēta, nevis pasniegta no vecas kešatmiņas
• Environment variable check, rāda pielāgoto mainīgo, ko iestatīju deploy ekrānā, un apstiprina to pareizi faktiskajā dzīvajā vietnē, nevis tikai paneļa priekšskatījumā

Tad es nospiedu pašas lietotnes pogu Ping the API route, kas izsauc dzīvu backend endpointu, nevis tikai attēlo statisku saturu. Tā atgrieza tīru JSON atbildi:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Šī atbilde ir svarīgāka, nekā varētu šķist. Lapa, kas ielādējas pareizi, tikai pierāda, ka statiskie faili ir augšupielādēti.

Strādājošs API izsaukums pierāda, ka īstais Node.js serveris darbojas zem tā un atbild uz reāliem pieprasījumiem — tā ir “Node.js web app” hostinga daļa, ko viegli izlikt ar statisku failu un grūti izlikt ar dzīvu servera laika zīmogu, kas ģenerēts tieši tad, kad nospiežat pogu.

Ko es domāju: Šī ir pārbaude, ko es ieteiktu jums veikt pirms uzticēšanās jebkuram deploy šajā platformā vai līdzīgā platformā. Zaļš “Completed” statuss un priekšskatījuma sīktēls parāda, ka build ir pabeigts. Noklikšķinot uz dzīvā URL un iedarbinot kaut ko dinamisku — API izsaukumu, datubāzes lasījumu, jebko, ko nevar viltot ar kešotu statisku lapu —, jūs redzat, ka serveris patiešām ir dzīvs un dara to, kam to uzbūvējāt.

5. Web App pārvaldība

Kad dzīva lietotne bija apstiprināta kā strādājoša, es atgriezos hPanel un izpētīju lietotnes paša pārvaldības paneli no sākuma līdz beigām — īsto servera pārvaldības slāni šim produktam, kas ir atsevišķs no vispārējā hPanel Home ekrāna, par kuru jau runāju iepriekš.

Paneļa pārskats. Brīdī, kad šeit nonākat, četras statusa emblēmas uzreiz parāda situāciju:

Visas četras pēc noklusējuma bija zaļas, neko man nevajadzēja ieslēgt manuāli. Zem tās ir Last deployment kartīte, kas apstiprina statusu, repozitoriju, autoru, commit, deploy laiku, noteikto steku un Node versiju — visu, ko gribētos ātri pārbaudīt, neiedziļinoties žurnālos.

Automātisks Page Speed test jau bija palaists pret dzīvo vietni un atgrieza 99/100 Desktop rezultātu bez manuālas iesaistes, blakus tam bija Essentials panelis ar ātrām saitēm uz datubāzes savienojumu, backupiem, failu pārvaldnieku, runtime žurnāliem un kešatmiņu.

Deploys, vides mainīgie un žurnāli. Šo tēmu aptver trīs atsevišķas lapas:

• Deployments saglabāja pilnu ierakstu par push, autoru, branch, commit hash un pabeigšanas statusu — īstu vēsturi, nevis tikai jaunāko ierakstu
• Environment variables pareizi uzrādīja mainīgo, ko iestatīju deploy laikā, apstiprinot, ka tas ir saglabāts un piemērots, nevis tikai vienreiz parādīts iestatīšanas laikā un pēc tam aizmirsts
• Runtime logs straumēja tiešsaistes servera izvadi, Next.js starta rindas, gatavības laika zīmogus un nepārtrauktu problēmu un kļūdu skaitu, kas visu laiku, kamēr skatījos, palika nulle un nulle

Drošība. Malware Scanner atgrieza tīru rezultātu — “Your website is safe” — ar vienu skaidri pateiktu piebildi: tas pārbauda tikai vietnes failus, nevis datubāzes saturu, un ir pieejama maksas tīrīšanas opcija, ja vēlaties dziļāku pārbaudi, kas ietver arī datubāzi. Vulnerabilities skenēšana arī atgriezās tīra.

Datubāzes. Šeit produkta mārketings rada reālu plaisu, kas jums ir jāsaprot pirms pirkuma. Plāns reklamē managed MySQL kā galveno funkciju, taču nekas netiek automātiski sagatavots jums.

Databases sadaļa atveras ar manuālu Create a New MySQL Database And Database User formu, kas nozīmē, ka datubāze jānosauc un jāizveido jums pašam, pirms lietotne to var izmantot. Es to tieši apstiprināju ar Kodee, par ko stāstīts Atbalsta sadaļā zemāk, un atbilde bija tieša: managed nozīmē, ka Hostinger uztur datubāzes infrastruktūru aizkulisēs, nevis to, ka datubāze tiek izveidota jums automātiski brīdī, kad lietotne nonāk tiešsaistē.

Uzlabotā piekļuve. SSH piekļuve ir pieejama sadaļā Advanced ar IP, portu un lietotājvārdu, taču pēc noklusējuma tā ir Inactive un ir manuāli jāaktivizē ar Enable klikšķi, lai to varētu izmantot. File Manager piedāvā izvēli starp tikai šīs lietotnes failu pārlūkošanu vai visu failu pārlūkošanu visā hostinga plānā.

Ko es domāju: Ikdienas panelis ir pārdomāts un labi organizēts. Īpaši drošība un deploy vēsture ir viegli atrodami un patiešām informatīvi, un nulles kļūdu runtime žurnāls kopā ar tīru malware skenēšanu man deva īstu pārliecību, ka lietotne ir vesela, ne tikai tiešsaistē.

Viena vieta, kur saskarne pārsola vairāk, nekā reāli dod, ir datubāzes sadaļa, kur “managed MySQL” plāna lapā izklausās kā kaut kas, kas gaida jūs uzreiz, kad lietotne nonāk tiešsaistē, bet praksē tas ir manuāls izveides formulis, vienkāršs lietošanā, taču solis, kas jums jāveic pašiem.

Kopējais secinājums par lietošanas ērtumu

Build, Deploy, and Scale with Hostinger

Host modern web apps with GitHub integration, managed MySQL, global CDN, unlimited bandwidth, and built-in security tools.

Apmeklēt Hostinger

Atbalsta līmenis

Es pārbaudīju Hostinger atbalstu Web Apps Hosting caur Kodee — AI asistentu, kas iebūvēts hPanel — un pēc tam apskatīju zināšanu bāzi, lai redzētu, cik daudz tā aptver bez nepieciešamības kaut ko jautāt cilvēkam. Kodee parādās divās vietās, kuras ir vērts nošķirt: kā Ask AI publiskajā mārketinga vietnē un kā Agent panelis jebkurā hPanel lapā, tostarp tieši pašas Web App panelī.

1. AI atbalsts (Kodee)

Es uzdevu divus jautājumus, kas balstīti uz reālām nepilnībām, ko biju atradis testēšanas laikā, nevis uz vispārīgiem vaicājumiem, uz kuriem Kodee varētu atbildēt, tikai citējot dokumentāciju.

1. jautājums pārbaudīja deploy kļūmes uzvedību un vides mainīgo iestatīšanas laiku — reālas ražošanas problēmas ikvienam, kas šajā platformā izvieto lietotni:

If my app’s build fails partway through a GitHub deployment, does the app revert to the last successful version automatically, or does it go down until I fix and redeploy? And can I set custom environment variables before the first deploy, or only after?

Kodee atbildēja tieši un pareizi uz abiem jautājuma aspektiem. Ja build neizdodas, tas neaizstāj pašlaik darbojošos lietotni; ja iepriekšējais deploy ir bijis veiksmīgs, lietotne turpina darboties uz pēdējās strādājošās versijas. Ja tas ir pirmais deploy un nav uz ko atgriezties, lietotne paliek nepieejama, līdz build tiek izlabots un atkārtoti izvietots — skaidra, godīga atbilde, nevis miglaina mierināšana.

Par vides mainīgajiem tas apstiprināja, ka tos var iestatīt pirms pirmā deploy iestatījumos, un jau strādājošai lietotnei tas izklāstīja precīzus trīs soļus: atveriet Settings un Redeploy, pievienojiet vai rediģējiet mainīgos sadaļā Environment variables, saglabājiet un veiciet redeploy.

2. jautājums nospieda uz abām nepilnībām, ko biju pamanījis panelī: “managed MySQL” formulējumu pret manuālo izveides formu un SSH, kas pēc noklusējuma bija neaktīvs:

This plan advertises managed MySQL, but the dashboard shows a manual ‘Create a New MySQL Database’ form rather than a database provisioned automatically. Is a database created for every Web App by default, or only if I create one myself? Also, SSH access is listed as available but shows as Inactive by default. If I never enable it, does that change anything about how my app actually runs, or is SSH purely an optional extra for advanced users?

Kodee atbilde apstiprināja tieši to, ko biju redzējis saskarnē, nevis maigāku versiju. Datubāze netiek izveidota automātiski katrai Web App; “managed” nozīmē, ka Hostinger uztur datubāzes servisu un infrastruktūru, bet faktiskas datubāzes izveide un konfigurēšana ir jūsu ziņā, izmantojot to pašu Create a New MySQL Database ekrānu, ko jau biju redzējis, un pēc tam pašam jāpievieno savienojuma detaļas lietotnes vides mainīgajos.

Par SSH tas apstiprināja, ka atstāšana to neaktīvu neko nemaina lietotnes darbībā, deploy procesā vai savienojumā ar datubāzi. Tas ir pozicionēts tikai kā izvēles rīks CLI komandām, migrācijām vai tiešai failu atkļūdošanai, nevis kaut kas, uz ko platforma klusām paļaujas fonā.

Ko es domāju: Abas atbildes sakrita ar to, ko jau biju pārbaudījis manuāli panelī, nevis to pretrunīgi vai mīkstināti izskaidroja, un tas liecina par atbalsta rīku, kas patiešām pārbauda produkta reālo stāvokli, nevis lasa scenāriju no lapas. Neviens no šiem jautājumiem nebija atbildams ar copy-paste no vispārīga FAQ, un Kodee abas reizes tika galā ar specifiskām, strukturētām, divdaļīgām atbildēm apmēram minūtes laikā.

2. Zināšanu bāze

Hostinger zināšanu bāze atveras kā kategoriju režģis ar 20 kategorijām kopā, katrā redzams rakstu skaits. Dažas no lielākajām: AI Builder ar 330 rakstiem, VPS ar 276, Email ar 127 un Website ar 103.

Web Apps Hosting nesaņem savu atsevišķu kategoriju. Tās saturs ir izkaisīts starp Getting Started, hPanel un Website, un tas ir reāls secinājums ikvienam, kas sagaida vienu atsevišķu centru, kādu saņem VPS vai Email.

Meklējot “Web Apps” tieši, tika atrasti 71 rezultāts 8 lapās. Galvenie rezultāti bija dažādu tipu — gan tieši saistīti, gan tikai attāli saistīti:

• How to deploy apps built with Codex on Hostinger, tieši saistīts
• Hostinger AI Builder: How to create a web app in agentic mode, līdzīgs, bet citam produktam
• How to add a Node.js Web App in Hostinger, tieši saistīts
• How to install Flutter Web on a VPS at Hostinger, pilnīgi citam produktam
• Vairāki Website Builder maksājumu metožu raksti (PayPal, WeChat Pay, BLIK), nesaistīti, izņemot to, ka tekstā kaut kur parādās vārdi “web” un “app”

Es atvēru vienu no galvenajiem rezultātiem, How to deploy apps built with Codex on Hostinger, lai pārbaudītu tā dziļumu. Tas izrādījās pamatīgs, labi strukturēts ceļvedis ar atbalstītajām platformām sākumā, soli pa solim ekrānattēliem gan GitHub importēšanas, gan ZIP augšupielādes ceļiem, sadaļu par build iestatīšanu ar piemēru komandām, failu struktūras aprakstu pēc deploy, datubāzes savienojuma vedņa pārskatu, ievainojamību monitoringa sadaļu un noslēdzošu FAQ bloku.

Lai gan tas ir ietverts kā ceļvedis par Codex specifiski, pamatā tā ir tā pati platforma, kas aiz vispārīgā Node.js Web App produkta, tāpēc lielākā daļa attiecas tieši.

Ko es domāju: Rakstu skaits meklēšanā izskatās spēcīgs uz papīra — 71 rezultāts vienam terminam —, taču būtiska daļa šī apjoma ir troksnis no nesaistītiem produktiem, kuriem vienkārši ir līdzīgi vārdi. Vienīgais raksts, ko atvēru pilnībā, bija kvalitatīvs: skaidri soļi, īsti ekrānattēli un patiess FAQ. Taču to atrast vajadzēja, pāršķirstot rezultātus, kuriem nebija nekāda sakara ar to, ko es patiesībā mēģināju deployot.

Kopējais secinājums par klientu atbalstu

Simple Hosting for Modern Web Apps

Deploy React, Next.js, Vue, Node.js, and other modern applications without managing servers or complex infrastructure.

Apmeklēt Hostinger

Vai mēs iesakām Hostinger Web Apps Hosting?

Jā. Deploy process ir šī produkta spēcīgākā daļa: precīza mana steka, branch un Node versijas automātiska noteikšana, īsts straumējošs build žurnāls spinnera vietā un dzīva lietotne, kas izturēja katru veiktspējas testu, ko tai metos pretī — nevainojami GTmetrix rezultāti no diviem dažādiem kontinentiem, tīra 54 punktu globālā konsekvences pārbaude un saskaņoti 100/100 rezultāti Hostinger paša rīkos gan desktop, gan mobile. Kodee to visu papildināja ar precīzām, konkrētām atbildēm uz reāliem tehniskiem jautājumiem, nevis ar vispārīgām skripta frāzēm.

Nelielās nepilnības ir mazas, bet vērts tās zināt pirms pirkuma. “Managed MySQL” plāna lapā izklausās kā kaut kas gatavs uzreiz, kad jūsu lietotne nonāk tiešsaistē, bet praksē tas nozīmē manuālu izveides formu. Panelim Web Apps Hosting nav arī acīmredzamas ieejas no galvenā Home ekrāna — jums jāzina, ka jāatver Websites.

Ja esat izstrādātājs, kurš vēlas ātru, no ietvara neatkarīgu deploy uz infrastruktūras, kas tik labi veic etalontestus, šo ir viegli ieteikt. Ja jūs sagaidāt, ka katra reklamētā funkcija būs ieslēgta tajā pašā brīdī, kad beidzas checkout, ieplānojiet dažas papildu minūtes datubāzes manuālai iestatīšanai.

Hostinger

5.0

2,471 user reviews

€1,37 /mo

Sākumcena

Apmeklēt Hostinger

Rating based on expert review

• Lietotājiem draudzīgs
  4.9
• Atbalsts
  4.9
• Iespējas
  4.8
• Uzticamība
  4.7
• Cenas
  4.5