Hostinger byggde Web Apps Hosting kring ett enkelt löfte: skicka din kod från GitHub, en ZIP-fil eller din AI-kodagent, och få en live, produktionsklar app igång på ungefär en minut, utan någon server för dig att hantera. Jag ville veta hur mycket av det som faktiskt stämmer när det är du som klickar på deploy, så här är vad jag fann.

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

För- och nackdelar

Poängfördelning

För att betygsätta Hostinger’s Web Apps Hosting tillämpade jag HostAdvice’s rating methodology, samma standardiserade metod som används i varje recension på sajten, så att poängen hålls förankrade i verkliga tester snarare än marknadsföringsspråk. Här är hur den bedömdes per 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 och priser

Hostinger säljer Web Apps Hosting i två nivåer, Business och Cloud Startup, båda byggda specifikt för att deploya Node.js- och moderna JavaScript-appar snarare än traditionell webbplatsbyggnad.

Cloud Startup, nivån jag testade, fördubblar app-tilldelningen och CPU-kärnorna jämfört med Business, och båda planerna inkluderar en fri domän, fri företagse-post och managed SSL för det första året direkt i kassan.

Några saker att känna till innan du beställer:

• Pengarna-tillbaka-garanti: Web Apps Hosting omfattas av Hostinger’s standardvillkor för återbetalning, ett rakt 30-dagarsfönster från köpdatumet. Detta är betydligt enklare än vad som gäller för Hostinger’s VPS-planer, som har en extra cooldown på 180 dagar mellan återbetalningsanspråk. Ingen sådan cooldown gäller här.
• Gratis provperiod: Jag fann ingen särskild gratis provperiod. 30-dagars pengarna-tillbaka-garantin är i stället din utvärderingsperiod.
• Betalningsmetoder: Kassan visade kortbetalning som standardmetod, med Visa-, Mastercard-, Amex- och Discover-loggor visade, plus ett alternativ att lägga till en annan betalningsmetod under kassan.
• Det som ingår: En fri domän i ett år, fria brevlådor i ett år och managed SSL ingår alla utan extra kostnad ovanpå planpriset, så det utannonserade priset ligger nära den verkliga kostnaden för att få en fullt fungerande, säkrad deploy live.
• Den enda upsell: Hostinger Reach, ett tillägg för e-postmarknadsföring, visas i varukorgen som en egen markerad ruta med ett separat månadspris. Det är lätt att hoppa över och blir inte paketerat eller förvalt som standard.

Om du säger upp en Web Apps Hosting-plan inom 30 dagar omfattas den enligt Hostinger’s återbetalningspolicy av standardvillkoren i stället för undantagslistan, så en enkel uppsägning inom den tidsramen bör ge rätt till återbetalning utan de extra villkor som gäller för VPS- eller domänköp.

Funktioner

• Automatisk identifiering av ramverk och Node-version
• Verktyg för att skapa en managed MySQL-databas
• Global CDN aktiverad som standard
• WAF- och DDoS-skydd ingår
• Dagliga och on-demand-backuper
• Malware-scanner och vulnerability-scanning
• GitHub-integration med auto-deploy
• Fri domän, e-post och SSL
• SSH-åtkomst för avancerade användare

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

Prestanda

Eftersom Web Apps Hosting är helt managed får du aldrig shell-åtkomst till en server, så det finns ingen CPU, RAM eller disk att benchmarka direkt på samma sätt som i en VPS-recension.

Det du kan mäta är hur snabbt den deployade appen själv laddar och svarar, från verkliga platser runt om i världen. Jag testade detta från fyra olika vinklar: GTmetrix från två kontinenter, en global konsekvenskontroll med 50+ punkter och Hostinger’s egen inbyggda hastighetsmätare för både desktop och mobil.

Appen som testades är den Next.js-deploy som täcks i avsnittet om Användarvänlighet nedan, live på ivory-llama-856835.hostingersite.com, körande på Cloud Startup-planen (4 CPU cores, 4096 MB RAM, 100 GB NVMe storage), med CDN aktiv som standard.

1. GTmetrix, testat från två kontinenter

Jag körde GTmetrix två gånger från olika delar av världen för att se om resultatet höll sig konsekvent eller bara såg bra ut från en lycklig synvinkel.

Båda körningarna landade på perfekta 100% för både Performance och Structure, med noll layout shift och noll blocking time i båda lägena, vilket innebär att inget på sidan konkurrerade om webbläsarens uppmärksamhet eller hoppade runt under laddning.

Den riktigt intressanta detaljen är att Frankfurt faktiskt slog Chicago på varje tidsmätning, trots att jag medvetet valde en amerikansk serverplats för den här appen. Det resultatet går bara ihop med CDN.

När ett CDN är aktivt, vilket det var här som standard, når din besökare inte nödvändigtvis direkt till origin-servern.

De når närmaste cachade edge-nod, så en europeisk testpunkt kan sluta snabbare än en amerikansk även när själva servern står i USA. Detta är en verklig, praktisk bekräftelse på att Hostinger’s standardaktiverade CDN faktiskt gör nytta och inte bara är en marknadsföringspunkt.

2. Global konsekvens (Check-Host)

Jag körde en HTTP-kontroll mot live-URL:en från varje kontrollpunkt som Check-Host erbjuder, 54 platser över sex kontinenter. Hela bilden:

Varje lyckad kontroll returnerade ett rent 200 OK, inga fel, inga delvisa misslyckanden, inga oväntade omdirigeringar.

Svarstiderna berättade en tydlig historia om hur CDN-cachning beter sig på verkliga avstånd:

Europeiska kontrollpunkter gav genomgående de snabbaste tiderna, flera under 50 millisekunder, medan kontrollpunkter fysiskt längst bort från någon edge-nod, Tokyo, Singapore, Ho Chi Minh City, fortfarande returnerade giltiga 200-svar, bara långsammare, i spannet 0.3 till 0.8 sekund.

Det är den förväntade formen för en CDN-baserad deploy: snabb nära noderna, fortfarande fullt fungerande långt ifrån dem.

De fyra timeoutsen, Kazakhstan, Romania och två av de fyra ryska kontrollpunkterna, är inte något jag skulle läsa som ett problem med Hostinger’s infrastruktur.

Andra kontrollpunkter i samma länder lyckades (Saint Petersburg kom tillbaka rent på 0.063s medan två Moskva-kontroller timeade ut), vilket pekar på regional nätverksfiltrering på kontrollpunktens sida snarare än något fel med den deployade appen.

3. Hostinger’s eget hastighetsverktyg, desktop och mobil

Hostinger kör sitt eget Page Speed-test direkt i appens dashboard, så jag jämförde dess siffror med de oberoende GTmetrix-resultaten i stället för att ta något av dem för givet ensamt.

Båda enhetstyperna fick perfekta 100, och desktop-siffrorna ligger nära det som GTmetrix oberoende mätte, vilket är själva poängen med att köra båda. Två olika verktyg, två olika metoder, och de är överens med varandra.

Mobil kom in långsammare över varje tidsmätning, som väntat på en simulerad långsammare anslutning och svagare processor, men fortfarande tillräckligt snabbt att ett 100-poängsresultat speglar verkligt stark mobil prestanda, inte bara en generös bedömningskurva.

En inkonsekvens i själva verktyget. Trots att poängen är en ren 100 på båda enheterna flaggar Diagnostics-panelen under det fortfarande några radobjekt med en bokstavlig 0-poäng, network dependency tree, document request latency och avoiding multiple redirects, tillsammans med två objekt som fick 50, unused JavaScript och legacy JavaScript.

Inga av dessa låga delpoäng drog ner huvudpoängen, så se dem som mindre, faktiskt existerande optimeringsmöjligheter snarare än något fel på deploymenten.

Separat är de “helpful links” som Hostinger visar bredvid dessa diagnostics alla skrivna för WordPress, “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, trots att detta är en Node.js-app utan WordPress inblandat i någon del av stacken. Det är en rest från en delad diagnostics-mall snarare än innehåll byggt för den här produkten.

Sammanfattande omdöme om prestanda

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

Användarvänlighet

Jag testade Hostinger’s Web Apps Hosting från landningssidan genom kassan, och sedan från ett kallt konto till en fullt live, fungerande Node.js-deploy.

Det innefattade att välja plan, betala, välja hur man skulle bygga, koppla GitHub och se builden slutföras i realtid. Så här var den processen faktiskt.

1. Registrering

Jag började på landningssidan för Web Apps Hosting, som leder med en enda call to action: Start deploying.

Att klicka på den öppnar inte ett registreringsformulär. Det scrollar dig direkt ner till prisavsnittet, så det första verkliga beslutet du tar är vilken plan du ska köpa, inte vilka kontouppgifter du ska fylla i.

Två planer stod sida vid sida:

Jag valde Cloud Startup för dubbelt app-utrymme och mer CPU-utrymme än instegsnivån. En liten inkonsekvens att notera här: prissidan kallar det “Cloud Startup”, men när det hamnar i varukorgen etiketteras samma plan som “Startup plan”. Inte ett funktionellt problem, bara en namngivningsskillnad mellan två skärmar i samma checkout-flöde.

Varukorgen var ren. Den listade 48-månadersperioden, besparingen, en fri domän i ett år och fria mailboxar, och erbjöd sedan en upsell, Hostinger Reach e-postmarknadsföring, i en egen markerad ruta i stället för att vara förvald.

Jag hoppade över den och klickade Continue utan friktion.

Om du är en ny kund snarare än en befintlig lägger kassan in ett steg för att skapa konto här innan du når sidan för faktureringsadress och betalning.

Härnäst lägger du till en faktureringsadress, väljer betalningsmetod, kort, PayPal eller någon av de andra alternativen, och skickar in. Jag fick ett bekräftelsemejl för köpet inom några ögonblick efter att ha klickat Submit payment, och landade sedan direkt i hPanel med planen redan provisionerad.

Vad jag tyckte: Kassan är kort och upsellen är lätt att tacka nej till utan att behöva leta efter en dold skip-länk. Plan-namngivningsskillnaden mellan prissidan och varukorgen är en liten sak, men det är just den typen av detalj som får en förstagångsköpare att pausa och dubbelkolla att de valde rätt nivå.

2. Dashboard

När din betalning går igenom landar du i hPanel, Hostinger’s egen in-house-kontrollpanel som den byggt för att hantera varje produkt den säljer, inte en sida som är byggd specifikt kring din nya Web App.

Sidan du landar på först är Home, och den är byggd kring ett AI-promptfält högst upp: “Hi, [your name]! How can I help you today?” med ett textfält under och sex genvägsknappar: Get domain, Create website, Get email, Migrate site, Get VPS, och Try email marketing.

Scrollar du förbi det hittar du:

• Funktionspromotionsrutor för AI Builder, onlinebutiksverktyget, som påstår gratis företagse-post, AI-agenter, en automationsapp och att de ger en fri domän
• En att-göra-checklista som puffar dig mot uppsättningsuppgifter, slutföra Reach-uppsättningen, hämta din fria e-post, hämta din fria domän
• Your business, en löpande lista över varje sajt, app och VPS-instans kopplad till ditt konto, var och en med sin egen Manage site knapp
• VPS, en separat tabell längre ner som listar eventuella VPS-instansers IP-adress, status och utgångsdatum

En Agent panel sitter också permanent i det övre högra hörnet på varje hPanel-sida, inte bara Home. Det är samma Kodee-assistent som används för support, men placerad här som ett allmänt action-verktyg med färdiga prompts som “Deploy my Node.js app” eller “Harden VPS updates” som du kan köra utan att skriva en hel fråga själv.

Home är faktiskt användbar när din app redan finns, allt i Your business länkar direkt till den. Men det är inte där du går för att skapa en ny Web App eller för att nå Setup-knappen. För det behöver du en annan väg via sidomenyn:

1. Klicka på Websites i vänstra sidomenyn
2. En undermeny fälls ut under den: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Klicka på Web Apps

Det klicket tar dig till en helt annan skärm än Home, en som är organiserad kring dina faktiska hostingplaner snarare än ett promptfält.

Här får varje plan du äger sitt eget kort. På mitt konto betydde det tre kort staplade vertikalt:

Business -kortet hade också redan en live-app listad under sig från tidigare tester, orange-walrus-700988.hostingersite.com, med sina egna Tools- och Dashboard-knappar.

Det är i sig en användbar sak att notera. När en Web App väl finns växer dess kort med en rad som denna som visar den live sajten direkt, vilket är exakt hur ditt Cloud Startup-kort kommer att se ut när du har slutfört uppsättningen.

Eftersom Cloud Startup var planen jag just köpt och ännu inte satt upp, visade dess kort i stället en enda Setup knapp. Det är den knappen som faktiskt startar guiden för att skapa Web App, och den visas bara här, under Websites → Web Apps, inte från Home-skärmen du landar på som standard.

Vad jag tyckte: hPanel är tydlig när du väl hittar rätt skärm, men Web Apps Hosting har ingen uppenbar huvudentré. Att landa på Home ger dig ett promptfält och genvägar, inte en väg till att skapa en app; du måste veta att du ska klicka på Websites, sedan Web Apps, innan Setup ens visas. Det är några extra klick för en produkt som säljs som “live på en minut”. När du väl är där är dock plan-korten rena och ärliga om status, och en plan med en app redan igång visar det direkt på kortet.

3. Deploy av appen

Att klicka på Setup på plan-kortet öppnade ett kort onboarding-flöde: Where would you like to start? med tre alternativ, Create a new site, Migrate an existing site, eller I hired someone to build my site. Jag valde Create a new site.

Det ledde till How do you want to build your website?, uppdelat i två nybörjarvänliga alternativ högst upp, Hostinger AI Builder och WordPress + AI, och två alternativ under en separat rubrik för “for advanced users” nedan: Node.js web app och PHP/HTML website. Att välja Node.js web app är det som faktiskt placerar dig på själva Web Apps Hosting-produkten.

Detta är en verklig strukturell notering för alla som jämför produkter: Web Apps Hosting har inte sitt eget dedikerade registreringsflöde.

Det är en gren i samma allmänna webbplats-skaparguide som används för AI Builder och WordPress.

Jag klickade på cirkeln bredvid Node.js web app, och sedan på Next.

Därifrån:

• Domänskärm: Jag valde Use temporary domain i stället för att binda en riktig, eftersom detta var en testdeploy.

• Serverplats-skärm: Hostinger hade förvalt France, den närmaste regionen till mitt faktureringsland, och visade 167ms latens. Om man scrollade till alternativet United States visades 364ms, mer än dubbelt så mycket.

Jag valde ändå United States, Massachusetts, och detta är exakt den läxa platsväljaren lär ut på alla Hostinger-produkter: välj baserat på var dina faktiska besökare finns, inte på det lägsta talet i listan.

Min testsidas avsedda publik är baserad i USA, så en server i USA kommer faktiskt att leverera till dem snabbare än en server i France någonsin skulle göra, oavsett vad platsväljaren visade mig från min egen plats. Siffran på skärmen berättar hur snabbt servern svarar på Hostinger’s test, inte hur snabbt den kommer att svara personerna som faktiskt ska använda din sajt.

• Deploy-metod-skärm: två huvudalternativ, Import Git repository (märkt Recommended) eller Upload your files, plus en callout nedan för att deploya direkt från Claude Code, Cursor eller VS Code genom Hostinger Connector. Jag valde Import Git repository och klickade Connect with GitHub.

Det öppnade ett riktigt GitHub-inloggningsfönster om du inte redan var inloggad, därefter en behörighetsskärm med titeln Install & Authorize Hostinger, som bad dig välja mellan:

• Att installera på all repositories du äger, inklusive framtida, med read-only-åtkomst till offentliga repos
• Att installera på only select repositories som du väljer individuellt och som listar de exakta behörigheter som ges: read access till actions, metadata och repository hooks, samt read-and-write access till administration, code och pull requests. När du klickar på Install & Authorize skickar GitHub dig automatiskt tillbaka in i hPanel.

Du landar på Select Git repository to import, en scrollbar lista över varje repo kopplat till ditt GitHub-konto, vart och ett med en egen Deploy-knapp bredvid. Jag hittade test-repot jag tidigare pushat, hostadvice-webapps-test, och klickade Deploy bredvid det.

Från att jag klickade på den knappen tog det nära 30 sekunder utan någon progressindikator på skärmen innan nästa sida laddades, tillräckligt länge för att man skulle kunna undra om klicket registrerades överhuvudtaget.

Sidan som till slut laddas heter Review build settings, och den berättar exakt var din app kommer att bo innan du åtar dig något: “Deploys to ivory-llama-856835.hostingersite.com.” Nedanför, utan att du rört ett enda fält, hade den redan automatiskt identifierat:

Var och en av dessa fem rader har sin egen Change eller Add knapp bredvid sig, så inget här är låst om identifieringen skulle få något fel.

Jag klickade på Add bredvid Environment variables och ställde in ett nyckel-värde-par för att bekräfta att det faktiskt skulle nå den körande appen senare, klickade sedan på Finish i den dialogen, och klickade sedan på huvudknappen Deploy nederst på sidan.

Att följa builden

Skärmen växlar till en Deploying… vy med en märkt progressbar, “Deployment from GitHub”, som stegvis ökade, jag såg den gå genom 28%, sedan 51%, på väg mot slutförande. Under progressbaren finns en utfällbar panel Build logs, och när man öppnar den visas verklig, live terminalutmatning medan den händer, inte en platsbriks-spinnare:

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

Deploying slutförd

När builden är klar landar du på en Deployment completed! skärm med en live-miniatyrförhandsvisning av din faktiska körande app direkt i kortet, bredvid en sammanfattning som visar repo-namnet och den tilldelade live-URL:en.

Från denna sida kan du klicka direkt vidare till Go to dashboard, där du sedan hanterar appen.

Vad jag tyckte: Automatisk identifiering är det starkaste här. Ramverk, branch och Node-version blev alla rätt utan ett enda manuellt fält, och den live build-loggen gör väntan transparent snarare än ogenomskinlig. Den svaga punkten är det där 30-sekundersglappet innan du ens når inställningssidan, tillräckligt långt för att man ska undra om något hängt sig innan processen synligt börjar.

4. Bekräfta den live deployen

Innan jag utforskade några av hanteringsverktygen ville jag bekräfta att appen faktiskt hade deployats och fungerade, inte bara markerats som “Completed” på skärmen.

Från sidan Deployment completed klickade jag direkt vidare till live-URL:en, ivory-llama-856835.hostingersite.com, i stället för att enbart lita på dashboardens förhandsvisningsminiatyr.

Den live sidan laddades och visade exakt det som appen var kodad att visa:

• Server build time, en live-tidsstämpel som bekräftar att sidan byggdes färskt, inte levererades från en gammal cache
• Environment variable check, som visade den anpassade variabeln jag satte under deploy-skärmen, korrekt bekräftad på den faktiska live-sidan, inte bara i dashboard-förhandsvisningen

Jag klickade sedan appens egen knapp Ping the API route, som anropar en live backend-endpoint i stället för att bara rendera statiskt innehåll. Den returnerade ett rent JSON-svar:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Det svaret betyder mer än det kanske ser ut som. En sida som laddar korrekt bevisar bara att de statiska filerna uppladdades.

Ett fungerande API-anrop bevisar att den faktiska Node.js-servern körs under ytan och svarar på riktiga förfrågningar, den del av “Node.js web app”-hosting som är lätt att fejka med en statisk fil och svår att fejka med en live servers tidsstämpel som genereras i exakt det ögonblick du klickar på en knapp.

Vad jag tyckte: Det här är kontrollen jag skulle rekommendera dig att göra innan du litar på någon deploy på den här plattformen, eller på någon liknande. En grön status “Completed” och en förhandsvisningsminiatyr säger att builden är klar. Att klicka sig vidare till live-URL:en och trigga något dynamiskt, ett API-anrop, en databasläsning, vad som helst som inte kan fejkas av en cachad statisk sida, visar att servern faktiskt lever och gör det du byggde den för att göra.

5. Web App-hantering

När den live appen var bekräftad fungerande gick jag tillbaka in i hPanel och utforskade appens egna hanteringsdashboard från början till slut, det faktiska serverhanteringslagret för denna produkt, separat från den allmänna hPanel Home-skärmen som täcktes tidigare.

Dashboard-översikt. I samma ögonblick du landar här visar fyra statusbrickor läget på ett ögonblick:

Alla fyra var gröna som standard, utan att jag behövde slå på något manuellt. Under detta finns ett kort för Last deployment som bekräftar status, repo, författare, commit, deploy-tid, identifierad stack och Node-version, allt du vill verifiera snabbt utan att gräva i loggar.

Ett automatiskt Page Speed test hade redan körts mot den live sajten av sig självt och gav en 99/100 Desktop-poäng utan att jag själv triggat det, bredvid en panel Essentials med snabblänkar till databasanslutning, backuper, file manager, runtime logs och cache.

Deploys, miljövariabler och loggar. Tre separata sidor täcker detta:

• Deployments behöll en fullständig historik över pushen, författare, branch, commit-hash och slutförandestatus, en riktig historik snarare än bara den senaste
• Environment variables listade korrekt den jag satte under deployen, vilket bekräftar att den lagrades och tillämpades, inte bara visades en gång under uppsättningen och glömdes bort
• Runtime logs strömmade live serverutdata medan det hände, Next.js-startlinjer, ready-tidsstämplar och en löpande räkning av issues och errors, som låg på noll och noll hela tiden jag tittade

Säkerhet. Malware Scanner gav ett rent resultat, “Your website is safe”, med en tydlig caveat: den kontrollerar bara webbplatsfiler, inte databasinnehåll, och det finns en betald rensningsoption om du vill ha en djupare kontroll som även inkluderar databasen. Vulnerabilities -skanningen var också ren.

Databaser. Det här är där produktens egen marknadsföring skapar ett verkligt glapp som du bör förstå innan du köper. Planen annonserar managed MySQL som en huvudfunktion, men ingenting provisioneras automatiskt åt dig.

Databasavsnittet öppnas med ett manuellt formulär Create a New MySQL Database And Database User, vilket innebär att du själv namnger och skapar databasen innan appen kan använda en. Jag bekräftade detta direkt med Kodee, vilket täcks i supportavsnittet nedan, och svaret var rakt: managed betyder att Hostinger driver databasens infrastruktur bakom kulisserna, inte att en databas skapas åt dig i samma ögonblick som din app går live.

Avancerad åtkomst. SSH-åtkomst finns under Advanced, komplett med IP, port och användarnamn, men står Inactive som standard och måste aktiveras manuellt innan du kan använda den. File Manager erbjuder ett val mellan att bläddra bara i den här appens filer eller i alla filer över hela hostingplanen.

Vad jag tyckte: Den dagliga dashboarden är genomarbetad och välorganiserad. Särskilt säkerhet och deployhistorik är lätta att hitta och faktiskt informativa, och runtime-loggen utan problem tillsammans med en ren malware-scanning gav mig verkligt förtroende för att appen mådde bra, inte bara var online.

Den enda plats där gränssnittet översäljer sig självt är databassektionen, där “managed MySQL” på plansidan låter som något som väntar färdigt när din app går live, medan du i praktiken får ett kontrollpanel för att skapa en själv.

Sammanfattande omdöme om användarvänlighet

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

Jag testade Hostinger’s support för Web Apps Hosting genom Kodee, AI-assistenten inbyggd i hPanel, och gick sedan igenom kunskapsbasen för att se hur mycket den täcker utan att man behöver fråga någon. Kodee visas på två ställen som är värda att skilja åt: som Ask AI på den publika marknadsföringssidan, och som en Agent panel tillgänglig från vilken sida som helst i hPanel, inklusive direkt på Web Appens egen dashboard.

1. AI-support (Kodee)

Jag ställde två frågor byggda kring verkliga luckor jag hittat under testningen, inte generiska sökningar som Kodee kunde svara på genom att klistra in dokumentation.

Fråga 1 testade beteende vid misslyckad deploy och timing för miljövariabler, båda verkliga produktionsfrågor för alla som skickar till den här 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 svarade direkt och korrekt på båda punkterna. En misslyckad build ersätter inte en app som redan körs; om en tidigare deploy lyckades fortsätter appen att leverera den senast fungerande versionen. Om det är den första deployen och det inte finns något att falla tillbaka på, går appen ner tills builden är fixad och deployas igen, ett tydligt, ärligt svar snarare än en vag försäkran.

Om miljövariabler bekräftade den att du kan ställa in dem innan den första deployen i deploy-inställningarna, och för en redan körande app gick den igenom de exakta tre stegen: öppna Settings and Redeploy, lägg till eller redigera variabler under Environment variables, spara och redeploya.

Fråga 2 tryckte på de två luckor jag själv hade hittat i dashboarden, formuleringen “managed MySQL” mot formuläret för manuell skapelse, och SSH som står 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’s svar bekräftade exakt det jag hade sett i gränssnittet, inte en mjukare version av det. En databas skapas inte automatiskt för varje Web App; “managed” syftar på att Hostinger driver databastjänsten och infrastrukturen, medan skapandet och konfigurationen av själva databasen är upp till dig, via samma skärm Create a New MySQL Database jag redan hade sett, följt av att du själv lägger till anslutningsuppgifterna i appens miljövariabler.

Om SSH bekräftade den att det inte förändrar hur appen körs, deployas eller ansluter till en databas att låta det förbli inaktivt. Det är placerat enbart som ett valfritt verktyg för CLI-kommandon, migreringar eller direkt felsökning av filer, inte något som plattformen i hemlighet är beroende av i bakgrunden.

Vad jag tyckte: Båda svaren stämde med det jag redan verifierat manuellt i dashboarden i stället för att motsäga eller förmildra det, vilket är kännetecknet på ett supportverktyg som faktiskt kontrollerar produktens verkliga status i stället för att recitera ett manus. Ingen av frågorna kunde besvaras genom att bara klistra in från en generell FAQ, och Kodee hanterade båda med specifika, strukturerade, tvådelade svar inom ungefär en minut vardera.

2. Kunskapsbas

Hostinger’s kunskapsbas öppnar på ett kategoriserat rutnät, 20 kategorier totalt, där varje visar ett artikelantal. Några av de största: AI Builder har 330 artiklar, VPS har 276, Email har 127 och Website har 103.

Web Apps Hosting får ingen egen dedikerad kategori. Dess innehåll ligger utspritt över Getting Started, hPanel och Website i stället, vilket är en verklig observation för alla som förväntar sig ett enda dedikerat hem, på samma sätt som VPS eller Email får det.

Att söka efter “Web Apps” direkt gav 71 resultat över 8 sidor. De översta resultaten var en blandning av direkt relevanta och bara löst relaterade artiklar:

• How to deploy apps built with Codex on Hostinger, direkt relevant
• Hostinger AI Builder: How to create a web app in agentic mode, närliggande men annan produkt
• How to add a Node.js Web App in Hostinger, direkt relevant
• How to install Flutter Web on a VPS at Hostinger, en annan produkt helt och hållet
• Flera Website Builder-artiklar om betalningsmetoder (PayPal, WeChat Pay, BLIK), orelaterade bortsett från att de delar orden “web” och “app” någonstans i texten

Jag öppnade ett av toppresultaten, How to deploy apps built with Codex on Hostinger, för att kontrollera dess djup. Det visade sig vara en grundlig, välstrukturerad genomgång, med stödjande ramverk listade i början, steg-för-steg-skärmdumpar för både GitHub-import och ZIP-uppladdning, ett avsnitt om att konfigurera build-inställningar med exempelkommandon, en genomgång av filstrukturen efter deploy, en databasanslutningsguide, ett avsnitt om vulnerability monitoring och ett avslutande FAQ-block.

Även om det är inramat kring Codex specifikt är den underliggande plattformen samma som bakom den generella Node.js Web App-produkten, så det mesta gäller direkt.

Vad jag tyckte: Artikelantalet i sök ser starkt ut på papper, 71 träffar för ett ord, men en betydande del av volymen är brus från orelaterade produkter som delar liknande formulering. Artikeln jag öppnade i sin helhet höll god kvalitet när jag väl kom in i den, tydliga steg, riktiga skärmdumpar och ett genuint FAQ-avsnitt, men att hitta den krävde att man scrollade förbi resultat som inte hade något med det jag faktiskt försökte deploya att göra.

Sammanfattande omdöme om kundsupport

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

Rekommenderar vi Hostinger Web Apps Hosting?

Ja. Deploy-processen är den starkaste delen av produkten: korrekt automatisk identifiering av min stack, branch och Node-version, en verklig streaming build-logg i stället för en spinner, och en live app som klarade varje prestandatest jag kastade på den, perfekta GTmetrix-resultat från två olika kontinenter, en ren global konsekvenskontroll med 54 punkter och matchande 100/100-poäng från Hostinger’s egna verktyg på både desktop och mobil. Kodee backade upp detta med korrekta, specifika svar på verkliga tekniska frågor snarare än generiska scriptsvar.

De skavanker som finns är små men värda att känna till innan du köper. “Managed MySQL” låter på plansidan som något som är redo i samma stund som din app går live, och i praktiken betyder det ett manuellt skapelseformulär. Dashboarden ger också Web Apps Hosting ingen dedikerad ingång från huvudskärmen Home; du måste veta att du ska klicka in på Websites först.

För en utvecklare som vill ha en snabb, ramverksagnostisk deploy på infrastruktur som benchmarkar så här bra är detta en enkel rekommendation. För någon som förväntar sig att varje utlovad funktion är påslagen i samma ögonblick som kassan är klar, budgetera några extra minuter för att sätta upp databasen själv.

Hostinger

5.0

2,471 user reviews

16 kr /mo

Utgångspris

Besök Hostinger

Rating based on expert review

• Användarvänligt
  4.9
• Support
  4.9
• Funktioner
  4.8
• Pålitlighet
  4.7
• Priser
  4.5