Hostingers eigens entwickelte Web Apps Hosting dreht sich um ein einfaches Versprechen: Schiebe deinen Code von GitHub, einer ZIP-Datei oder deinem KI-Coding-Agenten aus bereit und erhalte in etwa einer Minute eine Live-Produktiv-App, ganz ohne Server, um den du dich kümmern musst. Ich wollte wissen, wie viel davon tatsächlich Bestand hat, wenn man selbst auf Deploy klickt, also habe ich Folgendes herausgefunden.

Web Apps schneller bereitstellen mit Hostinger

Stelle moderne Web-Apps auf Hostinger mit automatisierten Builds, verwalteter Infrastruktur, globalem CDN, SSL, Sicherheitstools und einer 30-tägigen Geld-zurück-Garantie bereit.

Hostinger besuchen

Vor- und Nachteile

Bewertungsaufteilung

Um Hostingers Web Apps Hosting zu bewerten, habe ich die Bewertungsmethodik von HostAdvice angewendet, denselben standardisierten Ansatz, der bei jeder Rezension auf der Seite verwendet wird, damit die Bewertungen auf echter Prüfung statt auf Marketing-Sprache beruhen. So schnitt es in den einzelnen Parametern ab.

Hoste deine Web-Apps ohne DevOps-Aufwand

Stelle moderne Webanwendungen mit automatisierten Deployments, verwaltetem SSL, globalem CDN und integrierten Sicherheitstools bereit.

Hostinger besuchen

Tarife und Preise

Hostinger verkauft Web Apps Hosting in zwei Stufen, Business und Cloud Startup, die beide speziell für die Bereitstellung von Node.js- und modernen JavaScript-Apps statt für klassisches Website-Building entwickelt wurden.

Cloud Startup, die Stufe, die ich getestet habe, verdoppelt die App-Anzahl und die CPU-Kerne gegenüber Business, und beide Pläne bündeln eine kostenlose Domain, eine kostenlose Business-E-Mail und verwaltetes SSL für das erste Jahr direkt im Checkout.

Ein paar Dinge, die du vor der Bestellung wissen solltest:

• Geld-zurück-Garantie: Web Apps Hosting fällt unter Hostingers standardmäßige Hosting-Rückerstattungsbedingungen, also ein einfaches 30-Tage-Fenster ab dem Kaufdatum. Das ist deutlich unkomplizierter als bei Hostingers VPS-Plänen, bei denen zusätzlich eine 180-Tage-Abkühlphase zwischen Rückerstattungsanträgen gilt. Für diesen Tarif gilt keine solche Abkühlphase.
• Kostenlose Testphase: Ich habe keine dedizierte kostenlose Testphase gefunden. Die 30-Tage-Geld-zurück-Garantie ist stattdessen dein Bewertungszeitraum.
• Zahlungsmethoden: Im Checkout war Kartenzahlung als Standardmethode ausgewählt, mit Visa-, Mastercard-, Amex- und Discover-Logos sowie der Option, während des Checkouts eine andere Zahlungsmethode hinzuzufügen.
• Was enthalten ist: Eine kostenlose Domain für ein Jahr, kostenlose Mailboxen für ein Jahr und verwaltetes SSL sind alle ohne Zusatzkosten im Preis enthalten, sodass der angezeigte Preis den tatsächlichen Aufwand, eine vollständig funktionierende, abgesicherte Bereitstellung live zu bringen, ziemlich genau widerspiegelt.
• Das einzige Upsell: Hostinger Reach, ein E-Mail-Marketing-Add-on, erscheint im Warenkorb als eigene hervorgehobene Box mit separatem Monatspreis. Es ist leicht zu überspringen und wird standardmäßig weder gebündelt noch vorausgewählt.

Wenn du einen Web Apps Hosting-Tarif innerhalb von 30 Tagen kündigst, bestätigt Hostingers Rückerstattungsrichtlinie, dass er unter die Standardbedingungen fällt, sodass eine einfache Kündigung innerhalb dieses Fensters für eine Rückerstattung qualifizieren sollte, ohne die zusätzlichen Bedingungen, die für VPS- oder Domain-Käufe gelten.

Features

• Automatische Erkennung von Framework und Node-Version
• Verwaltungstools zur Erstellung von MySQL-Datenbanken
• Globales CDN standardmäßig aktiv
• WAF- und DDoS-Schutz inklusive
• Tägliche und manuelle Backups
• Malware-Scanner und Vulnerability-Scanning
• GitHub-Integration mit Auto-Deploy
• Kostenlose Domain, E-Mail und SSL
• SSH-Zugriff für fortgeschrittene Nutzer

Von Code zur Live-App mit Hostinger

Verbinde dein GitHub-Repository oder lade dein Projekt hoch und bringe es mit verwalteter Infrastruktur, automatischen Deployments und täglichen Backups online.

Hostinger besuchen

Performance

Da Web Apps Hosting vollständig verwaltet ist, bekommst du nie Shell-Zugriff auf einen Server, sodass es keinen CPU-, RAM- oder Festplattenwert gibt, den man direkt so benchmarken könnte wie bei einer VPS-Rezension.

Messbar ist, wie schnell die bereitgestellte App selbst lädt und reagiert, von realen Standorten auf der ganzen Welt aus. Ich habe dies aus vier verschiedenen Blickwinkeln getestet: GTmetrix von zwei Kontinenten, eine globale Konsistenzprüfung mit über 50 Punkten und Hostingers eigenes integriertes Geschwindigkeitstool für Desktop und Mobilgeräte.

Die getestete App ist das in der Ease-of-Use-Sektion unten beschriebene Next.js-Deployment, live unter ivory-llama-856835.hostingersite.com, laufend auf dem Cloud Startup-Tarif (4 CPU-Kerne, 4096 MB RAM, 100 GB NVMe-Speicher), mit standardmäßig aktiviertem CDN.

1. GTmetrix, von zwei Kontinenten aus getestet

Ich habe GTmetrix zweimal von unterschiedlichen Teilen der Welt aus ausgeführt, um zu sehen, ob das Ergebnis konsistent bleibt oder nur aus einem glücklichen Blickwinkel gut aussieht.

Beide Läufe erreichten sowohl bei Performance als auch bei Structure perfekte 100 %, mit null Layout-Verschiebung und null Blocking Time an beiden Standorten, was bedeutet, dass nichts auf der Seite mit dem Browser um Aufmerksamkeit konkurrierte oder beim Laden herumhüpfte.

Das wirklich interessante Detail ist, dass Frankfurt Chicago bei allen Timing-Metriken übertraf, obwohl ich bewusst einen US-Serverstandort für diese App gewählt hatte. Dieses Ergebnis ergibt nur mit Blick auf das CDN Sinn.

Sobald ein CDN aktiv ist, wie es hier standardmäßig der Fall war, erreicht dein Besucher nicht unbedingt direkt den Origin-Server.

Er erreicht den nächstgelegenen gecachten Edge-Knoten, sodass ein europäischer Testpunkt am Ende schneller sein kann als ein US-amerikanischer, selbst wenn der eigentliche Server in den USA steht. Das ist eine echte, praktische Bestätigung dafür, dass Hostingers standardmäßig aktiviertes CDN tatsächlich nützliche Arbeit leistet und nicht nur ein Marketing-Label ist.

2. Globale Konsistenz (Check-Host)

Ich habe einen HTTP-Check für die Live-URL von jedem Checkpoint ausgeführt, den Check-Host anbietet, 54 Standorte auf sechs Kontinenten. Das Gesamtbild:

Jeder erfolgreiche Check lieferte ein sauberes 200 OK, keine Fehler, keine teilweisen Ausfälle, keine unerwarteten Weiterleitungen.

Die Antwortzeiten zeichneten ein klares Bild davon, wie sich CDN-Caching über reale Distanzen verhält:

Europäische Checkpoints lieferten durchgehend die schnellsten Zeiten, mehrere unter 50 Millisekunden, während Checkpoints, die physisch am weitesten von einem Edge-Knoten entfernt waren, Tokio, Singapur, Ho-Chi-Minh-Stadt, weiterhin gültige 200-Antworten lieferten, nur langsamer, im Bereich von 0.3 bis 0.8 Sekunden.

Das ist die erwartete Form einer CDN-gestützten Bereitstellung: schnell an den Rändern, aber auch in größerer Entfernung noch voll funktionsfähig.

Die vier Timeouts, Kasachstan, Rumänien und zwei der vier russischen Checkpoints, würde ich nicht als Problem der Hostinger-Infrastruktur lesen.

Andere Checkpoints in denselben Ländern waren erfolgreich, (Sankt Petersburg meldete sich mit 0.063s sauber zurück, während zwei Moskauer Checkpoints timeouteten), was eher auf regionale Netzwerkfilterung auf Seiten des Checkpoints als auf ein Problem mit der bereitgestellten App hindeutet.

3. Hostingers eigenes Speed-Tool, Desktop und Mobile

Hostinger führt direkt im App-Dashboard einen eigenen Page-Speed-Test aus, also habe ich seine Werte mit den unabhängigen GTmetrix-Ergebnissen verglichen, statt einem von beiden blind zu vertrauen.

Beide Gerätetypen erzielten eine perfekte 100, und die Desktop-Werte stimmen eng mit dem überein, was GTmetrix unabhängig gemessen hat, und genau das ist der Grund, beide zu testen. Zwei verschiedene Tools, zwei verschiedene Methoden, und sie stimmen überein.

Mobile fiel erwartungsgemäß bei allen Zeitmessungen langsamer aus, da ein langsameres Netzwerk und ein schwächerer Prozessor simuliert werden, aber immer noch schnell genug, dass eine 100-Bewertung wirklich starke mobile Praxisperformance widerspiegelt und nicht nur eine großzügige Bewertungslogik.

Eine Inkonsistenz im Tool selbst. Obwohl die Bewertung auf beiden Geräten ein sauberes 100 ist, markiert das Diagnostics-Panel darunter trotzdem einige Punkte mit einer literal 0, network dependency tree, document request latency und avoiding multiple redirects, sowie zwei Punkte mit 50, unused JavaScript und legacy JavaScript.

Keine dieser niedrigen Unterbewertungen hat die Hauptpunktzahl nach unten gezogen, also sieh sie als kleine, tatsächlich vorhandene Optimierungsmöglichkeiten und nicht als Hinweis darauf, dass mit dem Deployment etwas nicht stimmt.

Zusätzlich stammen die “helpful links”, die Hostinger neben diesen Diagnosen anzeigt, alle aus WordPress, “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, obwohl es sich hier um eine Node.js-App ohne jegliches WordPress im Stack handelt. Das ist ein Überbleibsel einer gemeinsamen Diagnostikvorlage und kein speziell für dieses Produkt geschriebener Inhalt.

Gesamturteil zur Performance

Verwaltetes Web-App-Hosting von Hostinger

Konzentriere dich auf den Bau deiner App, während Hostinger Deployment, Infrastruktur, Sicherheit, SSL, Backups und globale Auslieferung übernimmt.

Hostinger besuchen

Benutzerfreundlichkeit

Ich habe Hostingers Web Apps Hosting von der Landingpage bis zum Checkout getestet und dann von einem frischen Konto aus bis zu einer vollständig live geschalteten, funktionierenden Node.js-Bereitstellung.

Dazu gehörte die Auswahl eines Tarifs, das Bezahlen, die Wahl der Build-Methode, das Verbinden von GitHub und das Beobachten des in Echtzeit laufenden Builds. So fühlte sich dieser Prozess tatsächlich an.

1. Registrierung

Ich begann auf der Web Apps Hosting-Landingpage, die mit genau einem Call-to-Action beginnt: Mit dem Deployen beginnen.

Ein Klick darauf öffnet kein Anmeldeformular. Stattdessen scrollst du direkt zum Pricing-Bereich, sodass die erste echte Entscheidung der Kauf eines Tarifs ist, nicht die Eingabe von Kontodaten.

Dort standen zwei Tarife nebeneinander:

Ich wählte Cloud Startup wegen der doppelten App-Kapazität und CPU-Reserve gegenüber der Einsteigerstufe. Eine kleine Inkonsistenz, die ich hier anmerken möchte: Auf der Pricing-Seite heißt es „Cloud Startup“, aber im Warenkorb wird derselbe Plan als „Startup plan“ bezeichnet. Kein funktionales Problem, nur ein Namensunterschied zwischen zwei Screens im selben Checkout-Flow.

Der Warenkorb selbst war sauber. Er zeigte die 48-monatige Laufzeit, die Ersparnis, eine kostenlose Domain für ein Jahr und kostenlose Mailboxen und bot dann ein Upsell an, Hostinger Reach E-Mail-Marketing, in einer eigenen hervorgehobenen Box und nicht vorausgewählt.

Ich übersprang es und klickte ohne Hürde auf Weiter.

Wenn du ein neuer Kunde statt ein Bestandskunde bist, fügt der Checkout an dieser Stelle einen Schritt zur Kontoerstellung ein, bevor du die Rechnungsadresse und die Zahlungsseite erreichst.

Als Nächstes gibst du eine Rechnungsadresse ein, wählst eine Zahlungsmethode, Karte, PayPal oder eine der anderen Optionen, und sendest ab. Ich erhielt innerhalb weniger Augenblicke nach Klick auf Zahlung abschicken eine Kaufbestätigung per E-Mail und landete direkt in hPanel, mit dem bereits bereitgestellten Plan.

Mein Eindruck: Der Checkout ist kurz und das Upsell lässt sich leicht ablehnen, ohne nach einem versteckten Überspringen-Link suchen zu müssen. Die Namensabweichung zwischen Pricing-Seite und Warenkorb ist klein, aber genau die Art von Detail, bei dem ein Erstkäufer kurz innehält und sich vergewissert, dass er den richtigen Tarif gewählt hat.

2. Dashboard

Sobald deine Zahlung durch ist, landest du in hPanel, Hostingers eigenem, intern entwickeltem Control Panel, das dazu gebaut wurde, jedes Produkt zu verwalten, das es verkauft, nicht eine Seite, die speziell um deine neue Web App herum entworfen wurde.

Die erste Seite, auf der du landest, ist Home, und sie ist um eine KI-Eingabeleiste oben herum aufgebaut: „Hi, [dein Name]! How can I help you today?“ mit einem Textfeld darunter und sechs Schnellzugriffen: Get domain, Create website, Get email, Migrate site, Get VPS und Try email marketing.

Wenn du weiter nach unten scrollst, findest du:

• Feature-Promotion-Kacheln für AI Builder, das Online-Shop-Tool, die Behauptung einer kostenlosen Business-E-Mail, AI Agents, eine Automations-App und die Behauptung einer kostenlosen Domain
• Eine To-do-Checkliste mit Hinweisen auf Einrichtungsaufgaben, Reach-Setup abschließen, kostenlose E-Mail beanspruchen, kostenlose Domain beanspruchen
• Dein Business, eine laufende Liste aller Websites, Apps und VPS-Instanzen, die mit deinem Konto verknüpft sind, jeweils mit einer eigenen Schaltfläche Manage site
• VPS, eine separate Tabelle weiter unten mit allen VPS-Instanzen nach IP-Adresse, Status und Ablaufdatum

Ein Agent Bereich sitzt außerdem dauerhaft oben rechts auf jeder hPanel-Seite, nicht nur auf Home. Es ist derselbe Kodee-Assistent, der auch für den Support genutzt wird, hier aber als allgemeines Aktionstool mit vorgefertigten Eingaben wie „Deploy my Node.js app“ oder „Harden VPS updates“, die du ohne vollständige Frage direkt auslösen kannst.

Home ist tatsächlich nützlich, sobald deine App bereits existiert, alles unter Dein Business führt direkt dorthin. Aber dort erstellst du keine neue Web App und findest auch nicht die Setup-Schaltfläche. Dafür musst du einen anderen Weg über die Sidebar gehen:

1. Klicke in der linken Seitenleiste auf Websites
2. Ein Untermenü klappt darunter auf: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Klicke auf Web Apps

Dieser Klick führt dich zu einem völlig anderen Bildschirm als Home, einem, der um deine tatsächlichen Hosting-Tarife herum organisiert ist statt um eine Eingabeleiste.

Hier bekommt jeder von dir erworbene Tarif eine eigene Karte. In meinem Konto bedeutete das drei Karten untereinander:

Die Business Karte hatte darunter außerdem bereits eine Live-App aus früheren Tests, orange-walrus-700988.hostingersite.com, mit eigenen Schaltflächen für Tools und Dashboard.

Das ist schon für sich genommen ein nützlicher Hinweis. Sobald eine Web App existiert, wächst ihre Karte um eine solche Zeile, die die Live-Seite direkt anzeigt, genau so, wie deine Cloud-Startup-Karte aussehen wird, sobald du das Setup abgeschlossen hast.

Da Cloud Startup der Tarif war, den ich gerade gekauft und noch nicht eingerichtet hatte, zeigte seine Karte stattdessen nur eine einzelne Setup Schaltfläche. Das ist die Schaltfläche, die tatsächlich den Web-App-Erstellungsassistenten startet, und sie erscheint nur hier, unter Websites → Web Apps, nicht auf dem Home-Bildschirm, auf dem du standardmäßig landest.

Mein Eindruck: hPanel ist klar, sobald man den richtigen Bildschirm gefunden hat, aber Web Apps Hosting hat keine offensichtliche Startseite. Wenn du auf Home landest, bekommst du eine Eingabeleiste und Schnellzugriffe, aber keinen Weg zur App-Erstellung; du musst wissen, dass du erst auf Websites und dann auf Web Apps klicken musst, bevor überhaupt Setup erscheint. Das sind ein paar zusätzliche Klicks für ein Produkt, das mit „in einer Minute live“ beworben wird. Wenn du dort bist, sind die Tarifkarten jedoch sauber und ehrlich beim Status, und ein Tarif mit bereits laufender App zeigt das direkt auf der Karte an.

3. Die App bereitstellen

Ein Klick auf Setup auf der Tarifkarte öffnete einen kurzen Onboarding-Ablauf: Where would you like to start? mit drei Optionen, Create a new site, Migrate an existing site oder I hired someone to build my site. Ich wählte Create a new site.

Das führte zu How do you want to build your website?, aufgeteilt in zwei einsteigerfreundliche Optionen oben, Hostinger AI Builder und WordPress + AI, sowie zwei Optionen unter einer separaten Überschrift „for advanced users“ darunter: Node.js web app und PHP/HTML website. Die Auswahl von Node.js web app bringt dich tatsächlich erst zum Web Apps Hosting-Produkt selbst.

Das ist ein echter struktureller Hinweis für jeden, der Produkte vergleicht: Web Apps Hosting hat keinen eigenen, dedizierten Signup-Flow.

Es ist ein Zweig innerhalb desselben allgemeinen Website-Erstellungsassistenten, der auch für AI Builder und WordPress verwendet wird.

Ich klickte auf den Kreis neben Node.js web app und dann auf Next.

Von dort aus:

• Domain-Bildschirm: Ich wählte Use temporary domain statt mich auf eine echte Domain festzulegen, da dies ein Test-Deployment war.

• Serverstandort-Bildschirm: Hostinger hatte Frankreich vorab ausgewählt, die Region, die meinem Rechnungsland am nächsten liegt, und zeigte dort 167ms Latenz an. Beim Scrollen zur Option Vereinigte Staaten sah man 364ms, also mehr als doppelt so viel.

Ich wählte trotzdem United States, Massachusetts, und genau das ist die Lektion, die die Standortauswahl bei jedem Hostinger-Produkt vermittelt: Wähle nach dem Ort deiner tatsächlichen Besucher, nicht nach dem kleinsten Wert in der Liste.

Die Zielgruppe meiner Test-App ist in den USA ansässig, also wird ein Server in den USA sie tatsächlich schneller bedienen, als es ein Server in Frankreich jemals könnte, unabhängig davon, was die Auswahl mir von meinem eigenen Standort aus anzeigte. Die Zahl auf dem Bildschirm sagt dir, wie schnell der Server auf Hostingers Test reagiert, nicht wie schnell er auf die Leute reagieren wird, die deine Website tatsächlich nutzen.

• Deploy-Methode-Bildschirm: zwei Hauptoptionen, Import Git repository (als Recommended markiert) oder Upload your files, plus ein Hinweis darunter, dass du direkt aus Claude Code, Cursor oder VS Code über den Hostinger Connector deployen kannst. Ich wählte Import Git repository und klickte auf Connect with GitHub.

Dadurch öffnete sich ein echtes GitHub-Anmeldefenster, falls du nicht bereits eingeloggt warst, und anschließend eine Berechtigungsseite mit dem Titel Install & Authorize Hostinger, auf der du zwischen Folgendem wählen konntest:

• Installation auf allen Repositories, die du besitzt, einschließlich zukünftiger, mit Lesezugriff auf öffentliche Repos
• Installation nur auf ausgewählte Repositories, die du einzeln auswählst, wobei die genauen Berechtigungen aufgelistet werden: Lesezugriff auf Aktionen, Metadaten und Repository-Hooks sowie Lese- und Schreibzugriff auf Administration, Code und Pull Requests. Sobald du auf Install & Authorize klickst, leitet GitHub dich automatisch zurück in hPanel.

Du landest auf Select Git repository to import, einer scrollbaren Liste aller Repositories, die mit deinem GitHub-Konto verbunden sind, jeweils mit einer eigenen Deploy-Schaltfläche daneben. Ich fand das Test-Repository, das ich zuvor hochgeladen hatte, hostadvice-webapps-test, und klickte neben ihm auf Deploy.

Vom Klick auf diese Schaltfläche bis zum Laden der nächsten Seite vergingen fast 30 Sekunden ohne Fortschrittsanzeige auf dem Bildschirm, lang genug, dass man sich fragen könnte, ob der Klick überhaupt registriert wurde.

Die Seite, die schließlich geladen wird, trägt den Titel Review build settings, und sie sagt dir genau, wo deine App leben wird, bevor du irgendetwas bestätigst: „Deploys to ivory-llama-856835.hostingersite.com.“ Darunter hatte sie, ohne dass du ein einziges Feld angefasst hast, bereits automatisch erkannt:

Jede dieser fünf Zeilen hat ihre eigene Schaltfläche Change oder Add daneben, sodass hier nichts festgeschrieben ist, falls die Erkennung etwas falsch macht.

Ich klickte neben Umgebungsvariablen auf Add und setzte ein Key-Value-Paar, um zu bestätigen, dass es später tatsächlich die laufende App erreicht, dann klickte ich im Dialog auf Finish und anschließend auf die Hauptschaltfläche Deploy unten auf der Seite.

Beim Build zuschauen

Der Bildschirm wechselt zu einer Ansicht Deploying… mit einer beschrifteten Fortschrittsanzeige, „Deployment from GitHub“, die in echten Schritten hochzählt; ich sah, wie sie 28%, dann 51% erreichte, auf dem Weg zum Abschluss. Unter der Fortschrittsanzeige befindet sich ein ausklappbares Panel Build logs, und wenn man es öffnet, sieht man echte, live ausgegebene Terminal-Logs, nicht einen Platzhalter-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 abgeschlossen

Sobald der Build fertig ist, landest du auf einem Bildschirm Deployment completed! mit einer Live-Vorschaubildansicht deiner tatsächlichen laufenden App direkt auf der Karte, neben einer Zusammenfassung mit Repository-Namen und der zugewiesenen Live-URL.

Von dieser Seite aus kannst du direkt auf Go to dashboard klicken, wo du die App anschließend verwaltest.

Mein Eindruck: Die automatische Erkennung ist hier das Highlight. Framework, Branch und Node-Version wurden alle korrekt erkannt, ohne dass ich ein einziges Feld manuell ausfüllen musste, und das Live-Build-Log macht das Warten transparent statt undurchsichtig. Die einzige Schwäche ist die 30-sekündige Pause, bevor du überhaupt den Einstellungsbildschirm erreichst, lang genug, dass man sich fragt, ob vorher etwas hängen geblieben ist.

4. Die Live-Bereitstellung bestätigen

Bevor ich irgendein Verwaltungstool anschaute, wollte ich bestätigen, dass die App tatsächlich bereitgestellt wurde und funktionierte, nicht nur im Bildschirm als „Completed“ markiert war.

Von der Seite Deployment completed aus klickte ich direkt auf die Live-URL ivory-llama-856835.hostingersite.com, statt der Vorschauminiatur im Dashboard allein zu vertrauen.

Die Live-Seite lud und zeigte genau das, was die App anzeigen sollte:

• Server build time, ein Live-Zeitstempel, der bestätigte, dass die Seite frisch gebaut wurde und nicht aus einem alten Cache stammte
• Umgebungsvariablen-Prüfung, die die benutzerdefinierte Variable zeigte, die ich während des Deploy-Bildschirms gesetzt hatte, korrekt auf der tatsächlichen Live-Seite bestätigt und nicht nur in der Dashboard-Vorschau

Dann klickte ich auf die Schaltfläche Ping the API route der App, die einen Live-Backend-Endpunkt aufruft und nicht nur statischen Inhalt rendert. Sie gab eine saubere JSON-Antwort zurück:

json

{

  “status”: “ok”,

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

  “nodeVersion”: “v22.18.0”

}

Diese Antwort ist wichtiger, als sie vielleicht aussieht. Eine korrekt ladende Seite beweist nur, dass die statischen Dateien hochgeladen wurden.

Ein funktionierender API-Call beweist, dass der tatsächliche Node.js-Server darunter läuft und auf echte Anfragen antwortet, also genau der Teil von „Node.js web app“-Hosting, der sich leicht mit einer statischen Datei vortäuschen lässt und schwer mit einem live erzeugten Server-Zeitstempel, der genau in dem Moment erstellt wird, in dem man auf eine Schaltfläche klickt.

Mein Eindruck: Das ist die Prüfung, die ich dir vor dem Vertrauen in einen Deploy auf dieser Plattform, oder einer ähnlichen, empfehlen würde. Ein grüner „Completed“-Status und eine Vorschauminiatur sagen dir, dass der Build fertig ist. Wenn du dann zur Live-URL gehst und etwas Dynamisches auslöst, einen API-Call, einen Datenbankzugriff, irgendetwas, das nicht von einer gecachten statischen Seite vorgetäuscht werden kann, weißt du, dass der Server wirklich lebt und das tut, was du gebaut hast.

5. Web-App-Verwaltung

Nachdem die Live-App bestätigt funktionierte, ging ich zurück in hPanel und erkundete das Verwaltungs-Dashboard der App von Anfang bis Ende, die eigentliche Server-Verwaltungsschicht dieses Produkts, getrennt von der allgemeinen hPanel-Home-Seite, die zuvor beschrieben wurde.

Dashboard-Übersicht. Sobald du hier landest, zeigen dir vier Status-Badges auf einen Blick den Zustand:

Alle vier waren standardmäßig grün, ohne dass ich etwas manuell einschalten musste. Darunter befindet sich eine Karte Last deployment, die Zustand, Repository, Autor, Commit, Deploy-Zeit, erkannten Stack und Node-Version bestätigt, also alles, was man auf einen Blick prüfen möchte, ohne in Logs zu graben.

Ein automatischer Page Speed test wurde bereits selbstständig gegen die Live-Seite ausgeführt und lieferte einen Desktop-Score von 99/100, ohne dass ich ihn selbst angestoßen hätte, daneben ein Panel Essentials mit Schnellzugriffen auf Datenbankverbindung, Backups, Dateimanager, Runtime-Logs und Cache.

Deployments, Umgebungsvariablen und Logs. Drei separate Seiten decken dieses Gebiet ab:

• Deployments hielt eine vollständige Aufzeichnung des Pushs, des Autors, des Branches, des Commit-Hashes und des Abschlussstatus fest, also eine echte Historie statt nur der neuesten Bereitstellung
• Environment variables listete korrekt die eine Variable, die ich während des Deployments gesetzt hatte, und bestätigte damit, dass sie gespeichert und angewendet wurde und nicht nur einmal während des Setups angezeigt und dann vergessen wurde
• Runtime logs strömten Live-Serverausgaben in Echtzeit, Next.js-Startzeilen, Bereit-Timestamps und eine laufende Anzahl von Problemen und Fehlern, die während der ganzen Zeit, in der ich zusah, bei null und null blieben

Sicherheit. Der Malware Scanner meldete ein sauberes Ergebnis, „Your website is safe“, mit einem klar benannten Vorbehalt: Er prüft nur Website-Dateien, nicht Datenbankinhalte, und es gibt eine kostenpflichtige Bereinigungsoption, falls du einen tieferen Check möchtest, der auch die Datenbank einbezieht. Der Scan Vulnerabilities kam ebenfalls sauber zurück.

Datenbanken. Hier entsteht eine echte Lücke zwischen Marketing und Realität, die du vor dem Kauf verstehen solltest. Der Tarif wirbt mit Managed MySQL als Kernfeature, aber es wird nichts automatisch für dich angelegt.

Der Abschnitt Databases öffnet sich mit einem manuellen Formular Create a New MySQL Database And Database User, das bedeutet, du benennst und erstellst die Datenbank selbst, bevor deine App eine nutzen kann. Ich habe das direkt mit Kodee bestätigt, worauf im Support-Abschnitt unten eingegangen wird, und die Antwort war eindeutig: „Managed“ bedeutet, dass Hostinger die Datenbank-Infrastruktur im Hintergrund betreibt, nicht, dass eine Datenbank in dem Moment automatisch erstellt wird, in dem deine App live geht.

Erweiterter Zugriff. SSH-Zugriff gibt es unter Advanced, inklusive IP, Port und Benutzername, aber er ist standardmäßig Inactive und muss manuell per Enable aktiviert werden, bevor du ihn verwenden kannst. Der Dateimanager bietet die Wahl, entweder nur die Dateien dieser App oder alle Dateien des gesamten Hosting-Tarifs zu durchsuchen.

Mein Eindruck: Das tägliche Dashboard ist gründlich und gut organisiert. Besonders Sicherheit und Deployment-Historie sind leicht zu finden und wirklich informativ, und das Runtime-Log mit null Fehlern zusammen mit einem sauberen Malware-Scan gab mir echtes Vertrauen, dass die App gesund und nicht nur online war.

Die Stelle, an der die Oberfläche mehr verspricht, als sie liefert, ist die Datenbanksektion, wo „Managed MySQL“ auf der Tarifseite nach etwas klingt, das dir sofort bereitsteht, während du in der Praxis ein manuelles Erstellungsformular bekommst.

Gesamturteil zur Benutzerfreundlichkeit

Web-App-Hosting bauen, deployen und skalieren mit Hostinger

Hoste moderne Web-Apps mit GitHub-Integration, verwaltetem MySQL, globalem CDN, unbegrenzter Bandbreite und integrierten Sicherheitstools.

Hostinger besuchen

Support-Level

Ich habe Hostingers Support für Web Apps Hosting über Kodee getestet, den in hPanel eingebauten KI-Assistenten, und dann die Wissensdatenbank durchgesehen, um zu sehen, wie viel davon ohne Nachfrage abgedeckt wird. Kodee erscheint an zwei Stellen, die man unterscheiden sollte: als Ask AI auf der öffentlichen Marketingseite und als Agent Panel, das in hPanel von jeder Seite aus verfügbar ist, auch direkt auf dem eigenen Dashboard der Web App.

1. KI-Support (Kodee)

Ich stellte zwei Fragen, die auf echten Lücken basierten, die ich während des Tests gefunden hatte, nicht auf generischen Suchen, die Kodee durch einfaches Zitieren aus der Dokumentation hätte beantworten können.

Frage 1 prüfte das Verhalten bei Deploy-Fehlern und den Zeitpunkt von Umgebungsvariablen, beides echte Produktionsfragen für alle, die auf diese Plattform ausliefern:

Wenn der Build meiner App mitten in einem GitHub-Deployment fehlschlägt, kehrt die App dann automatisch zur letzten erfolgreichen Version zurück, oder ist sie offline, bis ich den Fehler behebe und erneut deploye? Und kann ich benutzerdefinierte Umgebungsvariablen schon vor dem ersten Deploy setzen oder erst danach?

Kodee antwortete direkt und korrekt auf beide Punkte. Ein fehlgeschlagener Build ersetzt keine aktuell laufende App; wenn es bereits ein erfolgreiches vorheriges Deployment gibt, bedient die App weiter diese letzte funktionierende Version. Wenn es das erste Deployment ist und es nichts zum Zurückfallen gibt, bleibt die App offline, bis der Build behoben und erneut deployed wird – eine klare, ehrliche Antwort statt einer vagen Beruhigung.

Bei den Umgebungsvariablen bestätigte Kodee, dass man sie vor dem ersten Deploy in den Deployment-Einstellungen setzen kann, und für eine bereits laufende App führte es die genauen drei Schritte auf: Einstellungen öffnen und neu deployen, Variablen unter Environment variables hinzufügen oder bearbeiten, speichern und erneut deployen.

Frage 2 ging auf die beiden Lücken, die ich selbst beim Durchsehen des Dashboards gefunden hatte, die Formulierung „managed MySQL“ im Vergleich zum manuellen Erstellungsformular und SSH, das standardmäßig inaktiv ist:

Dieser Tarif wirbt mit managed MySQL, aber das Dashboard zeigt ein manuelles Formular „Create a New MySQL Database“ statt einer automatisch bereitgestellten Datenbank. Wird für jede Web App standardmäßig eine Datenbank erstellt, oder nur, wenn ich selbst eine anlege? Außerdem ist SSH-Zugriff als verfügbar aufgeführt, zeigt aber standardmäßig Inactive. Wenn ich ihn nie aktiviere, ändert das irgendetwas daran, wie meine App tatsächlich läuft, oder ist SSH nur ein optionales Extra für fortgeschrittene Nutzer?

Kodee bestätigte genau das, was ich bereits in der Oberfläche gefunden hatte, nicht in einer weichgespülten Version. Eine Datenbank wird nicht automatisch für jede Web App erstellt, „managed“ bezieht sich darauf, dass Hostinger den Datenbankdienst und die Infrastruktur betreibt, während das Erstellen und Konfigurieren einer tatsächlichen Datenbank bei dir liegt, über denselben Bildschirm Create a New MySQL Database, den ich bereits gesehen hatte, gefolgt davon, die Verbindungsdaten selbst in die Umgebungsvariablen deiner App einzutragen.

Zu SSH bestätigte es, dass das Inaktivlassen nichts daran ändert, wie die App läuft, deployt oder mit einer Datenbank verbunden wird. Es ist rein als optionales Werkzeug für CLI-Befehle, Migrationen oder direktes Debugging von Dateien gedacht, nicht als etwas, auf das die Plattform im Hintergrund angewiesen ist.

Mein Eindruck: Beide Antworten stimmten mit dem überein, was ich bereits selbst im Dashboard überprüft hatte, statt es zu widersprechen oder abzuschwächen, und genau das ist das Zeichen eines Support-Tools, das tatsächlich den realen Produktstatus prüft statt ein Skript herunterzubeten. Keine der beiden Fragen ließ sich durch das bloße Einfügen aus einer generischen FAQ beantworten, und Kodee löste beide mit spezifischen, strukturierten Antworten in jeweils etwa einer Minute.

2. Wissensdatenbank

Hostingers Wissensdatenbank öffnet sich als kategorisierte Kachelansicht, insgesamt 20 Kategorien, jede mit einer Artikelanzahl. Einige der größten: AI Builder hat 330 Artikel, VPS 276, E-Mail 127 und Website 103.

Web Apps Hosting bekommt keine eigene Kategorie. Der Inhalt ist über Getting Started, hPanel und Website verstreut, was für jeden, der eine eigene zentrale Anlaufstelle erwartet, wie sie VPS oder E-Mail haben, eine echte Erkenntnis ist.

Eine Suche nach „Web Apps“ lieferte direkt 71 Ergebnisse auf 8 Seiten. Die Top-Ergebnisse waren eine Mischung aus direkt relevantem und nur lose verbundenem Inhalt:

• How to deploy apps built with Codex on Hostinger, direkt relevant
• Hostinger AI Builder: How to create a web app in agentic mode, angrenzend, aber ein anderes Produkt
• How to add a Node.js Web App in Hostinger, direkt relevant
• How to install Flutter Web on a VPS at Hostinger, ein anderes Produkt völlig
• Mehrere Website-Builder-Zahlungsmethoden-Artikel (PayPal, WeChat Pay, BLIK), ohne Bezug, außer dass irgendwo im Text die Wörter „web“ und „app“ vorkommen

Ich öffnete einen der Top-Treffer, How to deploy apps built with Codex on Hostinger, um seine Tiefe zu prüfen. Er stellte sich als gründliche, gut strukturierte Anleitung heraus, mit unterstützten Frameworks ganz oben, Schritt-für-Schritt-Screenshots für sowohl den GitHub-Import- als auch den ZIP-Upload-Pfad, einem Abschnitt zur Konfiguration der Build-Einstellungen mit Beispielbefehlen, einer Aufschlüsselung der Dateistruktur nach dem Deployment, einer Datenbankverbindungs-Wizard-Durchlauf, einem Abschnitt zu Vulnerability-Monitoring und einem abschließenden FAQ-Block.

Auch wenn es speziell auf Codex zugeschnitten ist, ist die zugrunde liegende Plattform dieselbe wie beim allgemeinen Node.js-Web-App-Produkt, sodass der größte Teil direkt anwendbar ist.

Mein Eindruck: Die Artikelanzahl bei der Suche wirkt auf dem Papier stark, 71 Treffer für einen Begriff, aber ein erheblicher Teil dieser Menge ist Rauschen aus irrelevanten Produkten mit ähnlicher Wortwahl. Der Artikel, den ich vollständig geöffnet habe, hielt qualitativ stand, klare Schritte, echte Screenshots und ein tatsächlicher FAQ-Abschnitt, aber ihn zu finden erforderte, an Ergebnissen vorbeizuscrollen, die mit dem, was ich eigentlich deployen wollte, nichts zu tun hatten.

Gesamturteil zum Kundensupport

Einfaches Hosting für moderne Web-Apps

Stelle React-, Next.js-, Vue-, Node.js- und andere moderne Anwendungen bereit, ohne Server oder komplexe Infrastruktur verwalten zu müssen.

Hostinger besuchen

Empfehlen wir Hostinger Web Apps Hosting?

Ja. Der Deploy-Prozess ist die stärkste Seite dieses Produkts: korrekte automatische Erkennung meines Stacks, Branches und meiner Node-Version, ein echtes Streaming-Build-Log statt eines Spinners und eine Live-App, die jeden von mir geworfenen Performance-Test bestand, perfekte GTmetrix-Werte von zwei verschiedenen Kontinenten, ein sauberer globaler Konsistenzcheck mit 54 Punkten und übereinstimmende 100/100-Werte aus Hostingers eigenen Tools auf Desktop und Mobile. Kodee untermauerte das mit präzisen, spezifischen Antworten auf echte technische Fragen statt mit generischen Skriptantworten.

Die Schwächen sind klein, aber vor dem Kauf erwähnenswert. „Managed MySQL“ klingt auf der Tarifseite nach etwas, das sofort bereitsteht, wenn deine App live geht, und in der Praxis bedeutet es ein manuelles Erstellungsformular. Außerdem bietet das Dashboard für Web Apps Hosting keinen direkten Einstiegspunkt von der allgemeinen Home-Seite aus; du musst zuerst in Websites wechseln.

Für einen Entwickler, der einen schnellen, framework-agnostischen Deploy auf Infrastruktur möchte, die so gut benchmarkt, ist das eine klare Empfehlung. Wer erwartet, dass jede beworbene Funktion sofort nach dem Checkout aktiviert ist, sollte ein paar zusätzliche Minuten einplanen, um die Datenbank selbst einzurichten.

Hostinger

5.0

2,471 Nutzerbewertungen

1,37 € /mo

Einstiegspreis

Hostinger besuchen

Rating based on expert review

• Benutzerfreundlichkeit
  4.9
• Support
  4.9
• Funktionen
  4.8
• Zuverlässigkeit
  4.7
• Preisgestaltung
  4.5