Hostinger byggede Web Apps Hosting omkring en simpel idé: push din kode fra GitHub, en ZIP-fil eller din AI-kodeagent, og få en live, produktionsklar app kørende på omkring et minut, uden en server du selv skal administrere. Jeg ville finde ud af, hvor meget af det der faktisk holder, når det er dig, der klikker deploy, så her er, hvad jeg fandt ud af.

Deploy Web Apps Faster with Hostinger

Deploy moderne webapps på Hostinger med automatiserede builds, administreret infrastruktur, global CDN, SSL, sikkerhedsværktøjer og en 30-dages pengene-tilbage-garanti.

Besøg Hostinger

Fordele og ulemper

Vurderingsfordeling

For at score Hostinger’s Web Apps Hosting anvendte jeg HostAdvice’s rating-metodologi, den samme standardiserede tilgang, der bruges på tværs af alle anmeldelser på sitet, så scorerne forbliver forankret i reel testning frem for markedsføringssprog. Her er, hvordan den scorede på hver parameter.

Host Your Web Apps Without the DevOps Hassle

Deploy moderne webapplikationer på fuldt administreret hosting med automatiserede deploys, administreret SSL, global CDN og indbygget sikkerhed.

Besøg Hostinger

Planer og priser

Hostinger sælger Web Apps Hosting som to niveauer, Business og Cloud Startup, begge bygget specifikt til at deploye Node.js- og moderne JavaScript-apps i stedet for traditionel website-opbygning.

Cloud Startup, det niveau jeg testede, fordobler antallet af apps og CPU-kerner i forhold til Business, og begge planer inkluderer et gratis domæne, gratis business-email og administreret SSL for det første år direkte i checkout.

Et par ting, du skal vide, før du bestiller:

• Pengene-tilbage-garanti: Web Apps Hosting er omfattet af Hostinger’s standard refunderingsvilkår, et lige 30-dages vindue fra købsdatoen. Det er markant enklere end det, der gælder for Hostinger’s VPS-planer, som har en ekstra 180-dages cooldown mellem refund-krav. Ingen sådan cooldown gælder her.
• Gratis prøveperiode: Jeg fandt ingen dedikeret gratis prøveperiode. Den 30-dages pengene-tilbage-garanti er din evalueringsperiode i stedet.
• Betalingsmetoder: Checkout viste kortbetaling som standardmetode, med Visa, Mastercard, Amex og Discover-logoer vist, plus en mulighed for at tilføje en anden betalingsmetode under checkout.
• Hvad der er inkluderet: Et gratis domæne i et år, gratis mailbokse i et år og administreret SSL er alle inkluderet uden ekstra omkostninger oven i planprisen, så listeprisen er tæt på den reelle pris for at få en fuldt fungerende, sikret deploy live.
• Det ene upsell: Hostinger Reach, et email marketing-tilføjelsesprodukt, vises i kurven som sin egen fremhævede boks med en separat månedlig pris. Det er let at springe over og bliver ikke inkluderet eller forvalgt som standard.

Hvis du opsiger en Web Apps Hosting-plan inden for 30 dage, bekræfter Hostinger’s refunderingspolitik, at den er omfattet af standardvilkårene i stedet for undtagelseslisten, så en enkel annullering inden for den periode bør kvalificere til refundering uden de ekstra betingelser, der er knyttet til VPS- eller domænekøb.

Funktioner

• Automatisk registrering af framework og Node-version
• Værktøjer til oprettelse af administreret MySQL-database
• Global CDN aktiv som standard
• WAF- og DDoS-beskyttelse inkluderet
• Daglige og on-demand backups
• Malware-scanner og vulnerabilities-scanning
• GitHub-integration med auto-deploy
• Gratis domæne, email og SSL
• SSH-adgang til avancerede brugere

From Code to Live App with Hostinger

Forbind dit GitHub-repository eller upload dit projekt, og få det online med administreret infrastruktur, automatiske deploys og daglige backups.

Besøg Hostinger

Ydelse

Da Web Apps Hosting er fuldt administreret, får du aldrig shell-adgang til en server, så der er ingen CPU, RAM eller disk at benchmarke direkte på samme måde som i en VPS-anmeldelse.

Det, du kan måle, er hvor hurtigt den deployede app indlæses og reagerer fra rigtige lokationer rundt om i verden. Jeg testede dette fra fire forskellige vinkler: GTmetrix fra to kontinenter, en global konsistenskontrol med 50+ punkter og Hostinger’s eget indbyggede hastighedsværktøj for både desktop og mobil.

Appen under test er den Next.js-deploy, der er dækket i Ease of Use-sektionen nedenfor, live på ivory-llama-856835.hostingersite.com, kørende på Cloud Startup-planen (4 CPU-kerner, 4096 MB RAM, 100 GB NVMe storage), med CDN aktiv som standard.

1. GTmetrix, testet fra to kontinenter

Jeg kørte GTmetrix to gange fra forskellige dele af verden for at se, om resultatet holdt på tværs, eller om det kun så godt ud fra ét heldigt udsigtspunkt.

Begge kørsler landede på perfekte 100% både på Performance og Structure, med nul layout shift og nul blocking time i begge lokationer, hvilket betyder, at intet på siden konkurrerede om browserens opmærksomhed eller hoppede rundt under indlæsningen.

Det virkelig interessante er, at Frankfurt faktisk slog Chicago på alle timing-metrikker, selvom jeg bevidst valgte en amerikansk serverlokation til denne app. Det resultat giver kun mening i lyset af CDN’et.

Når et CDN er aktivt, som det var her som standard, går din besøgende ikke nødvendigvis direkte til origin-serveren.

De rammer den nærmeste cachede edge-node, så et europæisk testpunkt kan ende med at være hurtigere end et amerikansk, selv om den egentlige server står i USA. Det er en reel, praktisk bekræftelse på, at Hostinger’s CDN slået til som standard faktisk gør nyttigt arbejde i stedet for bare at være en marketing-bullet.

2. Global konsistens (Check-Host)

Jeg kørte et HTTP-tjek mod den live URL fra hvert checkpoint, Check-Host tilbyder, 54 lokationer på tværs af seks kontinenter. Det fulde billede:

Hvert succesfuldt tjek returnerede et rent 200 OK, ingen fejl, ingen delvise fejl, ingen uventede redirects.

Responstiderne fortalte en tydelig historie om, hvordan CDN-caching opfører sig på tværs af virkelige afstande:

Europæiske checkpoints gav konsekvent de hurtigste tider, flere under 50 millisekunder, mens checkpoints længst væk fra enhver edge-node, Tokyo, Singapore, Ho Chi Minh City, stadig returnerede gyldige 200-svar, bare langsommere, i området 0.3 til 0.8 sekunder.

Det er den forventede form for en CDN-baseret deployment: hurtigt nær edge-noderne, stadig fuldt funktionel langt væk fra dem.

De fire timeouts, Kazakhstan, Romania og to af de fire russiske checkpoints, er ikke noget, jeg ville læse som et problem med Hostinger’s infrastruktur.

Andre checkpoints i de samme lande lykkedes (Saint Petersburg kom rent tilbage på 0.063s, mens to Moscow-checkpoints timeoutede), hvilket peger på regional netværksfiltrering på checkpointets side snarere end noget galt med den deployede app.

3. Hostinger’s eget hastighedsværktøj, desktop og mobil

Hostinger kører sin egen Page Speed-test direkte i app-dashboardet, så jeg sammenlignede dens tal med de uafhængige GTmetrix-resultater i stedet for at tage nogen af dem for gode varer alene.

Begge enhedstyper scorede perfekte 100, og desktop-tallene stemmer tæt overens med, hvad GTmetrix uafhængigt målte, og det er hele pointen med at køre begge. To forskellige værktøjer, to forskellige metoder, og de er enige med hinanden.

Mobil var langsommere på tværs af alle timing-metrikker, som forventet på en simuleret langsommere forbindelse og svagere processor, men stadig hurtig nok til, at en 100-score afspejler virkelig stærk mobil performance i praksis og ikke bare en mild vurderingsskala.

En uoverensstemmelse i selve værktøjet. Selvom scoren er en ren 100 på begge enheder, markerer Diagnostics-panelet nedenunder stadig nogle få linjepunkter med en bogstavelig 0-score, network dependency tree, document request latency og avoiding multiple redirects, sammen med to punkter scoret til 50, unused JavaScript og legacy JavaScript.

Ingen af de lave under-scorer trak hovedscoren ned, så betragt dem som mindre, reelt eksisterende optimeringsmuligheder snarere end noget galt med deploymenten.

Separat er de “helpful links”, Hostinger viser ved siden af disse diagnostics, alle skrevet til WordPress, “Speed up WordPress in 9 easy steps,” “How to optimize images for your WordPress site”, selvom det her er en Node.js-app uden WordPress involveret noget sted i stacken. Det er et levn fra en delt diagnostics-skabelon i stedet for indhold bygget til dette produkt.

Samlet vurdering af ydelse

Managed Web App Hosting by Hostinger

Fokuser på at bygge din app, mens Hostinger tager sig af deployment, infrastruktur, sikkerhed, SSL, backups og global levering.

Besøg Hostinger

Brugervenlighed

Jeg testede Hostinger’s Web Apps Hosting fra landingpage til checkout, og derefter fra en kold konto til en fuldt live, fungerende Node.js-deploy.

Det omfattede valg af plan, betaling, valg af byggemetode, forbindelse til GitHub og at se builden fuldføres i realtid. Her er, hvordan den proces faktisk føltes.

1. Registrering

Jeg startede på Web Apps Hosting-landingpage, som leder med én call to action: Start deploying.

At klikke på den åbner ikke en signup-formular. Det scroller dig direkte ned til pris-sektionen, så det første reelle valg, du træffer, er hvilken plan du vil købe, ikke hvilke kontooplysninger du vil udfylde.

To planer stod side om side:

Jeg valgte Cloud Startup for dobbelt så mange apps og mere CPU-kapacitet end entry-niveauet. En lille uoverensstemmelse at bemærke her: pris-siden kalder den “Cloud Startup”, men når den lander i kurven, er den samme plan mærket “Startup plan.” Ikke et funktionelt problem, bare et navnemismatch mellem to skærme i samme checkout-flow.

Selve kurven var ren. Den listede 48-måneders perioden, besparelsen, et gratis domæne i et år og gratis mailbokse, og tilbød derefter ét upsell, Hostinger Reach email marketing, placeret i sin egen fremhævede boks i stedet for at være forvalgt.

Jeg sprang det over og klikkede Continue uden friktion.

Hvis du er ny kunde i stedet for en eksisterende, indsætter checkout et konto-oprettelsestrin her, før du når til siden med faktureringsadresse og betaling.

Næste skridt er, at du tilføjer en faktureringsadresse, vælger en betalingsmetode, kort, PayPal eller en af de andre muligheder, og sender. Jeg fik en ordrebekræftelsesmail inden for få øjeblikke efter at have klikket Submit payment, og derefter landede jeg direkte i hPanel med planen allerede provisioneret.

Hvad jeg syntes: Checkout er kort, og upsell er let at afvise uden at skulle lede efter et skjult skip-link. Navnemismatchet mellem pris-siden og kurven er en lille ting, men det er den slags detalje, der får en førstegangskøber til at stoppe op og dobbelttjekke, at de valgte den rigtige plan.

2. Dashboard

Når betalingen er gået igennem, lander du i hPanel, Hostinger’s eget kontrolpanel, som de har bygget til at administrere alle produkter, de sælger, ikke en side, der er bygget specifikt omkring din nye Web App.

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

Hvis du scroller forbi det, finder du:

• Promoveringsfliser for AI Builder, online store-værktøjet, der lover en gratis business-email, AI agents, en automation-app og et gratis domæne
• En to-do-liste der skubber dig mod opsætningsopgaver, afslut Reach-opsætning, gør krav på din gratis email, gør krav på dit gratis domæne
• Your business, en løbende liste over alle sites, apps og VPS-instanser knyttet til din konto, hver med sin egen Manage site knap
• VPS, en separat tabel længere nede, der viser eventuelle VPS-instanser efter IP-adresse, status og udløbsdato

Et Agent panel sidder også permanent i øverste højre hjørne på hver hPanel-side, ikke kun på Home. Det er den samme Kodee-assistent, der bruges til support, men her placeret som et generelt handlingsværktøj med færdige prompts som “Deploy my Node.js app” eller “Harden VPS updates”, som du kan aktivere uden at skrive et helt spørgsmål selv.

Home er faktisk nyttig, når din app allerede eksisterer. Alt i Your business linker direkte videre til den. Men det er ikke her, du går hen for at oprette en ny Web App eller nå Setup-knappen. Til det skal du bruge en anden vej gennem sidebaren:

1. Klik på Websites i venstre sidebar
2. En undermenu udfolder sig nedenunder: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Klik på Web Apps

Det klik fører dig til en helt anden skærm end Home, en der er organiseret omkring dine faktiske hostingplaner snarere end en promptlinje.

Her får hver plan, du ejer, sit eget kort. På min konto betød det tre kort stablet vertikalt:

Business -kortet havde også allerede en live app listet nedenunder fra tidligere test, orange-walrus-700988.hostingersite.com, med sine egne Tools- og Dashboard-knapper.

Det er i sig selv værd at lægge mærke til. Når en Web App først eksisterer, vokser dens kort en række som denne, der viser det live site direkte, og det er præcis, hvordan dit Cloud Startup-kort vil se ud, når du er færdig med opsætningen.

Da Cloud Startup var den plan, jeg lige havde købt og endnu ikke sat op, viste dens kort kun en Setup knap. Det er den knap, der faktisk starter Web App-oprettelsesguiden, og den vises kun her, under Websites → Web Apps, ikke fra Home-skærmen, du lander på som standard.

Hvad jeg syntes: hPanel er overskueligt, når du først finder den rigtige skærm, men Web Apps Hosting har ingen tydelig hovedindgang. Når du lander på Home, får du en promptlinje og genveje, ikke en vej til at oprette en app; du skal vide, at du skal klikke Websites og derefter Web Apps, før Setup overhovedet dukker op. Det er et par ekstra klik for et produkt, der sælges som “live på et minut.” Når du først er der, er plan-kortene dog rene og ærlige om status, og en plan med en app kørende viser det lige på kortet.

3. Deploying af appen

At klikke på Setup på plan-kortet åbnede et kort onboarding-flow: Where would you like to start? med tre muligheder, 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 op i to begynderorienterede muligheder øverst, Hostinger AI Builder og WordPress + AI, og to muligheder under en separat “for advanced users”-overskrift nedenunder: Node.js web app og PHP/HTML website. At vælge Node.js web app er det, der faktisk bringer dig ind på selve Web Apps Hosting-produktet.

Det er en vigtig strukturel note for alle, der sammenligner produkter: Web Apps Hosting har ikke sit eget dedikerede signup-flow.

Det er én gren inde i den samme generelle site-oprettelsesguide, som bruges til AI Builder og WordPress.

Jeg klikkede på cirklen ved siden af Node.js web app, og derefter klikkede jeg på Next.

Derfra:

• Domæneskærm: Jeg valgte Use temporary domain i stedet for at binde et rigtigt domæne, da dette var en test-deploy.

• Serverlokationsskærm: Hostinger havde på forhånd valgt France, den nærmeste region i forhold til mit faktureringsland, og viste det som 167ms latency. Hvis man scrollede til United States-indstillingen, viste den 364ms, mere end dobbelt så meget.

Jeg valgte United States, Massachusetts alligevel, og det er præcis den lektie, lokationsvælgeren lærer dig på alle Hostinger-produkter: vælg ud fra, hvor dine faktiske besøgende er, ikke det laveste tal på listen.

Mit testsites tiltænkte publikum er USA-baseret, så en server i USA vil faktisk betjene dem hurtigere, end en server i France nogensinde kunne, uanset hvad vælgeren viste mig fra min egen lokation. Tallet på skærmen fortæller dig, hvor hurtigt serveren reagerer på Hostinger’s test, ikke hvor hurtigt den vil reagere for de mennesker, der faktisk skal bruge dit site.

• Deploy-metodeskærm: to primære muligheder, Import Git repository (mærket Recommended) eller Upload your files, plus et callout nedenunder til at deploye direkte fra Claude Code, Cursor eller VS Code gennem Hostinger Connector. Jeg valgte Import Git repository og klikkede Connect with GitHub.

Det åbnede et ægte GitHub-loginvindue, hvis du ikke allerede var logget ind, og derefter en tilladelsesskærm med titlen Install & Authorize Hostinger, der bad dig vælge mellem:

• At installere på all repositories du ejer, inklusive fremtidige, med read-only-adgang til offentlige repos
• At installere på only select repositories du vælger individuelt og med de præcise tilladelser angivet: read access til actions, metadata og repository hooks, og read-and-write access til administration, code og pull requests. Når du klikker Install & Authorize, sender GitHub dig automatisk tilbage til hPanel.

Du lander på Select Git repository to import, en scrollbar liste over alle repositories knyttet til din GitHub-konto, hver med sin egen Deploy-knap ved siden af. Jeg fandt test-repositoriet, jeg havde pushed tidligere, hostadvice-webapps-test, og klikkede Deploy ved siden af det.

Fra det øjeblik jeg klikkede på den knap, gik der tæt på 30 sekunder uden nogen fremdriftsindikator på skærmen, længe nok til at man kunne undre sig over, om klikket overhovedet blev registreret.

Siden, der til sidst indlæses, har titlen Review build settings, og den fortæller dig præcis, hvor din app vil bo, før du forpligter dig til noget: “Deploys to ivory-llama-856835.hostingersite.com.” Nedenunder, uden at du rørte et eneste felt, havde den allerede registreret automatisk:

Hver af disse fem rækker har sin egen Change eller Add-knap ved siden af, så intet her er låst fast, hvis registreringen rammer forkert.

Jeg klikkede på Add ved siden af Environment variables og satte ét key-value-par for at bekræfte, at det faktisk ville nå den kørende app senere, og klikkede derefter på Finish i den dialog og derefter på den primære Deploy-knap nederst på siden.

Watching the build

Skærmen skifter til en Deploying… visning med en navngivet fremdriftslinje, “Deployment from GitHub,” der bevæger sig i reelle trin, jeg så den gå gennem 28%, derefter 51%, på vej mod fuldførelse. Under fremdriftslinjen ligger et sammenklappeligt Build logs panel, og når man åbner det, vises ægte, live terminaloutput, efterhånden som det sker, ikke en placeholder-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 …

Deployment completed

Når builden er færdig, lander du på en Deployment completed! skærm med en live miniaturevisning af din faktiske kørende app renderet lige der i kortet, ved siden af en opsummering, der viser repositories-navnet og den tildelte live URL.

Fra denne side kan du klikke direkte videre til Go to dashboard, hvor du administrerer appen fremover.

Hvad jeg syntes: Auto-registreringen er det stærkeste her. Framework, branch og Node-version kom alle tilbage korrekt uden et eneste manuelt felt, og den live build-log gør ventetiden transparent i stedet for uigennemsigtig. Det eneste svage punkt er den 30 sekunder lange pause, før du overhovedet når indstillingsskærmen, længe nok til at man kan tro, at noget er gået i stå, før processen synligt starter.

4. Bekræftelse af den live deployment

Inden jeg udforskede nogen af administrationsværktøjerne, ville jeg bekræfte, at appen faktisk var deployet og fungerede, ikke bare var markeret som “Completed” på skærmen.

Fra Deployment completed-siden klikkede jeg direkte videre til den live URL, ivory-llama-856835.hostingersite.com, i stedet for at stole på dashboardets preview-miniature alene.

Den live side indlæste og viste præcis det, appen var kodet til at vise:

• Server build time, en live tidsstempel, der bekræfter, at siden var frisk bygget, ikke leveret fra en gammel cache
• Environment variable check, der viste den brugerdefinerede variabel, jeg havde sat under deploy-skærmen, korrekt bekræftet på det faktiske live site, ikke kun i dashboard-previewet

Jeg klikkede derefter på appens egen Ping the API route knap, som kalder et live backend-endpoint i stedet for blot at gengive statisk indhold. Den returnerede et rent JSON-svar:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Det svar betyder mere, end det måske ser ud til. En side, der indlæses korrekt, beviser kun, at de statiske filer blev uploadet.

Et fungerende API-kald beviser, at den faktiske Node.js-server kører nedenunder og svarer på rigtige forespørgsler, den del af “Node.js web app”-hosting, der er let at fake med en statisk fil og svær at fake med et live server-tidsstempel genereret i præcis det øjeblik, du klikker på en knap.

Hvad jeg syntes: Det er det tjek, jeg ville anbefale dig at lave, før du stoler på enhver deploy på denne platform, eller på en lignende. En grøn “Completed”-status og en preview-miniature fortæller dig, at builden er færdig. At klikke videre til den live URL og aktivere noget dynamisk, et API-kald, en database-læsning, hvad som helst, der ikke kan fakes af en cachet statisk side, fortæller dig, at serveren faktisk er i live og gør det, du har bygget den til.

5. Web App-administration

Da den live app var bekræftet som fungerende, gik jeg tilbage i hPanel og udforskede appens eget administrationsdashboard fra ende til anden, det egentlige server-administrationslag i dette produkt, adskilt fra det generelle hPanel Home-skærmbillede, der blev dækket tidligere.

Dashboard-oversigt. I det øjeblik du lander her, fortæller fire statusbadges dig, hvordan det står til ved første øjekast:

Alle fire kom tilbage grønne som standard, uden at jeg skulle slå noget til manuelt. Nedenunder ligger et Last deployment kort, der bekræfter status, repository, forfatter, commit, deploy-tid, registreret stack og Node-version, alt det, du gerne vil kunne verificere med et blik uden at grave i logs.

En automatisk Page Speed test havde allerede kørt mod live-siden på egen hånd og returneret en 99/100 Desktop-score uden at jeg selv udløste den, placeret ved siden af et Essentials panel med genveje til databaseforbindelse, backups, file manager, runtime logs og cache.

Deployments, miljøvariabler og logs. Tre separate sider dækker dette område:

• Deployments holdt en fuld historik over push, forfatter, branch, commit-hash og fuldførelsesstatus, en reel historik i stedet for kun den seneste
• Environment variables listede korrekt den, jeg havde sat under deploy, hvilket bekræfter, at den blev gemt og anvendt, ikke bare vist én gang under opsætningen og glemt
• Runtime logs streamede live serveroutput, efterhånden som det skete, Next.js-startlinjer, ready-tidsstempler og et løbende antal issues og errors, som hele tiden stod til nul og nul, mens jeg så på

Sikkerhed. Malware Scanner returnerede et rent resultat, “Your website is safe,” med en klar begrænsning angivet åbent i stedet for skjult i det små: den tjekker kun website-filer, ikke databaseindhold, og der findes en betalt oprydningsmulighed, hvis du ønsker et dybere tjek, der også inkluderer databasen. Vulnerabilities-scanningen kom også tilbage ren.

Databaser. Det er her, produktets egen markedsføring skaber et reelt hul, du bør forstå, før du køber. Planen reklamerer med managed MySQL som en hovedfunktion, men intet bliver provisioneret automatisk for dig.

Databases-sektionen åbner på en manuel Create a New MySQL Database And Database User formular, hvilket betyder, at du selv navngiver og opretter databasen, før din app kan bruge en. Jeg bekræftede dette direkte med Kodee, dækket i Support-sektionen nedenfor, og svaret var klart: managed betyder, at Hostinger driver databaseinfrastrukturen bag kulisserne, ikke at en database oprettes for dig i det øjeblik, din app går live.

Avanceret adgang. SSH-adgang findes under Advanced, komplet med IP, port og brugernavn, men står som Inactive som standard og kræver et manuelt Enable-klik, før du kan bruge det. File Manager giver et valg mellem at gennemse kun filerne for denne app eller alle filer på hele hostingplanen.

Hvad jeg syntes: Det daglige dashboard er grundigt og velorganiseret. Især sikkerhed og deploy-historik er lette at finde og virkelig informative, og runtime-loggen uden fejl sammen med en ren malware-scanning gav mig reel tillid til, at appen var sund, ikke bare online.

Det ene sted, hvor interfacet lover lidt mere, end det leverer, er database-sektionen, hvor “managed MySQL” på plansiden lyder som noget, der står klar i det øjeblik, din app går live, mens du i praksis får en manual oprettelsesformular, nem at bruge, men et trin, du selv skal tage.

Samlet vurdering af brugervenlighed

Build, Deploy, and Scale with Hostinger

Host moderne webapps med GitHub-integration, administreret MySQL, global CDN, ubegrænset båndbredde og indbyggede sikkerhedsværktøjer.

Besøg Hostinger

Supportniveau

Jeg testede Hostinger’s support til Web Apps Hosting gennem Kodee, AI-assistenten indbygget i hPanel, og gik derefter gennem vidensbasen for at se, hvor meget den dækker uden at skulle spørge nogen. Kodee dukker op to steder, der er værd at skelne mellem: som Ask AI på den offentlige marketing-side og som et Agent panel tilgængeligt fra enhver side inde i hPanel, også direkte på selve Web App’ens dashboard.

1. AI-support (Kodee)

Jeg stillede to spørgsmål bygget omkring reelle huller, jeg havde fundet under testen, ikke generiske opslag, som Kodee kunne besvare ved at kopiere fra dokumentationen.

Spørgsmål 1 testede adfærd ved deploy-fejl og timing for miljøvariabler, begge reelle produktionsbekymringer for alle, der sender til denne platform:

Hvis min apps build fejler midt i en GitHub-deploy, ruller appen så automatisk tilbage til den sidste succesfulde version, eller går den ned, indtil jeg retter fejlen og deployer igen? Og kan jeg sætte brugerdefinerede miljøvariabler før den første deploy, eller kun bagefter?

Kodee svarede direkte og korrekt på begge punkter. En fejlet build erstatter ikke en app, der kører i forvejen; hvis en tidligere deploy lykkedes, fortsætter appen med at servere den sidste fungerende version. Hvis det er den første deploy, og der ikke er noget at falde tilbage på, forbliver appen nede, indtil builden er rettet og deployet igen, et klart, ærligt svar i stedet for en vag beroligelse.

Om miljøvariabler bekræftede den, at du kan sætte dem før den første deploy i deployment-indstillingerne, og for en allerede kørende app gennemgik den de præcise tre trin: åbn Settings og Redeploy, tilføj eller rediger variabler under Environment variables, gem og deploy igen.

Spørgsmål 2 pressede på de to huller, jeg selv havde fundet i dashboardet, formuleringen “managed MySQL” op mod den manuelle oprettelsesformular, og SSH, der stod som inaktiv som standard:

Denne plan reklamerer med managed MySQL, men dashboardet viser en manuel ‘Create a New MySQL Database’-formular i stedet for en database, der oprettes automatisk. Oprettes en database for hver Web App som standard, eller kun hvis jeg selv opretter en? Og SSH-adgang er listet som tilgængelig, men vises som Inactive som standard. Hvis jeg aldrig aktiverer den, ændrer det så noget ved, hvordan min app faktisk kører, eller er SSH udelukkende et valgfrit ekstra for avancerede brugere?

Kodee’s svar bekræftede præcis det, jeg havde fundet i interfacet, ikke en mildere version af det. En database oprettes ikke automatisk for hver Web App; “managed” refererer til, at Hostinger driver databaseservicen og infrastrukturen, mens oprettelse og konfiguration af en egentlig database er op til dig via den samme Create a New MySQL Database-skærm, jeg allerede havde set, efterfulgt af, at du selv tilføjer dens forbindelsesoplysninger til din apps miljøvariabler.

Om SSH bekræftede den, at hvis du lader det være inaktivt, ændrer det ingenting ved, hvordan appen kører, deployer eller forbinder til en database. Det er udelukkende placeret som et valgfrit værktøj til CLI-kommandoer, migrationer eller direkte filfejlfinding, ikke noget platformen afhænger af i baggrunden.

Hvad jeg syntes: Begge svar matchede det, jeg allerede havde verificeret manuelt i dashboardet, i stedet for at modsige eller mildne det, hvilket er tegnet på et supportværktøj, der faktisk tjekker den reelle produktstatus i stedet for at recitere et manuskript. Ingen af spørgsmålene kunne besvares ved bare at kopiere fra en generisk FAQ, og Kodee håndterede begge med specifikke, strukturerede svar i to dele på omkring et minut hver.

2. Vidensbase

Hostinger’s vidensbase åbner på et kategoriseret gitter, 20 kategorier i alt, hver med et artikeltal. Nogle af 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 dedikerede kategori. Dets indhold ligger spredt ud over Getting Started, hPanel og Website i stedet, hvilket er et reelt fund for alle, der forventer et enkelt, dedikeret hjemsted på samme måde som VPS eller Email får det.

Et søg efter “Web Apps” gav 71 resultater fordelt på 8 sider. De øverste resultater var en blanding af direkte relevante og kun løst relaterede artikler:

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

Jeg åbnede et af de øverste resultater, How to deploy apps built with Codex on Hostinger, for at tjekke dybden. Det viste sig at være en grundig, velstruktureret gennemgang, med understøttede frameworks listet i starten, trin-for-trin-screenshots for både GitHub-import- og ZIP-upload-vejene, en sektion om konfiguration af build settings med eksempelkommandoer, en gennemgang af filstrukturen efter deploy, en databaseforbindelsesguide, en sektion om vulnerability-overvågning og en afsluttende FAQ-blok.

Selv om den er vinklet specifikt mod Codex, er den underliggende platform den samme som bag det generelle Node.js Web App-produkt, så det meste af den gælder direkte.

Hvad jeg syntes: Artikeltallet under søgning ser stærkt ud på papiret, 71 hits for et enkelt ord, men en betydelig del af volumen er støj fra ikke-relaterede produkter, der deler lignende ord. Den ene artikel, jeg åbnede i fuld længde, holdt fint niveau, når jeg først var inde i den, klare trin, rigtige screenshots og en ægte FAQ-sektion, men at finde den krævede, at man scrollede forbi resultater, der intet havde med det, jeg faktisk forsøgte at deploye, at gøre.

Samlet vurdering af kundesupport

Simple Hosting for Modern Web Apps

Deploy React, Next.js, Vue, Node.js og andre moderne applikationer uden at administrere servere eller kompleks infrastruktur.

Besøg Hostinger

Anbefaler vi Hostinger Web Apps Hosting?

Ja. Deploy-processen er den stærkeste del af dette produkt: korrekt auto-registrering af min stack, branch og Node-version, en reel streaming build-log i stedet for en spinner og en live app, der bestod alle performance-tests, jeg kastede efter den, perfekte GTmetrix-scorer fra to forskellige kontinenter, en ren global konsistenskontrol med 54 punkter og matchende 100/100-scorer fra Hostinger’s eget værktøj på både desktop og mobil. Kodee understøttede det med præcise, specifikke svar på reelle tekniske spørgsmål i stedet for generiske scriptsvar.

De svage punkter er små, men værd at kende, før du køber. “Managed MySQL” lyder på plansiden som noget, der er klar i det øjeblik, din app går live, og i praksis betyder det en manuel oprettelsesformular. Dashboardet giver heller ikke Web Apps Hosting en dedikeret indgang fra den generelle Home-skærm; du skal vide, at du skal ind via Websites først.

For en udvikler, der vil have en hurtig, framework-agnostisk deploy på infrastruktur, der benchmarker så godt, er dette en nem anbefaling. For en person, der forventer, at hver annonceret funktion er slået til i det øjeblik checkout er gennemført, skal der sættes et par ekstra minutter af til selv at oprette databasen.

Hostinger

5.0

2,471 user reviews

11 kr /mo

Start pris

Besøg Hostinger

Rating based on expert review

• Brugervenlighed
  4.9
• Support
  4.9
• Funktioner
  4.8
• Pålidelighed
  4.7
• Pris
  4.5