Hostinger rakensi Web Apps Hosting -palvelun yksinkertaisen lupauksen ympärille: työnnä koodisi GitHubista, ZIP-tiedostosta tai tekoälykoodaajaasi käyttämällä, ja saat tuotantovalmiin sovelluksen käyntiin noin minuutissa ilman, että sinun tarvitsee hallita palvelinta. Halusin selvittää, kuinka paljon tästä pitää oikeasti paikkansa, kun olet itse klikkaamassa käyttöönottoa, joten tässä on se, mitä löysin.

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.

Vieraile sivustolla Hostinger

Hyvät ja huonot puolet

Arvioinnin erittely

Arvioidakseni Hostingerin Web Apps Hostingin sovelsin HostAdvicen arviointimetodologiaa, samaa standardoitua lähestymistapaa, jota käytetään sivuston jokaisessa arviossa, jotta pisteet pysyvät todelliseen testaukseen, eivät markkinointikieleen, perustuvina. Tässä on, miten se suoriutui kussakin parametrissa.

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.

Vieraile sivustolla Hostinger

Suunnitelmat ja hinnoittelu

Hostinger myy Web Apps Hostingia kahtena tasona, Business ja Cloud Startup, jotka molemmat on rakennettu erityisesti Node.js- ja modernien JavaScript-sovellusten käyttöönottoa varten perinteisen sivustonrakennuksen sijaan.

Cloud Startup, taso jota testasin, kaksinkertaistaa sovelluskiintiön ja CPU-ytimien määrän Businessiin verrattuna, ja molemmat suunnitelmat sisältävät ilmaisen domainin, ilmaisen yrityssähköpostin ja hallitun SSL:n ensimmäiseksi vuodeksi suoraan kassalla.

Muutama asia, jotka on hyvä tietää ennen tilaamista:

• Rahat takaisin -takuu: Web Apps Hosting kuuluu Hostingerin tavallisten hosting-hyvitysehtojen piiriin, eli 30 päivän ikkuna ostopäivästä alkaen. Tämä on huomattavasti yksinkertaisempi kuin Hostingerin VPS-suunnitelmissa, joihin sisältyy lisäksi 180 päivän jäähtymisaika hyvityspyyntöjen välillä. Sellaista jäähtymisaikaa ei sovelleta tässä.
• Ilmainen kokeilu: En löytänyt erillistä ilmaista kokeilua. 30 päivän rahat takaisin -takuu toimii arviointijaksonasi.
• Maksutavat: Kassalla korttimaksu näkyi oletusvaihtoehtona, Visa-, Mastercard-, Amex- ja Discover-logot esitettyinä, sekä vaihtoehto lisätä toinen maksutapa kassalla.
• Mitä sisältyy: Ilmainen domain vuodeksi, ilmaiset postilaatikot vuodeksi ja hallittu SSL sisältyvät kaikki ilman lisäkustannusta suunnitelman hintaan, joten listahinta on lähellä todellista hintaa sille, että saat täysin toimivan ja suojatun käyttöönoton liveksi.
• Ainoa lisämyynti: Hostinger Reach, sähköpostimarkkinoinnin lisäosa, näkyy ostoskorissa omana korostettuna laatikkonaan erillisellä kuukausihinnalla. Se on helppo ohittaa, eikä sitä ole oletuksena valittu tai niputettu mukaan.

Jos peruutat Web Apps Hosting -suunnitelman 30 päivän kuluessa, Hostingerin hyvityskäytäntö vahvistaa, että se kuuluu tavallisten ehtojen piiriin eikä poissulkulistaan, joten peruutus tuon ajan sisällä pitäisi oikeuttaa hyvitykseen ilman VPS- tai domain-ostoksiin liittyviä lisäehtoja.

Ominaisuudet

• Frameworkin ja Node-version automaattinen tunnistus
• Hallitut MySQL-tietokannan luontityökalut
• Globaali CDN aktiivisena oletuksena
• WAF- ja DDoS-suojaus mukana
• Päivittäiset ja tarvittaessa otettavat varmuuskopiot
• Malware scanner ja haavoittuvuuksien skannaus
• GitHub-integraatio automaattisella käyttöönotolla
• Ilmainen domain, sähköposti ja SSL
• SSH-yhteys edistyneille käyttäjille

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.

Vieraile sivustolla Hostinger

Suorituskyky

Koska Web Apps Hosting on täysin hallittu, et koskaan saa shell-yhteyttä palvelimeen, joten et voi benchmarkata CPU:ta, RAM-muistia tai levyä samalla tavalla kuin VPS-arviossa.

Voit mitata sitä, kuinka nopeasti käyttöönotettu sovellus itse latautuu ja vastaa, todellisista sijainneista ympäri maailmaa. Testasin tätä neljästä eri kulmasta: GTmetrixillä kahdelta mantereelta, yli 50 pisteen globaalilla johdonmukaisuustarkistuksella sekä Hostingerin omalla sisäänrakennetulla nopeustyökalulla sekä työpöydällä että mobiilissa.

Testin alla oleva sovellus on alla olevan Käytön helppous -osion kattama Next.js-käyttöönotto, live-osoitteessa ivory-llama-856835.hostingersite.com, joka toimii Cloud Startup -suunnitelmalla (4 CPU-ydintä, 4096 MB RAM, 100 GB NVMe-tallennustilaa), CDN aktiivisena oletuksena.

1. GTmetrix, testattu kahdelta mantereelta

Ajoin GTmetrixin kahdesti eri puolilta maailmaa nähdäkseni, pysyikö tulos johdonmukaisena vai näyttikö se hyvältä vain yhdestä onnekkaasta näkökulmasta.

Molemmat ajot päätyivät täydelliseen 100%:iin sekä Performance- että Structure-pisteissä, nollalla layout shiftillä ja nollalla blocking time -ajalla kummassakin sijainnissa, mikä tarkoittaa, ettei mikään sivulla kilpaillut selaimen huomiosta tai hypähtänyt latauksen aikana.

Oikeasti kiinnostava yksityiskohta on, että Frankfurt päihitti Chicagon kaikissa ajoitusmittareissa, vaikka valitsin tarkoituksella yhdysvaltalaisen palvelinsijainnin tälle sovellukselle. Tulos käy järkeen vain CDN:n valossa.

Kun CDN on aktiivinen, kuten se oli tässä oletuksena, kävijäsi ei välttämättä yhdistä suoraan alkuperäiseen palvelimeen.

He yhdistävät lähimpään välimuistissa olevaan reunasolmuun, joten eurooppalainen testipiste voi päätyä nopeammaksi kuin yhdysvaltalainen, vaikka varsinainen palvelin sijaitsee Yhdysvalloissa. Tämä on todellinen, käytännöllinen vahvistus siitä, että Hostingerin oletuksena päälle kytketty CDN tekee oikeaa työtä eikä vain ole markkinointiväite.

2. Globaali johdonmukaisuus (Check-Host)

Ajoin HTTP-tarkistuksen elävää URL-osoitetta vastaan kaikista Check-Hostin tarjoamista tarkistuspisteistä, 54 sijaintia kuudella mantereella. Koko kuva:

Jokainen onnistunut tarkistus palautti siistin 200 OK -vastauksen, ei virheitä, ei osittaisia epäonnistumisia, ei odottamattomia uudelleenohjauksia.

Vasteajat kertoivat selkeän tarinan siitä, miten CDN-välimuisti toimii todellisilla etäisyyksillä:

Eurooppalaiset tarkistuspisteet palauttivat johdonmukaisesti nopeimmat ajat, useat alle 50 millisekunnissa, kun taas maantieteellisesti kaukaisimmat tarkistuspisteet, Tokio, Singapore, Ho Chi Minh City, palauttivat edelleen kelvolliset 200-vastaukset, vain hitaampina, 0.3–0.8 sekunnin alueella.

Se on odotettu muoto CDN-pohjaiselle käyttöönotolle: nopea reunojen lähellä, edelleen täysin toimiva kaukana niistä.

Neljää aikakatkaisua, Kazakstanissa, Romaniassa ja kahdessa neljästä Venäjän tarkistuspisteestä, en pitäisi merkkinä Hostingerin infrastruktuuriongelmasta.

Muut saman maiden tarkistuspisteet onnistuivat (Pietari vastasi puhtaasti 0.063s:ssa, kun taas kaksi Moskovan tarkistuspistettä aikakatkaistiin), mikä viittaa alueelliseen verkkosuodatukseen tarkistuspisteen puolella eikä mihinkään ongelmaan käyttöönotetussa sovelluksessa.

3. Hostingerin oma nopeustyökalu, työpöytä ja mobiili

Hostinger ajaa oman Page Speed -testinsä suoraan sovelluksen hallintapaneelissa, joten vertasin sen lukuja riippumattomiin GTmetrix-tuloksiin sen sijaan, että olisin luottanut kumpaankaan yksin sellaisenaan.

Molemmat laitteistotyypit saivat täydet 100 pistettä, ja desktop-luvut vastaavat läheisesti sitä, mitä GTmetrix mittasi itsenäisesti, mikä on koko pointti kahden työkalun ajamisessa. Kaksi eri työkalua, kaksi eri metodologiaa, ja ne ovat samaa mieltä keskenään.

Mobiili oli hitaampi kaikissa ajoitusmittareissa, kuten odotettua simuloidulla hitaammalla yhteydellä ja heikommalla prosessorilla, mutta silti riittävän nopea, että 100 pisteen tulos kuvastaa aidosti vahvaa mobiilisuorituskykyä, ei vain löyhää arviointiasteikkoa.

Yksi epäjohdonmukaisuus itse työkalussa. Vaikka piste on siisti 100 molemmilla laitteilla, sen alla oleva Diagnostics-paneeli merkitsee silti muutaman rivikohdan kirjaimellisella 0-pisteellä, network dependency tree, document request latency ja avoiding multiple redirects, sekä kaksi kohtaa, jotka on pisteytetty 50: unused JavaScript ja legacy JavaScript.

Mitkään näistä matalista alipisteistä eivät pudottaneet kokonaispisteitä, joten pidä niitä pieninä, aidosti olemassa olevina optimointimahdollisuuksina, etkä merkkinä siitä, että käyttöönotossa olisi jotain vialla.

Erikseen “helpful links”, joita Hostinger näyttää näiden diagnostiikkatietojen vieressä, on kaikki kirjoitettu WordPressiä varten, “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, vaikka kyseessä on Node.js-sovellus, jossa WordPressiä ei ole missään osassa pinoa. Se on peräisin yhteisestä diagnostiikkamallipohjasta eikä tälle tuotteelle tehdyistä sisällöistä.

Kokonaisarvio suorituskyvystä

Managed Web App Hosting by Hostinger

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

Vieraile sivustolla Hostinger

Käytön helppous

Testasin Hostingerin Web Apps Hostingia aloitussivulta kassalle asti ja sitten kylmästä tilistä täysin liveen, toimivaan Node.js-käyttöönottoon.

Tämä kattoi suunnitelman valinnan, maksamisen, rakennustavan valinnan, GitHubin yhdistämisen ja buildin valmistumisen seuraamisen reaaliajassa. Tässä on, millainen tuo prosessi oikeasti oli.

1. Rekisteröityminen

Aloitin Web Apps Hosting -aloitussivulta, jossa on yksi toimintakehote: Start deploying.

Sen klikkaaminen ei avaa rekisteröintilomaketta. Se vierittää sinut suoraan alas hinnoitteluosioon, joten ensimmäinen todellinen päätös on, minkä suunnitelman ostat, ei mitä tilitietoja täytät.

Kaksi suunnitelmaa oli vierekkäin:

Valitsin Cloud Startupin, koska se tarjoaa kaksinkertaisen sovelluskiintiön ja enemmän CPU-päätilaa lähtötasoon verrattuna. Yksi pieni epäjohdonmukaisuus täällä: hinnoittelusivu kutsuu sitä “Cloud Startupiksi”, mutta kun se päätyy ostoskoriin, sama suunnitelma on nimetty “Startup planiksi”. Ei toiminnallinen ongelma, vain nimiero kahden saman kassavirran näytön välillä.

Ostoskori itsessään oli siisti. Siinä listattiin 48 kuukauden jakso, säästöt, ilmainen domain vuodeksi ja ilmaiset postilaatikot, ja sitten tarjottiin yksi lisämyynti, Hostinger Reach -sähköpostimarkkinointi, omassa korostetussa laatikossaan eikä valmiiksi valittuna.

Ohitin sen ja jatkoin Continue-painikkeella ilman kitkaa.

Jos olet uusi asiakas etkä olemassa oleva, kassavaihe lisää tähän tilin luontivaiheen ennen kuin pääset laskutusosoitteeseen ja maksusivulle.

Seuraavaksi lisäät laskutusosoitteen, valitset maksutavan, kortin, PayPalin tai jonkin muun vaihtoehdon, ja lähetät maksun. Sain ostovahvistussähköpostin muutaman hetken kuluttua Submit paymentin klikkaamisesta, ja sitten päädyin suoraan hPaneliin, jossa suunnitelma oli jo provisionoitu.

Oma arvioni: Kassa on lyhyt ja lisämyynti on helppo ohittaa ilman, että pitää etsiä piilotettua ohituslinkkiä. Suunnitelmien nimeämisen epäjohdonmukaisuus hinnoittelusivun ja ostoskorin välillä on pieni asia, mutta juuri sellainen yksityiskohta, joka saa ensikertalaisen pysähtymään ja varmistamaan, että valitsi oikean tason.

2. Hallintapaneeli

Kun maksu on mennyt läpi, päädyt hPaneliin, Hostingerin omaan hallintapaneeliin, jonka se on rakentanut kaikkien myymiensä tuotteiden hallintaan, ei sivulle, joka olisi tehty erityisesti uuden Web App -sovelluksesi ympärille.

Sivu, jolle päädyt ensimmäisenä, on Home, ja se rakentuu yläosan AI-kehoterivin ympärille: “Hi, [your name]! How can I help you today?” tekstikentällä sen alla ja kuudella pikapainikkeella: Get domain, Create website, Get email, Migrate site, Get VPS ja Try email marketing.

Kun vierität tämän ohi, löydät:

• Ominaisuusmainospaneelit AI Builderille, verkkokauppatyökalulle, jotka lupaavat ilmaisen yrityssähköpostin, AI agentsin, automaatiosovelluksen ja ilmaisen domainin
• To-do-listan, joka ohjaa sinua kohti asetustehtäviä, Reachin viimeistelyä, ilmaisen sähköpostin lunastamista, ilmaisen domainin lunastamista
• Your business, jatkuvan luettelon kaikista tiliisi liitetyistä sivustoista, sovelluksista ja VPS-instansseista, joista jokaisessa on oma Manage site -painike
• VPS, erillisen taulukon alempana, jossa listataan mahdolliset VPS-instanssit IP-osoitteen, tilan ja päättymispäivän mukaan

Agent -paneeli näkyy myös pysyvästi kaikkien hPanel-sivujen oikeassa yläkulmassa, ei vain Home-sivulla. Se on sama Kodee-avustaja, jota käytetään tuessa, mutta tässä se on sijoitettu yleiseksi toimintatyökaluksi valmiine kehotteineen kuten “Deploy my Node.js app” tai “Harden VPS updates”, joita voit käyttää ilman koko kysymyksen kirjoittamista.

Home on aidosti hyödyllinen sitten, kun sovelluksesi on jo olemassa, kaikki Your business -kohdan asiat linkittävät suoraan siihen. Mutta se ei ole paikka, jossa luot uuden Web Appin tai jossa Setup-painike on. Sitä varten sinun täytyy käyttää eri reittiä sivupalkissa:

1. Klikkaa vasemmassa sivupalkissa kohtaa Websites
2. Sen alle avautuu alavalikko: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Klikkaa kohtaa Web Apps

Tuo klikkaus vie sinut aivan eri näyttöön kuin Home, näyttöön, joka on järjestetty todellisten hosting-suunnitelmiesi ympärille eikä kehoterivin.

Täällä jokainen omistamasi suunnitelma saa oman korttinsa. Tililläni se tarkoitti kolmea korttia päällekkäin:

Business -kortissa oli myös jo aiemmasta testauksesta peräisin oleva live-sovellus, orange-walrus-700988.hostingersite.com, omine Tools- ja Dashboard-painikkeineen.

Se on itsessään hyödyllinen huomio. Kun Web App on olemassa, sen korttiin ilmestyy tällainen rivi, joka näyttää live-sivuston suoraan, ja juuri siltä Cloud Startup -korttisi näyttää, kun viimeistelet asetukset.

Koska Cloud Startup oli juuri ostamani suunnitelma, jota en ollut vielä ottanut käyttöön, sen kortissa näkyi sen sijaan vain Setup -painike. Se on painike, joka todella käynnistää Web Appin luontivelhon, ja se ilmestyy vain täällä, Websites → Web Apps -kohdassa, ei Home-näytössä, jolle päädyt oletuksena.

Oma arvioni: hPanel on selkeä, kun löydät oikean näytön, mutta Web Apps Hostingilla ei ole selkeää etuovea. Homeen päätyminen näyttää kehoterivin ja pikavalinnat, ei polkua sovelluksen luontiin, sinun täytyy tietää klikata Websitesiin ja sitten Web Appsiin ennen kuin Setup edes ilmestyy. Se on pari ylimääräistä klikkausta tuotteelle, jota myydään lupauksella “live in a minute.” Kun olet siellä, suunnitelmakortit ovat kuitenkin siistit ja rehelliset tilasta, ja kortti näyttää jo käynnissä olevan sovelluksen suoraan siinä.

3. Sovelluksen käyttöönotto

Setup -painikkeen klikkaaminen suunnitelmakortissa avasi lyhyen perehdytyksen: Where would you like to start? , jossa oli kolme vaihtoehtoa, Create a new site, Migrate an existing site tai I hired someone to build my site. Valitsin Create a new site.

Se johti kohtaan How do you want to build your website?, joka oli jaettu kahteen aloittelijaystävälliseen vaihtoehtoon ylhäällä, Hostinger AI Builder ja WordPress + AI, sekä kahteen vaihtoehtoon erillisen “for advanced users” -otsikon alla: Node.js web app ja PHP/HTML website. Node.js web appin valitseminen on se, mikä todella vie sinut Web Apps Hosting -tuotteeseen.

Tämä on aito rakenteellinen huomio kaikille, jotka vertaavat tuotteita: Web Apps Hostingilla ei ole omaa erillistä rekisteröitymisprosessia.

Se on yksi haara samassa yleisessä sivuston luontivelhossa, jota käytetään AI Builderille ja WordPressille.

Valitsin ympyrän kohdan Node.js web app vierestä ja klikkasin sitten Next.

Sen jälkeen:

• Domain-näyttö: valitsin Use temporary domain -vaihtoehdon enkä sitoutunut oikeaan domainiin, koska kyseessä oli testikäyttöönotto.

• Palvelinsijainnin näyttö: Hostinger valitsi oletuksena Ranskan, lähimmän alueen laskutusmaahani nähden, ja näytti siinä 167ms viiveen. Yhdysvaltain vaihtoehtoon vierittäminen näytti 364ms, yli kaksinkertaisen määrän.

Valitsin kuitenkin United States, Massachusettsin, ja juuri tämä on se oppi, jonka sijaintivalitsin opettaa jokaisessa Hostingerin tuotteessa: valitse sen perusteella, missä oikeat kävijäsi ovat, ei sen mukaan, mikä näyttää omasta sijainnistasi pienimmän numeron.

Testisovellukseni tarkoitettu yleisö on Yhdysvalloissa, joten palvelin Yhdysvalloissa palvelee heitä oikeasti nopeammin kuin palvelin Ranskassa koskaan voisi, riippumatta siitä, mitä valitsin näytti minulle omasta sijainnistani. Näytön numero kertoo, kuinka nopeasti palvelin vastaa Hostingerin testiin, ei kuinka nopeasti se vastaa ihmisille, jotka todella käyttävät sivustoasi.

• Käyttöönoton tapa: kaksi ensisijaista vaihtoehtoa, Import Git repository (merkitty Recommended) tai Upload your files, sekä alempana huomautus suorasta käyttöönotosta Claude Coden, Cursorin tai VS Coden kautta Hostinger Connectorilla. Valitsin Import Git repositoryn ja klikkasin Connect with GitHub.

Se avasi oikean GitHub-kirjautumisikkunan, jos et ollut jo kirjautunut sisään, ja sitten käyttöoikeussivun nimeltä Install & Authorize Hostinger, jossa pyydettiin valitsemaan joko:

• Asentaminen kaikkiin repositorioihin, jotka omistat, mukaan lukien tulevat repositoriosi, vain lukuoikeudella julkisiin repositorioihin
• Asentaminen vain valittuihin repositorioihin, jotka valitset yksitellen, ja jossa listattiin tarkasti myönnettävät oikeudet: lukuoikeus actionsiin, metadataan ja repository hookeihin, sekä luku- ja kirjoitusoikeus administrationiin, codeen ja pull requesteihin. Kun klikkaat Install & Authorize, GitHub ohjaa sinut automaattisesti takaisin hPaneliin.

Päädyt kohtaan Select Git repository to import, vieritettävään listaan kaikista GitHub-tiliisi liitetyistä repositorioista, joista jokaisen vieressä on Deploy-painike. Löysin testirepositorion, jonka olin aiemmin puskenut, hostadvice-webapps-test, ja klikkasin sen vieressä Deploy.

Tuon painikkeen klikkaamisesta kesti lähes 30 sekuntia ilman näkyvää etenemismittaria ennen kuin seuraava sivu latautui, niin kauan, että saatat miettiä, rekisteröityikö klikkaus lainkaan.

Vihdoin latautuva sivu on nimeltään Review build settings, ja se kertoo tarkasti, mihin sovelluksesi sijoittuu ennen kuin sitoudut mihinkään: “Deploys to ivory-llama-856835.hostingersite.com.” Alla, koskematta yhteenkään kenttään, se oli jo tunnistanut automaattisesti:

Jokaisella näistä viidestä rivistä on oma Change – tai Add -painikkeensa, joten mikään tässä ei ole lukittu, jos tunnistus menee pieleen.

Klikkasin Add -painiketta ympäristömuuttujien vierestä ja asetin yhden avain-arvoparin varmistaakseni, että se todella päätyisi toimivaan sovellukseen myöhemmin, ja klikasin sitten dialogin Finish , ja sitten pääikkunan Deploy -painiketta alareunasta.

Buildin seuraaminen

Näyttö vaihtuu Deploying… -näkymään, jossa on nimetty edistymispalkki, “Deployment from GitHub”, joka etenee vaiheittain; katselin sen nousevan 28%:iin, sitten 51%:iin, matkalla kohti valmistumista. Edistymispalkin alla on avattava Build logs -paneeli, ja sen avaaminen näyttää reaaliaikaista terminaalitulostetta sitä mukaa kuin se tapahtuu, ei mitään paikkamerkki-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 …

Käyttöönotto valmis

Kun build päättyy, päädyt Deployment completed! -näyttöön, jossa on live-esikatselukuva todellisesta käynnissä olevasta sovelluksestasi suoraan kortissa, sekä yhteenveto, jossa näkyvät repositorion nimi ja annettu live-osoite.

Tältä sivulta voit klikata suoraan kohtaan Go to dashboard, jossa hallitset sovellusta tästä eteenpäin.

Oma arvioni: Automaattinen tunnistus on tässä kohokohta. Framework, branch ja Node-versio tunnistettiin oikein ilman yhtäkään manuaalista kenttää, ja live build-loki tekee odotuksesta läpinäkyvää opaslaman sijaan. Heikko kohta on se 30 sekunnin tauko ennen kuin edes saavutetaan asetussivu, niin pitkä, että saatat miettiä, jumittuiko jokin ennen kuin prosessi näkyvästi alkaa.

4. Live-käyttöönoton vahvistaminen

Ennen kuin tutkin mitään hallintatyökaluista, halusin varmistaa, että sovellus oli todella otettu käyttöön ja toimi, eikä vain merkitty “Completed” näytölle.

Deployment completed -sivulta klikkasin suoraan live-URL-osoitteeseen, ivory-llama-856835.hostingersite.com, sen sijaan että olisin luottanut vain hallintapaneelin esikatselukuvaan.

Live-sivu latautui ja näytti juuri sen, mitä sovellus oli koodattu näyttämään:

• Server build time, live-aikaleima, joka vahvistaa sivun rakentuneen juuri hetki sitten, ei vanhasta välimuistista
• Ympäristömuuttujan tarkistus, joka näytti mukautetun muuttujan, jonka olin asettanut käyttöönoton aikana, vahvistettuna oikein oikealla live-sivulla, ei vain hallintapaneelin esikatselussa

Sen jälkeen klikkasin sovelluksen omaa Ping the API route -painiketta, joka kutsuu live-backend-päätepistettä eikä vain renderöi staattista sisältöä. Se palautti siistin JSON-vastauksen:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Tuo vastaus on tärkeämpi kuin miltä se ehkä näyttää. Sivun latautuminen oikein todistaa vain, että staattiset tiedostot on ladattu.

Toimiva API-kutsu todistaa, että itse Node.js-palvelin toimii taustalla ja vastaa oikeisiin pyyntöihin, se osa “Node.js web app” -hostingia, jota on helppo teeskennellä staattisella tiedostolla ja vaikea teeskennellä elävällä palvelinaikaleimalla, joka tuotetaan juuri sillä hetkellä, kun painat nappia.

Oma arvioni: Tämä on tarkistus, jota suosittelisin ennen kuin luotat mihinkään käyttöönottoon tällä alustalla tai millä tahansa vastaavalla alustalla. Vihreä “Completed” -tila ja esikatselukuva kertovat, että build valmistui. Klikkaamalla suoraan live-URL:iin ja käynnistämällä jotain dynaamista, API-kutsun, tietokantahauun, mitä tahansa, mitä ei voi teeskennellä välimuistiin tallennetulla staattisella sivulla, kerrot, että palvelin on oikeasti elossa ja tekee sitä, mitä rakensit sen tekemään.

5. Web Appin hallinta

Kun live-sovellus oli varmistettu toimivaksi, palasin hPaneliin ja tutkin sovelluksen oman hallintapaneelin läpikotaisin, tämän tuotteen varsinaisen palvelinhallintakerroksen, joka on erillinen aiemmin käsitellystä yleisestä hPanel Home -näytöstä.

Hallintapaneelin yleiskuva. Heti kun saavut tänne, neljä tilamerkkiä kertovat tilanteen yhdellä silmäyksellä:

Kaikki neljä olivat oletuksena vihreitä ilman, että minun tarvitsi kytkeä mitään päälle manuaalisesti. Tämän alapuolella on Last deployment -kortti, joka vahvistaa tilan, repositorion, tekijän, commitin, käyttöönottoajan, tunnistetun pinon ja Node-version, kaiken mitä haluat tarkistaa yhdellä silmäyksellä ilman lokien kaivamista.

Automaattinen Page Speed -testi oli jo ajettu live-sivua vastaan itsenäisesti ja palautti 99/100 Desktop-pisteet ilman, että käynnistin sitä itse, ja sen vieressä oli Essentials -paneeli pikavalinnoilla tietokantayhteyteen, varmuuskopioihin, tiedostonhallintaan, runtime-lokeihin ja välimuistiin.

Käyttöönotot, ympäristömuuttujat ja lokit. Kolme erillistä sivua kattaa tämän:

• Deployments säilytti täydellisen historian pushista, tekijästä, branchista, commit-hajusta ja valmistumistilasta, todellisen historian eikä vain viimeisintä
• Environment variables listasi oikein muuttujan, jonka olin asettanut käyttöönoton aikana, vahvistaen, että se tallennettiin ja otettiin käyttöön, ei vain näytetty kerran asetuksen aikana ja unohdettu
• Runtime logs virrattivat elävää palvelimen tulostetta sitä mukaa kuin se tapahtui, Next.js:n käynnistysrivejä, ready-aikaleimoja ja juoksevaa ongelmien ja virheiden laskuria, joka pysyi nollassa ja nollassa koko ajan, kun katsoin

Tietoturva. Malware Scanner palautti puhtaan tuloksen, “Your website is safe”, yhdellä selkeästi mainitulla varauksella: se tarkistaa vain verkkosivun tiedostot, ei tietokannan sisältöä, ja tarjolla on maksullinen puhdistusvaihtoehto, jos haluat syvemmän tarkistuksen, joka sisältää myös tietokannan. Vulnerabilities -skannauskin palautui puhtaana.

Tietokannat. Tässä tuotteen oma markkinointi luo todellisen aukon, joka sinun kannattaa ymmärtää ennen ostamista. Suunnitelma mainostaa hallittua MySQL:ää kärkiominaisuutena, mutta mikään ei luoda sinulle automaattisesti.

Databases-osa avautuu manuaalisella Create a New MySQL Database And Database User -lomakkeella, mikä tarkoittaa, että nimeät ja luot tietokannan itse ennen kuin sovelluksesi voi käyttää sitä. Vahvistin tämän suoraan Kodeelta, kuten Support-osiossa alla kerrotaan, ja vastaus oli suora: hallittu tarkoittaa, että Hostinger pyörittää tietokantainfrastruktuuria taustalla, ei sitä, että tietokanta luotaisiin sinulle heti, kun sovelluksesi menee liveksi.

Edistynyt käyttö. SSH-yhteys löytyy Advanced-kohdasta, IP-osoitteineen, portteineen ja käyttäjänimineen, mutta se on oletuksena Inactive ja vaatii manuaalisen Enable-klikkauksen ennen kuin voit käyttää sitä. File Manager tarjoaa valinnan tämän sovelluksen tiedostojen ja koko hosting-suunnitelman kaikkien tiedostojen selaamisen välillä.

Oma arvioni: Päivittäinen hallintapaneeli on kattava ja hyvin järjestetty. Erityisesti tietoturva ja käyttöönottohistoria ovat helposti löydettävissä ja todella informatiivisia, ja nolla-virheinen runtime-loki yhdessä puhtaan malware-skannauksen kanssa antoi minulle oikeasti luottamusta siihen, että sovellus on terve, ei vain verkossa.

Ainoa kohta, jossa käyttöliittymä liioittelee, on tietokantaosio, jossa “managed MySQL” kuulostaa suunnitelmasivulla siltä, että se olisi valmiina käytettäväksi heti, kun sovellus menee liveksi, mutta käytännössä saat manuaalisen luontilomakkeen, joka on helppokäyttöinen, mutta askel, joka sinun täytyy tehdä itse.

Kokonaisarvio käytön helppoudesta

Build, Deploy, and Scale with Hostinger

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

Vieraile sivustolla Hostinger

Tuen taso

Testasin Hostingerin tukea Web Apps Hostingille Kodeen kautta, joka on hPaneliin rakennettu tekoälyavustaja, ja kävin sitten läpi tietopohjan nähdäkseni, kuinka paljon se kattaa ilman, että tarvitsee kysyä keneltäkään. Kodee näkyy kahdessa paikassa, jotka kannattaa erottaa toisistaan: julkisella markkinointisivustolla Ask AI -kohtana ja hPanelin sisällä kaikilta sivuilta saatavilla olevana Agent -paneelina, myös suoraan Web Appin omalla hallintapaneelilla.

1. Tekoälytuki (Kodee)

Kysyin kaksi kysymystä, jotka perustuivat todellisiin puutteisiin, joita olin löytänyt testauksen aikana, enkä yleisiin hakuaiheisiin, joihin Kodee voisi vastata kopioimalla dokumentaatiosta.

Kysymys 1 testasi epäonnistuneen käyttöönoton toimintaa ja ympäristömuuttujien ajoitusta, molemmat todellisia tuotantohuolia kaikille, jotka toimittavat tälle alustalle:

Jos sovellukseni build epäonnistuu kesken GitHub-käyttöönoton, palaako sovellus automaattisesti viimeiseen onnistuneeseen versioon vai putoaako se pois päältä, kunnes korjaan ja otan sen uudelleen käyttöön? Ja voinko asettaa mukautettuja ympäristömuuttujia ennen ensimmäistä käyttöönottoa vai vasta sen jälkeen?

Kodee vastasi suoraan ja oikein molempiin kohtiin. Epäonnistunut build ei korvaa jo käynnissä olevaa sovellusta; jos aiempi käyttöönotto on onnistunut, sovellus jatkaa viimeisen toimivan version tarjoamista. Jos kyseessä on ensimmäinen käyttöönotto eikä varaversiota ole, sovellus pysyy alhaalla, kunnes build on korjattu ja otettu uudelleen käyttöön, mikä on selkeä ja rehellinen vastaus eikä mitään epämääräistä rauhoittelua.

Ympäristömuuttujien osalta se vahvisti, että voit asettaa ne ennen ensimmäistä käyttöönottoa asetusvaihtoehdoissa, ja jo käynnissä olevalle sovellukselle se kävi läpi täsmälleen kolme vaihetta: avaa Settings ja Redeploy, lisää tai muokkaa muuttujia kohdassa Environment variables, tallenna ja ota uudelleen käyttöön.

Kysymys 2 pureutui kahteen puutteeseen, jotka olin itse havainnut hallintapaneelia selatessa, “managed MySQL” -muotoiluun verrattuna manuaaliseen luontilomakkeeseen sekä SSH:n oletuksena inaktiiviseen tilaan:

Tämä suunnitelma mainostaa hallittua MySQL:ää, mutta hallintapaneeli näyttää manuaalisen ‘Create a New MySQL Database’ -lomakkeen sen sijaan, että tietokanta olisi luotuna automaattisesti. Luodaanko jokaiselle Web Appille tietokanta oletuksena vai vain jos luon sellaisen itse? Lisäksi SSH-yhteys on listattu saataville, mutta se näkyy oletuksena Inactive-tilassa. Jos en koskaan ota sitä käyttöön, muuttaako se mitään siihen, miten sovellukseni oikeasti toimii, vai onko SSH vain valinnainen lisä edistyneille käyttäjille?

Kodeen vastaus vahvisti täsmälleen sen, minkä olin löytänyt käyttöliittymästä, ei pehmeämpää versiota siitä. Tietokantaa ei luoda automaattisesti jokaiselle Web Appille; “managed” viittaa siihen, että Hostinger pyörittää tietokantapalvelua ja infrastruktuuria, kun taas varsinainen tietokannan luominen ja konfigurointi on sinun vastuullasi, saman Create a New MySQL Database -näytön kautta, minkä jälkeen lisäät yhteystiedot sovelluksesi ympäristömuuttujiin itse.

SSH:n kohdalla se vahvisti, että sen jättäminen inaktiiviseksi ei muuta mitään siitä, miten sovellus toimii, ottaa käyttöön tai yhdistää tietokantaan. Se on asetettu puhtaasti valinnaiseksi työkaluksi CLI-komennoille, migraatioille tai suoraan tiedostojen debuggaamiseen, ei millekään, johon alusta hiljaisesti nojaa taustalla.

Oma arvioni: Molemmat vastaukset vastasivat sitä, minkä olin jo varmistanut käsin hallintapaneelista, sen sijaan että ne olisivat ristiriidassa sen kanssa tai pehmentäneet sitä, mikä on merkki siitä, että tukityökalu tarkistaa oikeaa tuotteen tilaa eikä toista käsikirjoitusta. Kumpaakaan kysymystä ei voinut vastata kopioimalla tavallisesta UKK:sta, ja Kodee hoiti molemmat tarkasti, rakenteellisesti ja kahdessa osassa noin minuutissa kumpikin.

2. Tietopohja

Hostingerin tietopohja avautuu kategorisoidulla ruudukolla, yhteensä 20 kategoriaa, joista jokainen näyttää artikkelimäärän. Muutamia suurimmista: AI Builderissä on 330 artikkelia, VPS:ssä 276, Emailissa 127 ja Website-kategoriassa 103.

Web Apps Hosting ei saa omaa erillistä kategoriaansa. Sen sisältö on ripoteltu Getting Started-, hPanel- ja Website-osioihin, mikä on oikea havainto kaikille, jotka odottavat yhden, omistetun kotipesän samalla tavalla kuin VPS tai Email saavat.

Hakusana “Web Apps” palautti suoraan 71 tulosta 8 sivulla. Ylimmät tulokset olivat sekoitus suoraan relevantteja ja vain löyhästi aiheeseen liittyviä sisältöjä:

• How to deploy apps built with Codex on Hostinger, suoraan relevantti
• Hostinger AI Builder: How to create a web app in agentic mode, läheinen mutta eri tuote
• How to add a Node.js Web App in Hostinger, suoraan relevantti
• How to install Flutter Web on a VPS at Hostinger, aivan eri tuote
• Useita Website Builder -maksutapa-artikkeleita (PayPal, WeChat Pay, BLIK), eivät liity asiaan muuten kuin että niissä esiintyvät sanat “web” ja “app” jossain tekstissä

Avasin yhden kärkituloksista, How to deploy apps built with Codex on Hostinger, tarkistaakseni sen syvyyden. Se osoittautui perusteelliseksi, hyvin jäsennellyksi ohjeeksi, jossa oli alussa listatut tuetut frameworkit, vaihe vaiheelta etenevät kuvakaappaukset sekä GitHub-tuonti- että ZIP-latauspoluista, osio build-asetusten konfiguroinnista esimerkkikomentoineen, läpikäynti tiedostorakenteesta käyttöönoton jälkeen, tietokantayhteyden ohjattu vaiheistus, haavoittuvuuksien valvonta -osio ja lopussa UKK-lohko.

Vaikka se on kehystetty erityisesti Codexin ympärille, taustalla oleva alusta on sama kuin yleisen Node.js Web App -tuotteen, joten suurin osa siitä pätee suoraan.

Oma arvioni: Hakutulosten määrä näyttää paperilla vahvalta, 71 osumaa yhdelle hakusanalle, mutta merkittävä osa siitä on kohinaa, joka tulee epäolennaisista tuotteista, joissa on samankaltaista sanastoa. Yksi täysimittaisena avaamani artikkeli piti tasonsa hyvin, selkeät vaiheet, oikeat kuvakaappaukset ja aito UKK-osa, mutta sen löytäminen vaati selaamista tulosten ohi, joilla ei ollut mitään tekemistä sen kanssa, mitä yritin oikeasti ottaa käyttöön.

Kokonaisarvio asiakastuesta

Simple Hosting for Modern Web Apps

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

Vieraile sivustolla Hostinger

Suosittelemmeko Hostinger Web Apps Hostingia?

Kyllä. Käyttöönottoprosessi on tämän tuotteen vahvin osa: pinon, branchin ja Node-version oikea automaattinen tunnistus, oikea reaaliaikainen build-loki spinnerin sijaan sekä live-sovellus, joka läpäisi kaikki sille heittämäni suorituskykytestit, täydelliset GTmetrix-pisteet kahdelta eri mantereelta, puhdas 54 pisteen globaali johdonmukaisuustarkistus ja Hostingerin oman työkalun vastaavat 100/100-pisteet sekä työpöydällä että mobiilissa. Kodee tuki tätä tarkalla, spesifillä vastauksella todellisiin teknisiin kysymyksiin eikä yleisillä käsikirjoitusvastauksilla.

Karkeudet ovat pieniä mutta hyvä tietää ennen ostamista. “Managed MySQL” näyttää suunnitelmasivulla siltä, että tietokanta olisi valmis heti, kun sovelluksesi menee liveksi, ja käytännössä se tarkoittaa manuaalista luontilomaketta. Myös hallintapaneeli antaa Web Apps Hostingille ilman selkeää sisäänkäyntiä pääHome-näytöltä, sinun täytyy tietää mennä ensin Websitesiin.

Jos olet kehittäjä, joka haluaa nopean, framework-riippumattoman käyttöönoton infrastruktuurilla, joka benchmarkeissa pärjää näin hyvin, tämä on helppo suositus. Jos taas odotat, että kaikki mainostetut ominaisuudet ovat päällä heti kassalta poistumisen jälkeen, varaa muutama lisäminuutti tietokannan manuaaliseen asetukseen.

Hostinger

5.0

2,471 käyttäjäarvostelua

1,37 € /mo

Aloitushinta

Vieraile sivustolla Hostinger

Rating based on expert review

• Käytettävyys
  4.9
• Tuki
  4.9
• Ominaisuudet
  4.8
• Luotettavuus
  4.7
• Hinnoittelu
  4.5