Hostinger bygde Web Apps Hosting  rundt en enkel idé: push koden din fra GitHub, en ZIP-fil eller AI-kodeagenten din, og få en live, produksjonsklar app i gang på omtrent ett minutt, uten at du trenger å administrere noen server. Jeg ville finne ut hvor mye av dette som faktisk stemmer når det er du som klikker på deploy, så her er det jeg fant.

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.

Besøk Hostinger

Fordeler og ulemper

Vurderingsfordeling

For å gi Hostinger’s Web Apps Hosting poeng, brukte jeg HostAdvice sin vurderingsmetodikk, den samme standardiserte tilnærmingen som brukes på tvers av alle anmeldelser på nettstedet, slik at poengsummene forblir forankret i reell testing fremfor markedsføring. Her er hvordan den skåret på hver parameter.

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.

Besøk Hostinger

Planer og priser

Hostinger selger Web Apps Hosting som to nivåer, Business og Cloud Startup, begge bygget spesielt for å distribuere Node.js- og moderne JavaScript-apper, i stedet for tradisjonell nettsidebygging.

Cloud Startup, nivået jeg testet, dobler app-tillatt og CPU-kjerner over Business, og begge planene inkluderer gratis domene, gratis bedrifts-e-post og administrert SSL det første året direkte i kassen.

Noen ting du bør vite før du bestiller:

• Pengene-tilbake-garanti: Web Apps Hosting omfattes av Hostinger sine standard refusjonsvilkår, et enkelt 30-dagers vindu fra kjøpsdatoen. Dette er betydelig enklere enn det som gjelder for Hostinger sine VPS-planer, som har en ekstra 180-dagers avkjølingsperiode mellom refusjonskrav. Ingen slik avkjølingsperiode gjelder her.
• Gratis prøveperiode: Jeg fant ingen dedikert gratis prøveperiode. Den 30-dagers pengene-tilbake-garantien er evalueringsvinduet ditt i stedet.
• Betalingsmetoder: Kassen viste kortbetaling som standardmetode, med Visa, Mastercard, Amex og Discover-logoer, samt et alternativ for å legge til en annen betalingsmetode i kassen.
• Hva som er inkludert: Et gratis domene i ett år, gratis e-postkontoer i ett år og administrert SSL er alle inkludert uten ekstra kostnad på toppen av planprisen, så listeprisen er nær den reelle kostnaden for å få en fullt fungerende, sikret deploy live.
• Det eneste tillegget: Hostinger Reach, et e-postmarkedsførings-tillegg, vises i handlekurven som en egen uthevet boks med en separat månedspris. Det er enkelt å hoppe over og blir verken pakket inn eller forhåndsvalgt som standard.

Hvis du kansellerer en Web Apps Hosting-plan innen 30 dager, bekrefter Hostinger sin refusjonspolicy at den faller under standardvilkårene, så en enkel kansellering innen det vinduet bør kvalifisere for refusjon uten de ekstra betingelsene som gjelder VPS- eller domenekjøp.

Funksjoner

• Automatisk oppdagelse av rammeverk og Node-versjon
• Verktøy for opprettelse av administrert MySQL-database
• Global CDN aktivert som standard
• WAF- og DDoS-beskyttelse inkludert
• Daglige og manuelle sikkerhetskopier
• Malware-skanner og sårbarhetsskanning
• GitHub-integrasjon med auto-deploy
• Gratis domene, e-post og SSL
• SSH-tilgang for avanserte brukere

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.

Besøk Hostinger

Ytelse

Siden Web Apps Hosting er fullt administrert, får du aldri shell-tilgang til en server, så det finnes ingen CPU, RAM eller disk å benchmarke direkte på samme måte som i en VPS-anmeldelse.

Det du kan måle er hvor raskt den deployede appen faktisk lastes inn og svarer, fra ekte steder rundt om i verden. Jeg testet dette fra fire ulike vinkler: GTmetrix fra to kontinenter, en global konsistenssjekk med mer enn 50 punkter, og Hostinger sitt eget innebygde hastighetsverktøy for både desktop og mobil.

Appen som ble testet er Next.js-deployen omtalt i delen om Brukervennlighet nedenfor, live på ivory-llama-856835.hostingersite.com, kjørende på Cloud Startup-planen (4 CPU-kjerner, 4096 MB RAM, 100 GB NVMe-lagring), med CDN aktivert som standard.

1. GTmetrix, testet fra to kontinenter

Jeg kjørte GTmetrix to ganger fra ulike deler av verden for å se om resultatet holdt seg stabilt eller bare så bra ut fra én heldig vinkel.

Begge kjøringene landet på perfekte 100% både for Performance og Structure, med null layout shift og null blocking time på begge steder, noe som betyr at ingenting på siden konkurrerte om nettleserens oppmerksomhet eller hoppet rundt under innlasting.

Den virkelig interessante detaljen er at Frankfurt faktisk slo Chicago på alle tidsmålinger, selv om jeg bevisst valgte en amerikansk serverlokasjon for denne appen. Det gir bare mening i lys av CDN-et.

Når et CDN er aktivt, slik det var her som standard, trenger ikke besøkende dine å nå origin-serveren direkte.

De når nærmeste cachede edge-node, så et europeisk testpunkt kan ende opp raskere enn et amerikansk, selv om den faktiske serveren ligger i USA. Dette er en reell, praktisk bekreftelse på at Hostinger sitt CDN som standard er slått på og faktisk gjør en nyttig jobb, i stedet for bare å være en markedsføringsbullet.

2. Global konsistens (Check-Host)

Jeg kjørte en HTTP-sjekk mot den live URL-en fra hvert kontrollpunkt Check-Host tilbyr, 54 steder fordelt på seks kontinenter. Det fulle bildet:

Hver vellykkede sjekk returnerte en ren 200 OK, ingen feil, ingen delvise feil, ingen uventede omdirigeringer.

Responstidene fortalte en tydelig historie om hvordan CDN-caching oppfører seg over reelle avstander:

Europeiske kontrollpunkter ga konsekvent de raskeste tidene, flere under 50 millisekunder, mens kontrollpunkter fysisk lengst unna en edge-node, Tokyo, Singapore, Ho Chi Minh-byen, fortsatt ga gyldige 200-svar, bare saktere, i området 0.3 til 0.8 sekunder.

Det er den forventede formen for en CDN-basert deploy: rask nær kantene, fortsatt fullt fungerende langt unna dem.

De fire timeoutsene, Kasakhstan, Romania og to av de fire russiske kontrollpunktene, er ikke noe jeg ville lest som et problem med Hostinger sin infrastruktur.

Andre kontrollpunkter i de samme landene lyktes (Saint Petersburg kom tilbake rent på 0.063s mens to Moskva-kontrollpunkter timet ut), noe som peker på regional nettverksfiltrering på kontrollpunktets side heller enn noe galt med den deployede appen.

3. Hostinger sitt eget hastighetsverktøy, desktop og mobil

Hostinger kjører sin egen Page Speed-test rett inne i app-dashboardet, så jeg sammenlignet tallene med de uavhengige GTmetrix-resultatene i stedet for å ta noen av dem for god fisk alene.

Begge enhetstyper fikk en perfekt 100, og desktop-tallene ligger tett opp mot det GTmetrix uavhengig målte, noe som er hele poenget med å kjøre begge. To forskjellige verktøy, to forskjellige metoder, og de er enige med hverandre.

Mobil kom inn tregere på alle tidsmålinger, som forventet på en simulert tregere forbindelse og svakere prosessor, men fortsatt rask nok til at en 100-score reflekterer genuint sterk mobil ytelse i praksis, ikke bare en raus vurderingsskala.

Én inkonsistens i selve verktøyet. Selv om scoren er en ren 100 på begge enheter, flagger Diagnostics-panelet under det fortsatt noen linjeposter med en bokstavelig 0-score, network dependency tree, document request latency og avoiding multiple redirects, sammen med to poster scoret 50, unused JavaScript og legacy JavaScript.

Ingen av disse lave underpoengene dro ned hovedscoren, så se på dem som mindre, reelt eksisterende optimaliseringsmuligheter snarere enn noe galt med deployen.

I tillegg er “helpful links” Hostinger viser ved siden av disse diagnostikkene, alle skrevet for WordPress, “Speed up WordPress in 9 easy steps,” “How to optimize images for your WordPress site”, selv om dette er en Node.js-app uten WordPress involvert noe sted i stacken. Det er en rest fra en delt diagnostikkmal, ikke innhold laget for dette produktet.

Samlet vurdering av ytelsen

Managed Web App Hosting by Hostinger

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

Besøk Hostinger

Brukervennlighet

Jeg testet Hostinger sin Web Apps Hosting fra landingssiden og gjennom kassen, og deretter fra en tom konto til en fullt live, fungerende Node.js-deploy.

Det dekket valg av plan, betaling, valg av byggemåte, tilkobling til GitHub og å se byggingen fullføre i sanntid. Her er hvordan den prosessen faktisk var.

1. Registrering

Jeg startet på landingssiden for Web Apps Hosting, som leder med én call to action: Start deploying.

Å klikke på den åpner ikke et registreringsskjema. Den scroller deg rett ned til prisdelen, så den første reelle avgjørelsen du tar er hvilken plan du skal kjøpe, ikke hvilke kontodetaljer du skal fylle inn.

To planer sto side ved side:

Jeg valgte Cloud Startup for dobbel app-tillatelse og CPU-hodekapasitet over inngangsnivået. Én liten inkonsistens å merke seg her: pris-siden kaller den “Cloud Startup”, men når den havner i handlekurven, er samme plan merket “Startup plan”. Ikke et funksjonelt problem, bare et navneskifte mellom to skjermer i samme utsjekksflyt.

Handlekurven var ren. Den listet 48-månedersperioden, besparelsen, et gratis domene i ett år og gratis e-postkontoer, og tilbød deretter ett tillegg, Hostinger Reach e-postmarkedsføring, i sin egen uthevede boks i stedet for å være forhåndsvalgt.

Jeg hoppet over det og klikket Continue uten friksjon.

Hvis du er en ny kunde i stedet for en eksisterende, legger kassen inn et steg for opprettelse av konto her før du kommer til fakturaadresse- og betalingssiden.

Deretter legger du inn fakturaadresse, velger betalingsmetode, kort, PayPal eller en av de andre alternativene, og sender inn. Jeg fikk en kjøpsbekreftelses-e-post i løpet av noen øyeblikk etter å ha klikket Send betaling, og landet deretter direkte i hPanel med planen allerede klargjort.

Hva jeg syntes: Kassen er kort og tillegget er lett å avvise uten å måtte lete etter en skjult hopp over-lenke. Plan-navneforskjellen mellom prissiden og handlekurven er en liten ting, men det er den typen detalj som får en førstegangskjøper til å stoppe opp og dobbeltsjekke at de valgte riktig nivå.

2. Dashboard

Når betalingen din går gjennom, havner du i hPanel, Hostinger sitt eget kontrollpanel som det bygde for å håndtere alle produktene det selger, ikke en side laget spesielt rundt din nye Web App.

Siden du lander på først er Home, og den er bygget rundt en AI-promptlinje øverst: “Hi, [your name]! How can I help you today?” med et tekstfelt under og seks snarveisknapper: Get domain, Create website, Get email, Migrate site, Get VPS og Try email marketing.

Scroller du forbi det, finner du:

• Promoteringsfliser for AI Builder, nettbutikkverktøyet, gratis bedrifts-e-post, AI-agenter, en automasjonsapp, og krav om gratis domene
• En to-do-sjekkliste som dytter deg mot oppsettoppgaver, fullføre Reach-oppsett, kreve gratis e-post, kreve gratis domene
• Your business, en løpende liste over alle nettsteder, apper og VPS-instanser knyttet til kontoen din, hver med sin egen Manage site knapp
• VPS, en separat tabell lenger ned som viser eventuelle VPS-instanser etter IP-adresse, status og utløpsdato

Et Agent -panel sitter også permanent i øverste høyre hjørne på alle hPanel-sider, ikke bare Home. Det er samme Kodee-assistent som brukes til support, men plassert her som et generelt handlingsverktøy med ferdige prompts som “Deploy my Node.js app” eller “Harden VPS updates” som du kan starte uten å skrive et fullt spørsmål selv.

Home er faktisk nyttig når appen din allerede eksisterer, alt i Your business lenker rett til den. Men det er ikke stedet du går for å opprette en ny Web App eller nå Setup-knappen. For det trenger du en annen vei gjennom sidepanelet:

1. Klikk Websites i venstre sidepanel
2. En undermeny utvides under det: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Klikk Web Apps

Det klikket tar deg til en helt annen skjerm enn Home, en som er organisert rundt dine faktiske hostingplaner i stedet for en promptlinje.

Her får hver plan du eier sitt eget kort. På min konto betydde det tre kort stablet vertikalt:

Business -kortet hadde også allerede en live app oppført under seg fra tidligere testing, orange-walrus-700988.hostingersite.com, med sine egne Tools- og Dashboard-knapper.

Det er verdt å merke seg i seg selv. Når en Web App først finnes, vokser kortet dens med en rad som dette som viser den live siden direkte, og det er akkurat slik Cloud Startup-kortet ditt vil se ut når du er ferdig med oppsettet.

Siden Cloud Startup var planen jeg nettopp hadde kjøpt og ikke satt opp ennå, viste kortet bare en Setup -knapp i stedet. Det er knappen som faktisk starter opprettelsesveiviseren for Web App, og den vises bare her, under Websites → Web Apps, ikke fra Home-skjermen du lander på som standard.

Hva jeg syntes: hPanel er tydelig når du først finner riktig skjerm, men Web Apps Hosting har ingen åpenbar inngangsdør. Å lande på Home gir deg en promptlinje og snarveier, ikke en vei til å opprette en app, du må vite at du skal klikke Websites, deretter Web Apps, før Setup i det hele tatt vises. Det er noen ekstra klikk for et produkt som markedsføres som “live på et minutt”. Når du først er der, er plan-kortene derimot rene og ærlige om status, og en plan med en app som allerede kjører viser det rett på kortet.

3. Deploying the App

Å klikke Setup på plan-kortet åpnet en kort onboarding-flyt: Where would you like to start? med tre alternativer, Create a new site, Migrate an existing site, eller I hired someone to build my site. Jeg valgte Create a new site.

Det førte til How do you want to build your website?, delt inn i to nybegynnervennlige alternativer øverst, Hostinger AI Builder og WordPress + AI, og to alternativer under en egen “for advanced users”-overskrift nederst: Node.js web app og PHP/HTML website. Å velge Node.js web app er det som faktisk setter deg på Web Apps Hosting-produktet.

Dette er en reell strukturell observasjon for alle som sammenligner produkter: Web Apps Hosting har ikke sin egen dedikerte registreringsflyt.

Det er én gren inne i den samme generelle nettstedopprettingsveiviseren som brukes for AI Builder og WordPress.

Jeg klikket sirkelen ved siden av Node.js web app, og klikket deretter Next.

Derfra:

• Domene-skjerm: Jeg valgte Use temporary domain i stedet for å forplikte meg til et ekte domene, siden dette var en testdeploy.

• Serverlokasjons-skjerm: Hostinger hadde forhåndsvalgt Frankrike, den nærmeste regionen til mitt faktureringsland, og viste 167ms latens. Når jeg scrollet til USA-alternativet, viste det 364ms, mer enn dobbelt så mye.

Jeg valgte USA, Massachusetts likevel, og dette er den nøyaktige leksjonen lokasjonsvelgeren lærer deg på hvert Hostinger-produkt: velg basert på hvor de faktiske besøkende dine er, ikke det laveste tallet i listen.

Målgruppen for testappen min er basert i USA, så en server i USA vil faktisk betjene dem raskere enn en server i Frankrike noen gang kunne, uansett hva velgeren viste meg fra min egen plassering. Tallet på skjermen forteller deg hvor raskt serveren svarer Hostinger sin test, ikke hvor raskt den vil svare menneskene som faktisk skal bruke siden din.

• Deploy-metode-skjerm: to primære alternativer, Import Git repository (merket Recommended) eller Upload your files, pluss en callout under for å deploye direkte fra Claude Code, Cursor eller VS Code gjennom Hostinger Connector. Jeg valgte Import Git repository og klikket Connect with GitHub.

Det åpnet et ekte GitHub-innloggingsvindu hvis du ikke allerede var logget inn, deretter en tillatelsesskjerm med tittelen Install & Authorize Hostinger, som ba deg velge mellom:

• Å installere på all repositories du eier, inkludert fremtidige, med skrivebeskyttet tilgang til offentlige repos
• Å installere på only select repositories du velger individuelt og liste opp de nøyaktige tillatelsene som gis: lesetilgang til actions, metadata og repository hooks, og lese- og skrivetilgang til administration, code og pull requests. Når du klikker Install & Authorize, videresender GitHub deg automatisk tilbake til hPanel.

Du lander på Select Git repository to import, en rullbar liste over hvert repo knyttet til GitHub-kontoen din, hvert med sin egen Deploy-knapp ved siden av. Jeg fant testrepoet jeg hadde pushet tidligere, hostadvice-webapps-test, og klikket Deploy ved siden av det.

Fra jeg klikket på den knappen, tok det nesten 30 sekunder uten noen fremdriftsindikator på skjermen før neste side lastet, lenge nok til at du kunne lure på om klikket i det hele tatt ble registrert.

Siden som endelig lastes er med tittelen Review build settings, og den forteller deg nøyaktig hvor appen din vil leve før du bekrefter noe som helst: “Deploys to ivory-llama-856835.hostingersite.com.” Under dette, uten at du rørte et eneste felt, hadde den allerede automatisk oppdaget:

Hver av disse fem radene har sin egen Change – eller Add -knapp ved siden av seg, så ingenting her er låst hvis oppdagelsen skulle ta feil.

Jeg klikket Add ved siden av Environment variables og satte ett nøkkel-verdi-par for å bekrefte at det faktisk ville nå den kjørende appen senere, deretter klikket jeg Finish i den dialogen, og deretter klikket jeg hovedknappen Deploy nederst på siden.

Se på byggingen

Skjermen bytter til en Deploying… visning med en merket fremdriftslinje, “Deployment from GitHub”, som øker i tydelige steg; jeg så den gå gjennom 28%, deretter 51%, på vei mot fullføring. Under fremdriftslinjen ligger et sammenleggbart panel for Build logs, og når det utvides viser det ekte, live terminalutdata mens det skjer, ikke en plassholder-spinner:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Deploy fullført

Når byggingen er ferdig, lander du på en Deployment completed! -skjerm med en live miniatyrforhåndsvisning av den faktiske appen din rendret rett der i kortet, ved siden av et sammendrag som viser repository-navnet og den tildelte live URL-en.

Fra denne siden kan du klikke rett videre til Go to dashboard, som er stedet du administrerer appen videre.

Hva jeg syntes: Auto-oppdagelsen er det som skiller seg ut her. Rammeverk, branch og Node-versjon ble alle riktig uten ett eneste manuelt felt, og den live byggeloggen gjør ventingen transparent i stedet for uklar. Det ene svake punktet er den 30 sekunder lange pausen før du i det hele tatt kommer til innstillingssiden, lang nok til at du kan lure på om noe stoppet opp før prosessen tydelig starter.

4. Bekrefter den live deployen

Før jeg utforsket noen av administrasjonsverktøyene, ville jeg bekrefte at appen faktisk var deployet og fungerte, ikke bare var merket “Completed” på skjermen.

Fra siden Deployment completed klikket jeg rett til live URL-en, ivory-llama-856835.hostingersite.com, i stedet for å stole på forhåndsvisningsminiatyren i dashboardet alene.

Den live siden lastet og viste akkurat det appen var kodet til å vise:

• Server build time, en live tidsstempel som bekrefter at siden var nybyggd, ikke servert fra en gammel cache
• Environment variable check, som viste den egendefinerte variabelen jeg satte under deploy-skjermen, bekreftet korrekt på den faktiske live siden, ikke bare i dashboard-forhåndsvisningen

Jeg klikket deretter appens egen Ping the API route knapp, som kaller et live backend-endepunkt i stedet for bare å rendere statisk innhold. Den returnerte et rent JSON-svar:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Det svaret betyr mer enn det kanskje ser ut som. At en side lastes korrekt betyr bare at de statiske filene ble lastet opp.

Et fungerende API-kall beviser at den faktiske Node.js-serveren kjører under og svarer på ekte forespørsler, den delen av “Node.js web app”-hosting som er lett å late som med en statisk fil og vanskelig å late som med en live server-tidsstempel generert akkurat idet du klikker en knapp.

Hva jeg syntes: Dette er sjekken jeg ville anbefale deg før du stoler på noen deploy på denne plattformen, eller på en lignende en. En grønn “Completed”-status og en forhåndsvisningsminiatyr forteller deg at byggingen ble ferdig. Å klikke deg videre til den live URL-en og trigge noe dynamisk, et API-kall, en database-lesing, noe som ikke kan forfalskes av en cachet statisk side, forteller deg at serveren faktisk er i live og gjør det du bygde den til å gjøre.

5. Web App-administrasjon

Med den live appen bekreftet fungerende, gikk jeg tilbake inn i hPanel og utforsket appens egen administrasjonsdashboard fra ende til ende, det faktiske server-administrasjonslaget for dette produktet, separat fra den generelle hPanel Home-siden som ble omtalt tidligere.

Dashboard-oversikt. Idet du lander her, viser fire statusmerker tilstanden på et øyeblikk:

Alle fire kom tilbake grønne som standard, uten at jeg måtte slå på noe manuelt. Under dette ligger et kort for Last deployment som bekrefter status, repository, forfatter, commit, deploy-tidspunkt, oppdaget stack og Node-versjon, alt du ønsker å verifisere med et blikk uten å grave i logger.

En automatisk Page Speed test hadde allerede kjørt mot den live siden på egen hånd og returnert en 99/100 Desktop-score uten at jeg startet den selv, ved siden av et Essentials -panel med hurtiglenker til databasetilkobling, sikkerhetskopier, filbehandler, runtime-logger og cache.

Deployments, miljøvariabler og logger. Tre separate sider dekker dette:

• Deployments beholdt en full historikk over push, forfatter, branch, commit-hash og fullføringsstatus, en faktisk historikk i stedet for bare den nyeste
• Environment variables listet korrekt variabelen jeg satte under deploy, og bekreftet at den ble lagret og brukt, ikke bare vist en gang under oppsettet og glemt
• Runtime logs streamet live serverutdata mens det skjedde, Next.js-startlinjer, klare tidsstempler og en løpende telling av problemer og feil, som viste null og null hele tiden jeg så på

Sikkerhet. Malware Scanner returnerte et rent resultat, “Your website is safe”, med ett forbehold oppgitt tydelig i stedet for begravet i det små: den sjekker bare nettstedfiler, ikke databaseinnhold, og det finnes et betalt ryddealternativ hvis du vil ha en dypere sjekk som også inkluderer databasen. Vulnerabilities-skanningen kom også tilbake ren.

Databaser. Dette er stedet hvor produktets egen markedsføring skaper et reelt gap du bør forstå før du kjøper. Planen reklamerer for administrert MySQL som en hovedfunksjon, men ingenting blir satt opp automatisk for deg.

Databases-delen åpner på et manuelt skjema Create a New MySQL Database And Database User , noe som betyr at du navngir og oppretter databasen selv før appen din kan bruke en. Jeg bekreftet dette direkte med Kodee, omtalt i support-delen nedenfor, og svaret var tydelig: administrert betyr at Hostinger kjører databaseinfrastrukturen i bakgrunnen, ikke at en database opprettes for deg idet appen går live.

Avansert tilgang. SSH-tilgang finnes under Advanced, komplett med IP, port og brukernavn, men står Inactive som standard og må aktiveres manuelt før du kan bruke den. File Manager tilbyr et valg mellom å bla gjennom bare filene til denne appen eller alle filer på hele hostingplanen.

Hva jeg syntes: Det daglige dashboardet er grundig og godt organisert. Spesielt sikkerhet og deploy-historikk er lett å finne og genuint informativt, og runtime-loggen med null feil sammen med en ren malware-skanning ga meg reell tillit til at appen var frisk, ikke bare online.

Det ene stedet grensesnittet overlover er databaseseksjonen, der “managed MySQL” på plansiden høres ut som noe som ligger klart idet appen går live, mens det i praksis betyr et kontrollpanel for å opprette en selv.

Samlet vurdering av brukervennlighet

Build, Deploy, and Scale with Hostinger

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

Besøk Hostinger

Nivå av support

Jeg testet Hostinger sin support for Web Apps Hosting gjennom Kodee, AI-assistenten innebygd i hPanel, og gikk deretter gjennom kunnskapsbasen for å se hvor mye den dekker uten at du trenger å spørre noen. Kodee dukker opp på to steder det er verdt å skille mellom: som Ask AI på det offentlige markedsføringsnettstedet, og som et Agent -panel tilgjengelig fra alle sider inne i hPanel, inkludert direkte på Web Appens eget dashboard.

1. AI-support (Kodee)

Jeg stilte to spørsmål bygget rundt reelle mangler jeg hadde funnet under testingen, ikke generelle oppslag Kodee kunne svare på ved å lime inn fra dokumentasjonen.

Spørsmål 1 testet hvordan feil under deploy og tidspunkt for miljøvariabler håndteres, begge reelle produksjonshensyn for alle som sender til denne plattformen:

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 svarte direkte og korrekt på begge punktene. En mislykket bygging erstatter ikke en app som allerede kjører, hvis en tidligere deploy var vellykket, fortsetter appen å servere den siste fungerende versjonen. Hvis det er første deploy og det ikke finnes noe å falle tilbake på, går appen ned til byggingen er fikset og deployet på nytt, et klart, ærlig svar i stedet for en vag forsikring.

Når det gjelder miljøvariabler, bekreftet den at du kan sette dem før første deploy i deploy-innstillingene, og for en allerede kjørende app gikk den gjennom de eksakte tre stegene: åpne Settings og Redeploy, legg til eller rediger variabler under Environment variables, lagre og redeploy.

Spørsmål 2 presset på de to manglene jeg selv hadde funnet i dashboardet, formuleringen “managed MySQL” mot det manuelle opprettelsesskjemaet, og SSH som er inaktivt som standard:

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 sitt svar bekreftet nøyaktig det jeg hadde funnet i grensesnittet, ikke en mykere versjon av det. En database opprettes ikke automatisk for hver Web App, “managed” viser til at Hostinger kjører databaseservicen og infrastrukturen, mens opprettelse og konfigurasjon av en faktisk database er opp til deg, via samme Create a New MySQL Database-skjerm jeg allerede hadde sett, etterfulgt av at du legger til tilkoblingsdetaljene i appens miljøvariabler selv.

Om SSH bekreftet den at det å la den være inaktiv ikke endrer noe for hvordan appen kjører, deployer eller kobler til en database. Det er kun et valgfritt verktøy for CLI-kommandoer, migrasjoner eller direkte feilsøking av filer, ikke noe plattformen er avhengig av i bakgrunnen.

Hva jeg syntes: Begge svarene stemte med det jeg allerede hadde bekreftet manuelt i dashboardet i stedet for å motsi eller myke det opp, noe som er kjennetegnet på et supportverktøy som faktisk sjekker den reelle produktstatusen i stedet for å resitere et manus. Ingen av spørsmålene kunne besvares ved å lime inn fra en generisk FAQ, og Kodee håndterte begge med spesifikke, strukturerte svar med to deler på omtrent ett minutt hver.

2. Kunnskapsbase

Hostinger sin kunnskapsbase åpner på et kategorisert rutenett, 20 kategorier totalt, hver med et artikkeltall. Noen av de største: AI Builder har 330 artikler, VPS har 276, Email har 127, og Website har 103.

Web Apps Hosting får ikke sin egen dedikerte kategori. Innholdet ligger spredt over Getting Started, hPanel og Website i stedet, noe som er et reelt funn for alle som forventer et enkelt, dedikert hjem slik VPS eller Email får.

Å søke etter “Web Apps” direkte ga 71 resultater fordelt på 8 sider. De øverste resultatene var en blanding av direkte relevante og bare løst relaterte artikler:

• How to deploy apps built with Codex on Hostinger, direkte relevant
• Hostinger AI Builder: How to create a web app in agentic mode, nært beslektet men et annet produkt
• How to add a Node.js Web App in Hostinger, direkte relevant
• How to install Flutter Web on a VPS at Hostinger, et annet produkt helt
• Flere Website Builder-betalingsmetodeartikler (PayPal, WeChat Pay, BLIK), irrelevante bortsett fra at de deler ordene “web” og “app” et sted i teksten

Jeg åpnet et av de øverste resultatene, How to deploy apps built with Codex on Hostinger, for å sjekke dybden. Det viste seg å være en grundig, godt strukturert veiledning, med støttede rammeverk listet på forhånd, trinnvise skjermbilder for både GitHub-import- og ZIP-opplastingsveiene, en del om å konfigurere byggeinnstillinger med eksempelskripter, en gjennomgang av filstrukturen etter deploy, en database-tilkoblingsveiviser, en del om sårbarhetsovervåking og en avsluttende FAQ-blokk.

Selv om den er vinklet rundt Codex spesielt, er den underliggende plattformen den samme som ligger bak den generelle Node.js Web App-produkten, så det meste av den gjelder direkte.

Hva jeg syntes: Artikkeltallet i søket ser sterkt ut på papiret, 71 treff for ett ord, men en meningsfull del av volumet er støy fra ikke-relaterte produkter som bare deler lignende ord. Artikkelen jeg åpnet i full lengde holdt seg bra kvalitetsmessig når jeg kom inn i den, tydelige trinn, ekte skjermbilder og en genuin FAQ-del, men det krevde at jeg scrollet forbi resultater som ikke hadde noe med det jeg faktisk prøvde å deploye å gjøre.

Samlet vurdering av kundesupport

Simple Hosting for Modern Web Apps

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

Besøk Hostinger

Bør vi anbefale Hostinger Web Apps Hosting?

Ja. Deploy-prosessen er den sterkeste delen av dette produktet: korrekt auto-oppdagelse av stack, branch og Node-versjon, en ekte strømmende byggelogger i stedet for en spinner, og en live app som besto alle ytelsestestene jeg kastet på den, perfekte GTmetrix-resultater fra to ulike kontinenter, en ren global konsistenssjekk med 54 punkter, og matchende 100/100-resultater fra Hostinger sitt eget verktøy på både desktop og mobil. Kodee støttet dette opp med nøyaktige, spesifikke svar på reelle tekniske spørsmål i stedet for generiske standardsvar.

De grove kantene er små, men verdt å kjenne til før du kjøper. “Managed MySQL” leses på plansiden som noe som er klart idet appen går live, og i praksis betyr det et manuelt opprettelsesskjema. Dashboardet gir heller ikke Web Apps Hosting en dedikert inngang fra hovedsiden Home, du må vite at du skal inn via Websites først.

For en utvikler som vil ha en rask, rammeverk-agnostisk deploy på infrastruktur som benchmarker så godt, er dette en enkel anbefaling. For noen som forventer at hver annonserte funksjon er slått på idet betalingen er fullført, bør du sette av noen ekstra minutter til å sette opp databasen selv.

Hostinger

5.0

2,471 brukeromtaler

Nkr 15 /mo

Startpris

Besøk Hostinger

Rating based on expert review

• Brukervennlig
  4.9
• Support
  4.9
• Funksjoner
  4.8
• Pålitelighet
  4.7
• Prising
  4.5