Das Management von Hosting unterbricht normalerweise die Entwicklung. Man schreibt Code in einem Editor, öffnet ein Hosting-Dashboard, um eine Website zu erstellen, wechselt zu einem Terminal, um das Projekt zu paketieren oder zu pushen, kehrt zum Dashboard zurück, um eine Bereitstellung zu prüfen, und öffnet weitere Tools, wenn DNS, Logs oder Serverressourcen Aufmerksamkeit benötigen.
Hostinger Connector reduziert dieses Hin und Her zwischen Kontexten. Es verbindet Hostinger-Dienste über das Model Context Protocol (MCP) mit KI-Coding-Tools, sodass Sie einen KI-Assistenten bitten können, unterstützte Hosting-Ressourcen zu prüfen oder zu verwalten, ohne Ihren Editor zu verlassen.
Das klingt bequem. Es wirft aber auch eine wichtigere Frage auf: Kann man einer KI vertrauen, reale Hosting-Aufgaben korrekt auszuführen?
Um das herauszufinden, habe ich Hostinger Connector mit VS Code und GitHub Copilot gegen ein echtes Hostinger-Konto getestet. Ich habe eine kleine Express.js-Anwendung namens PulseWatch verwendet und den Workflow von der Installation bis zur Live-Bereitstellung verfolgt. Außerdem habe ich wiederholte Deployments, Build-Aufzeichnungen, Logs und die Wiederherstellung nach absichtlicher Beschädigung des Startbefehls der Anwendung getestet.
So habe ich Hostinger Connector in den Bereichen bewertet, die für Entwickler, die überlegen, ob sie es nutzen sollen, am wichtigsten sind: Kosten, Funktionsumfang, Alltagstauglichkeit, wie genau es reale Aufgaben ausführt, und die Unterstützung dahinter, wenn etwas schiefgeht. Jede Bewertung spiegelt wider, was ich beim Testen tatsächlich gefunden habe, nicht die Marketingseite.
| Parameter | Punktzahl | Warum diese Punktzahl |
|---|---|---|
| Preise | 9.7/10 | Connector kostet überhaupt kein separates Abonnement und ist in jedem Plan kostenlos enthalten. Die einzigen Kosten sind die zugrunde liegenden Hosting-Ressourcen, die Sie ohnehin benötigen würden. |
| Funktionen | 9.5/10 | Der Funktionsumfang reicht über Deployments hinaus bis hin zu Websites, Domains, DNS, Datenbanken, E-Mail-Kampagnen, VPS-Ressourcen, Logs und Diagnosen und deckt mehr ab als ein typisches Deployment-Tool. |
| Einfachheit der Nutzung | 9.1/10 | Installation und OAuth gingen schnell und erforderten keine manuelle Konfiguration, und wiederholte Deployments waren einfach. Das erste Einrichten der Node.js-Website erforderte hPanel, nachdem die KI kein gültiges Ziel identifizieren konnte, die einzige echte Lücke in einem ansonsten reibungslosen Setup. |
| Ausführungsgenauigkeit | 8.5/10 | Projektanalyse, Codebearbeitung, Paketierung, Bereitstellung und Wiederherstellung funktionierten gut. Die KI verwendete erneut eine erfundene Domain und interpretierte eine Barrierefreiheitsprüfung zu weit, bevor dieses Ziel überhaupt existierte. |
| Support | 9.5/10 | Kodee gab auf Anhieb eine genaue, spezifische Antwort auf eine echte technische Frage, und die Antwort des menschlichen Spezialisten war noch präziser. Das Eskalieren erforderte zwei direkte Anfragen, aber sowohl die KI- als auch die menschlichen Antworten waren zuverlässig, sobald sie gegeben wurden. |
| Gesamt | 9.3/10 | Ein nützliches Workflow-Tool für Hostinger-Nutzer, die in KI-gestützten Editoren arbeiten. Es kostet nichts extra, deckt einen breiten Funktionsumfang ab, und sowohl Einrichtung als auch Support hielten im Test stand. Die Ausführungsgenauigkeit bei neuen Deployment-Zielen ist der Punkt, auf den man achten sollte. |
Hostinger Connector wird nicht als eigenständiges Produkt verkauft. Hostinger sagt, dass Connector in jedem Plan kostenlos enthalten ist, was bedeutet, dass keine separate monatliche Connector-Gebühr zu Ihrer Hosting-Rechnung hinzukommt.
„Kostenlos“ braucht jedoch Kontext. Connector verwaltet Hostinger-Ressourcen; es ersetzt sie nicht. Sie benötigen weiterhin einen berechtigten Hosting-, Cloud-, VPS-, Domain-, E-Mail- oder anderen Hostinger-Dienst für die Aufgaben, die es ausführen soll.
Zum Zeitpunkt dieser Bewertung hob die Connector-Landingpage Business Web Hosting und Cloud Startup hervor.
| Plan | Aktionspreis | Gezeigte Vorauszahlungsdauer | Verlängerungspreis | Web-Apps | Websites |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
Preise wurden vor anfallenden Steuern angezeigt. Aktionspreise und Verlängerungsraten können sich ändern. Prüfen Sie daher den aktuellen Gesamtbetrag an der Kasse, statt den Plan nur nach dem beworbenen Monatswert zu beurteilen.
Preis-Leistungs-Einschätzung: Kaufen Sie keinen höheren Plan nur, um Connector zu erhalten. Wählen Sie den Plan anhand der Anzahl der Websites und Web-Apps, die Sie benötigen, der Ressourcen, die sie erfordern, und des Support-Levels, das Sie wünschen. Connector ist eine enthaltene Verwaltungsschicht, nicht das Hauptprodukt, das bepreist wird.
Hostinger bewirbt eine 30-Tage-Geld-zurück-Garantie für berechtigte Hosting-Käufe. Es gibt keine separate Connector-Rückerstattungsrichtlinie zu bewerten, da Connector keine eigenständige Gebühr hat.
Die genauen Aktionen, die verfügbar sind, hängen von den Hostinger-Diensten in Ihrem Konto und den Tools ab, die dem verbundenen KI-Client bereitgestellt werden.
Hostinger dokumentiert auch Ratenlimits. Laut der Connector-FAQ beträgt das Standardkontingent 60 Anfragen pro Minute und 1.000 Anfragen pro Stunde, wobei Informationen zu Ratenlimits in den Antwort-Headern zurückgegeben werden.
Diese Limits sind großzügig für die interaktive Nutzung, obwohl automatisierte oder sehr repetitive Workflows dennoch unnötige doppelte Aufrufe vermeiden sollten.
Bevor ich beurteilen konnte, ob Hostinger Connector Deployments und Hosting gut verwaltet, musste ich wissen, was nötig ist, um es überhaupt zum Laufen zu bringen.
Ein Tool, das darauf ausgelegt ist, im Editor zu bleiben, verliert schnell seinen Reiz, wenn das Einrichten das Bearbeiten von Konfigurationsdateien, das Erzeugen von API-Tokens oder wiederholte Re-Authentifizierung bedeutet. Dieser Abschnitt behandelt nur die Einrichtung. Die praktischen Aufgabentests folgen direkt danach.
Ich habe Hostinger Connector aus dem VS Code Marketplace installiert. Es erschien als erstes Ergebnis, als ich nach “Hostinger” suchte, der Herausgeber war als Hostinger Official aufgeführt, und es ließ sich beim ersten Versuch in unter zwei Minuten installieren.
| Detail | Ergebnis |
|---|---|
| Marketplace-Suche | Bestanden, erschien sofort |
| Überprüfung des Herausgebers | Hostinger Official |
| Installation | In unter zwei Minuten abgeschlossen |
| Erweiterungsversion zum Zeitpunkt des Tests | 1.3.1 |
| Marketplace-Installationen | 8,140 |
| Benutzerbewertung | 5 Sterne, basierend auf zwei Bewertungen |
Die letzte Zeile ist mit Vorsicht zu genießen. Fünf Sterne klingen stark, aber eine Stichprobe von zwei Bewertungen sagt mir fast nichts über die typische Benutzererfahrung. Ich würde mich in diesem Review-Text nicht auf diese Zahl stützen.
Eine Voraussetzung hat mich überrascht: Hostinger Connector liefert die Hostinger-Tools, aber es braucht bereits einen aktiven KI-Agenten im Editor, um sie tatsächlich aufzurufen.
Die Erweiterung selbst hat nichts, womit sie allein sprechen könnte. In VS Code ist dieser Agent GitHub Copilot Chat, da dies derzeit die KI-Oberfläche ist, die VS Code für MCP-Tool-Aufrufe bereitstellt. Ich hatte Copilot bereits aktiv, daher hat mich das nicht verlangsamt, aber Leser sollten wissen, dass Connector nur so nützlich ist wie der KI-Agent dahinter.
Ohne einen installierten und angemeldeten Agenten gibt es nichts, womit es sich verbinden könnte.
Was die Installation nicht erforderte:
Die Installation der Erweiterung selbst war einer der reibungslosesten Teile des gesamten Tests. Der einzige echte Haken ist eine Abhängigkeit, die Hostinger nicht besonders hervorhebt: Die Erweiterung braucht einen aktiven KI-Agenten in Ihrem Editor, um überhaupt etwas zu tun.
Nachdem die Erweiterung installiert war, stellte sich die nächste Frage: Würde die Verbindung mit einem echten Konto genauso einfach sein?
Die Kontoverbindung erfolgte per OAuth über einen Button „1-Click Connect“. VS Code öffnete eine Hostinger-Autorisierungsseite in meinem Browser, erkannte meine bestehende Hostinger-Sitzung und bat mich, den Zugriff für etwas namens hostinger-mcp zu genehmigen.
Nachdem ich auf Allow geklickt hatte, kehrte ich zu VS Code zurück und sah „Connected via OAuth“.
| Prüfung | Ergebnis |
|---|---|
| Ein-Klick-Verbindung | Bestanden |
| Browser öffnete sich automatisch | Bestanden |
| Vorhandene Hostinger-Sitzung erkannt | Bestanden |
| Manueller API-Token erforderlich | Nein |
| Autorisierungsbildschirm angezeigt | Ja |
| Berechtigungen erklärt | Ja, aber allgemein |
| Erfolgreich zu VS Code zurückgekehrt | Bestanden |
Der Autorisierungsbildschirm sagte mir, dass der Connector Websites, Hosting, Domains, Abonnements und andere Hostinger-Dienste verwalten könne.
Das ist eine Kategorienliste, keine detaillierte Aufschlüsselung von Berechtigungen. Ich hätte mir hier mehr Granularität gewünscht, da „Abonnements verwalten“ und „Websites verwalten“ sehr unterschiedliche Risikostufen abdecken.
Was mir einen Teil dieser Kontrolle gab, war ein separates Panel innerhalb der Erweiterung, das jede Tool-Kategorie auflistet und es mir erlaubte, jede einzelne zu aktivieren oder zu deaktivieren:
| Tool-Kategorie | Verfügbare Tools | Standardstatus |
|---|---|---|
| Websites | 80 | Aktiviert |
| Domains | 26 | Aktiviert |
| Abonnements und Zahlungen | 7 | Aktiviert |
| E-Mail-Marketing | 12 | Aktiviert |
| Ecommerce | 12 | Deaktiviert |
| VPS | 62 | Deaktiviert |
Das sind insgesamt 199 Tools, davon 125 standardmäßig aktiviert. Ich ließ Ecommerce und VPS zunächst deaktiviert, bis ich bereit war, sie direkt zu testen, und die Erweiterung respektierte diese Grenze während des gesamten Tests.
Das ist die Art von Sicherheitsdetail, die auf Hostingers Marketingseite nicht auftaucht, aber für jeden wichtig ist, der entscheidet, wie viel Kontozugriff er einer KI-Assistentin oder einem KI-Assistenten geben will. Ich würde das als echte Stärke bezeichnen.
Das Trennen des Kontos ist über dasselbe Panel möglich, ohne dass Sie Ihr Hostinger-Passwort ändern oder nach einem gespeicherten Token suchen müssen.
Die Autorisierung ging schnell und erforderte keine eigene Token-Verwaltung, aber der Berechtigungsbildschirm ist breit statt granular. Die kategoriebasierten Tool-Steuerungen innerhalb der Erweiterung tragen mehr dazu bei, das tatsächliche Risiko zu begrenzen, als der OAuth-Bildschirm es tut.
Hostinger listet Unterstützung für die folgenden Clients auf, wie sie vom Onboarding-Bildschirm der Erweiterung erfasst wurden:
| Editor oder Client | Von Hostinger aufgeführt |
|---|---|
| VS Code | Ja |
| Cursor | Ja |
| Windsurf | Ja |
| Devin Desktop | Ja |
| Antigravity | Ja |
| Claude Code | Ja |
| OpenAI Codex CLI | Ja |
Ich verwendete VS Code mit GitHub Copilot als meine primäre Testumgebung.
Die Einrichtung sagte mir, dass der Connector leicht zu erreichen ist. Sie sagte mir noch nichts darüber, ob er die Aufgabe tatsächlich gut erledigt, sobald er verbunden ist, und genau diese schwierigere Frage habe ich als Nächstes untersucht.
Eine Erweiterung zu installieren und zu verbinden ist der einfache Teil. Was wirklich zählt, ist, ob sie echte Hosting-Arbeit korrekt erledigt, also habe ich eine kleine Express.js-Anwendung namens PulseWatch gebaut und den Connector denselben Weg gehen lassen, den ein Entwickler nach der Installation typischerweise geht: das Konto inspizieren, ein Deployment-Ziel finden, das Projekt deployen, es aktualisieren, die Ergebnisse prüfen und von einem von mir absichtlich eingeführten Fehler wiederherstellen.
| Test | Was ich lernen wollte |
|---|---|
| Kontodaten lesen | Kann es das Hosting-Konto genau verstehen? |
| Ein Deployment-Ziel finden | Kann es die richtige Website ohne Raten identifizieren? |
| Das Node.js-Projekt analysieren | Versteht es die App, bevor es daran etwas ändert? |
| PulseWatch deployen | Kann es ein echtes Projekt vom Editor zum Live-Hosting bringen? |
| Eine Inhaltsaktualisierung veröffentlichen | Ist es für routinemäßige Entwicklungsarbeit nützlich? |
| Builds und Logs prüfen | Liefert es nach einem Deployment nützliche Nachweise? |
| Eine defekte Version deployen | Zeigt es einen echten Anwendungsfehler auf? |
| Die Anwendung wiederherstellen | Kann es eine bekannte gute Version sicher wiederherstellen? |
PulseWatch war absichtlich einfach: ein Express-Server, eine Startseite, ein package.json-Startskript und ein /api/health-Endpunkt, der JSON zurückgibt. Dieser Health-Endpunkt erwies sich später als wichtig.
Eine Hosting-Plattform kann einen abgeschlossenen Build melden, während die Anwendung beim Start fehlschlägt. Ein Live-Endpunkt gab mir eine unabhängige Möglichkeit zu überprüfen, ob der bereitgestellte Prozess tatsächlich antwortete, anstatt einem Statussymbol zu vertrauen.
Ich begann mit schreibgeschützten Prompts, bevor ich dem Assistenten irgendetwas an Live-Änderungen erlaubte. Wenn er mein Konto nicht genau beschreiben konnte, hätte ich wenig Grund, ihm Deployments, DNS oder VPS-Aktionen anzuvertrauen.
Das Website-Auflistungstool des Connectors gab fünf Websites zurück:
Mein Konto enthielt tatsächlich mehr als das. hPanel zeigte Websites über Premium-, Business- und Growth-Pläne verteilt, darunter WordPress-Websites, PHP/HTML-Websites, Website-Builder-Projekte und mehrere temporäre Domains.
Bei einem separaten Prompt zur Frage nach meinen aktiven Hosting-Plänen sagte mir der Assistent, ich hätte „einen aktiven Hosting-Plan“. hPanel zeigte drei: Premium, Growth und Business.
| Prüfung | Ergebnis |
|---|---|
| Bekannte Websites aufgelistet | Bestanden |
| Alle Hosting-Pläne aufgelistet | Nicht bestanden |
| Unbenutzten Business-Plan erkannt | Nicht bestanden |
| Keine Kontosänderungen vorgenommen | Nein |
Um fair gegenüber dem Connector zu sein: Als ich nachhakte und auf die Diskrepanz hinwies, korrigierte er sich, trennte klar zwischen dem, was er verifiziert hatte, und dem, was er angenommen hatte, und wiederholte die falsche Behauptung nicht.
Das ist ein besseres Fehlverhalten, als darauf zu beharren, aber es bedeutet, dass die erste Antwort auf eine kontoweite Frage nicht als bare Münze genommen werden sollte.
Der schreibgeschützte Zugriff funktionierte, aber die erste Antwort auf eine kontoweite Frage war unvollständig. Er korrigierte sich, sobald ich ihn herausforderte, was wichtig ist, aber ich hätte ihn nicht herausfordern müssen.
Diese Lücke in der Kontosichtbarkeit erwies sich als Vorbote eines größeren Problems. Der eigentliche Test, ob das relevant war, kam als Nächstes, als ich den Connector bat, eine Website zu finden, die ihm nie namentlich genannt worden war.
Hier zeigte der Test am meisten. Ich bat den Assistenten, eine neu erstellte Node.js-Website zu identifizieren, ohne dass ich ihre Domain nannte, und ohne eine bestehende Website anzutasten.
Die Zielauswahl ist eine grundlegende Sicherheitsanforderung für ein Tool, das in einem Live-Konto handeln kann, daher wollte ich sehen, wie es mit Unsicherheit umgeht und nicht mit einer sauberen Antwort.
So lief es ab, in dieser Reihenfolge:
| Schritt | Was der Connector getan hat | Ergebnis |
|---|---|---|
| 1 | Verwendete einen Domainnamen aus einem früheren fehlgeschlagenen Versuch erneut: pulsewatch-temp-20260714.hostingersite.com | Diese Domain wurde nie von einem Website-Aufruf zurückgegeben |
| 2 | Führte auf dieser Domain eine Zugänglichkeitsprüfung aus | Gab is_accessible: true zurück |
| 3 | Interpretierte dieses Ergebnis als Bestätigung, dass die Website existierte | Falsch. Zugänglichkeit ist nicht dasselbe wie ein vorhandener, deploybarer Website-Datensatz |
| 4 | Versuchte die Bereitstellung mit Ressourcen-IDs, die es nicht als Hosting-Order-IDs verifiziert hatte | Hostinger gab zweimal [Hosting:9999] Not found zurück |
Das Kernproblem: Die beiden IDs, die es verwendete, waren Domain-Ressourcen-IDs, keine Hosting-Order-IDs. Es bestätigte den Unterschied nie, bevor es mit ihnen ein Live-Website-Erstellungstool aufrief.
Als ich es bat, sich zu erklären, lieferte der Assistent schließlich eine genaue Darstellung: Es hatte die ganze Zeit über ein funktionierendes Website-Auflistungstool zur Verfügung, rief es aber nach dem Erstellen einer neuen Website über hPanel nicht erneut auf, also füllte es die Lücke mit einer unüberprüften Domain statt die Daten zu aktualisieren.
Als ich es direkt aufforderte, dieses Listungstool erneut auszuführen und nach einem neuen Datensatz zu suchen, rief es stattdessen drei nicht zusammenhängende Deployment-Lookup-Tools auf und meldete „keine neue Website erschien“, eine Schlussfolgerung, die durch die tatsächlich ausgeführten Tool-Aufrufe nicht gestützt werden konnte.
Nichts davon erzeugte eine versehentliche Website in meinem Konto. Die fehlgeschlagenen Aufrufe hinterließen nichts. Aber das Muster sollte klar benannt werden. Bei unvollständigen Daten füllte der Assistent die Lücke mit einer plausibel klingenden Annahme, behandelte ein schwaches Signal als starke Evidenz und handelte in einem Live-Konto, bevor diese Annahme geprüft war.
Das ist die wichtigste Erkenntnis in diesem Abschnitt. Der Connector wird bei einem Ziel raten und auf Basis dieser Vermutung handeln, statt anzuhalten und zu fragen. Hier ist es sicher fehlgeschlagen, aber die Gewohnheit, ein schwaches Signal als Beweis zu behandeln, ist das, worauf Sie in Ihrem eigenen Konto achten sollten.
Da der Connector das Ziel nicht selbst finden konnte, blieb mir nur eine Option: Ich musste das Ziel selbst anlegen und sehen, ob sich dadurch etwas änderte.
Da der Connector das neue Ziel nicht zuverlässig selbst finden konnte, schloss ich die erste Einrichtung manuell über hPanel ab, um zu sehen, was Hostinger vor der Connector-basierten Bereitstellung vorbereitet.
Der Weg war: Neue Website erstellen → Node.js-Web-App → temporäre Domain → Hostinger wählte automatisch ein Rechenzentrum im Vereinigten Königreich mit geschätzter Latenz von 147ms → eine Auswahl aus drei Bereitstellungsmethoden.
Dieser dritte Bildschirm ist für sich genommen bemerkenswert. Hostinger bietet „Build with Hostinger Connector“ als Bereitstellungsmethode direkt neben GitHub-Import und manuellem Dateiupload an. Ich wählte ihn in der Erwartung, dass er die Einrichtung der Website abschließen würde.
Stattdessen leitete er mich zur Installationsseite des Connectors weiter, die ich bereits abgeschlossen hatte. Das ist eine echte Lücke im Onboarding. Die Option, die als Connector-nativer Pfad dargestellt wurde, provisionierte tatsächlich nichts.
Ich ging zurück und wählte stattdessen den manuellen Dateiupload. Hostinger akzeptierte mein Projektarchiv (11.46 KB, ohne node_modules ), und der Einstellungsbildschirm zeigte eine korrekte automatische Erkennung:
Ich klickte auf Deploy. Es wurde erfolgreich abgeschlossen, und Hostinger wies eine echte temporäre Domain zu: orange-walrus-700988.hostingersite.com. Das ist eine andere Domain als die, die der Connector zuvor erfunden hatte. Ich öffnete sowohl die Startseite als auch /api/health manuell und bestätigte, dass beide funktionierten.
Der manuelle Weg funktionierte problemlos, sobald ich aufhörte zu warten, dass der Connector es findet. Die Schaltfläche „Build with Hostinger Connector“ auf diesem Bildschirm sollte behoben oder entfernt werden. Im Moment verspricht sie etwas, das sie nicht tut.
Jetzt existierte eine echte, bestätigte Website. Die nächste Frage war, ob sich das Verhalten des Connectors änderte, nachdem er etwas Konkretes finden konnte.
Mit einer echten, bestätigten Website an Ort und Stelle ging ich zurück zum Connector und bat ihn, diese genaue Domain zu prüfen. Dieses Mal funktionierte es sauber.
| Prüfung | Ergebnis |
|---|---|
| Erkannte die Website als Node.js-Deployment-Ziel | Bestanden |
| Fand den abgeschlossenen Deployment-Datensatz | Bestanden |
| Fand den passenden Node.js-Build-Datensatz | Bestanden |
| Deployment und Build teilten sich dieselbe UUID | Bestanden |
Das bestätigte etwas Wichtiges: Die früheren Fehler betrafen das Auffinden und Erstellen eines neuen Ziels, nicht die Fähigkeit des Connectors, mit einer Node.js-Website zu arbeiten, sobald eine vorhanden ist.
Als Nächstes testete ich die Funktion, die Hostinger am stärksten bewirbt: eine Codeänderung lokal vorzunehmen und sie zu veröffentlichen, ohne hPanel zu öffnen.
Ich bat den Assistenten, eine Zeile des Startseitentextes zu ändern, von „Monitor Every Service. Catch Every Issue.“ zu „Monitor Every Service. Resolve Issues Faster.“
| Schritt | Ergebnis |
|---|---|
| Den vorhandenen Text gefunden | Bestanden |
| Nur die angeforderte Zeile geändert | Bestanden |
| Die App vor dem Deployment lokal verifiziert | Bestanden |
Das Projekt paketiert, unter Ausschluss von node_modules und .git | Bestanden |
| Zum vorhandenen, bestätigten Website deployt | Bestanden |
| Deployment- und Build-Status danach geprüft | Bestanden |
Der gesamte Update-Vorgang dauerte etwa eine Minute. Der Assistent meldete das neue Deployment sofort nach dem Abschicken als „pending“, einfach weil er prüfte, bevor Hostinger die Verarbeitung beendet hatte.
Als ich die Live-Seite selbst aktualisierte, war die neue Überschrift bereits da.
Die Build-Logs, die er danach abrief, waren konkret und nützlich: 67 Pakete hinzugefügt, 68 geprüft, null Schwachstellen gefunden, keine Fehler.
Für bestehende Websites ist das nah an dem Workflow, den Hostinger verspricht. Bearbeiten, lokal prüfen, veröffentlichen und bestätigen, alles ohne den Editor zu verlassen, in etwa einer Minute. Das ist das stärkste Ergebnis im gesamten Test.
Ein sauberer Deploy sagt mir nur, dass der glückliche Pfad funktioniert. Um herauszufinden, was der Connector unter Druck tatsächlich tut, habe ich die Anwendung absichtlich beschädigt.
Ein Tool verdient Vertrauen erst, wenn es sich in einem echten Fehlerfall bewährt und nicht nur in einer sauberen Demo. Ich habe die Anwendung absichtlich beschädigt, um zu sehen, ob die Statusanzeige und die Logs des Connectors wirklich bei der Diagnose helfen können.
Bevor irgendeine Änderung gemacht wurde, sicherte der Assistent package.json zu package.json.bak, was für sich genommen schon eine gute Angewohnheit ist.
Ich ließ dann den Startbefehl von “start”: “node server.js” auf “start”: “node missing-server.js” ändern, eine Datei, die nicht existiert.
Das lokale Ausführen bestätigte einen echten, reproduzierbaren Fehler: Error: Cannot find module ‘…/missing-server.js’.
Ich deployte die defekte Version absichtlich trotzdem, um zu sehen, was Hostinger melden würde.
| Angezeigter Status | Was er bestätigt hat | Was er nicht bestätigt hat |
|---|---|---|
| Build: abgeschlossen | Abhängigkeiten installiert, Build-Phase beendet | Dass die Anwendung tatsächlich gestartet ist |
| Deployment: abgeschlossen | Hostinger akzeptierte und verarbeitete die Veröffentlichung | Dass alle Routen gesund sind |
Die über den Connector verfügbaren Build-Logs zeigten eine erfolgreiche Installation der Abhängigkeiten und sonst nichts. Der Laufzeitfehler durch das fehlende Modul erschien dort nicht. Ein Entwickler, der nur auf ein grünes „abgeschlossen“-Abzeichen schaut, hätte keinen Grund zu vermuten, dass die Website defekt ist.
Die Wiederherstellung verlief reibungslos. Der Assistent stellte package.json aus der Sicherung wieder her, prüfte die App lokal, deployte erneut und bestätigte die Korrektur, indem er den Live- /api/health -Endpunkt direkt aufrief, statt dem Bereitstellungsstatus zu vertrauen.
Dieser Endpunkt gab eine betriebsbereite Antwort zurück, und das war der einzige Nachweis im gesamten Test, der tatsächlich beweist, dass die Anwendung lief.
Das ist die zweite große Erkenntnis. Ein abgeschlossener Status ist kein Beweis für eine funktionierende Anwendung, und die eigenen Logs des Connectors sagen Ihnen das nicht. Die Wiederherstellung selbst funktionierte gut, sobald ich wusste, dass es überhaupt ein Problem gab, das ich wiederherstellen musste.
Nach einem Fehler, den ein Statussymbol nicht erkennen konnte, wollte ich wissen, wo die Zuversicht des Connectors noch seiner tatsächlichen Fähigkeit voraus sein könnte. Umgebungsvariablen waren der nächste Test.
Ich bat den Assistenten, eine harmlose Umgebungsvariable hinzuzufügen, zu bestätigen, dass die Einstellung als dedizierte Connector-Funktion existiert, bevor etwas verändert wird, und zu stoppen, falls das nicht so ist.
Er suchte in den verfügbaren Tools, fand keine dedizierte Aktion zur Verwaltung von Node.js-Umgebungsvariablen und stoppte, bevor er irgendwelche Code- oder Deployment-Änderungen vornahm.
Das ist genau das Verhalten, das ich in diesem Test überall sonst sehen wollte. Als er auf eine echte Grenze stieß, hielt er an, statt zu raten. Ich würde daraus nicht schließen, dass Hostinger Connector nirgendwo in seinem Toolset keine Unterstützung für Umgebungsvariablen hat, sondern nur, dass während dieses Tests keine solche Aktion bereitgestellt wurde.
| Test | Ergebnis | Wichtigste Erkenntnis |
|---|---|---|
| Lauffähiges Manifest sichern | Bestanden | Wiederherstellungsdatei vor der Änderung erstellt |
| Fehlenden Einstiegspunkt einführen | Bestanden | Kontrollierter Fehler hinzugefügt |
| Fehler lokal reproduzieren | Bestanden | MODULE_NOT_FOUND bestätigt |
| Defekte Version deployen | Bestanden | Hostinger akzeptierte das Archiv |
| Build-Status erkennt Fehler | Nicht bestanden | Build zeigte weiterhin abgeschlossen |
| Build-Logs zeigen Laufzeitfehler | Nicht bestanden | Der fehlende Modulfehler war nicht vorhanden |
| Lauffähiges Manifest wiederherstellen | Bestanden | Ursprünglicher Startbefehl wiederhergestellt |
| Arbeitsfähige Version erneut deployen | Bestanden | Deployment abgeschlossen |
| Live-Health-Endpunkt prüfen | Bestanden | API gab operativen Status zurück |
Hostinger Connector erledigte routinemäßige, deterministische Aufgaben gut:
Es war schwächer, wenn die Aufgabe Interpretation über unvollständige Kontodaten hinweg erforderte:
Dieses Muster ist hilfreich, wenn man entscheidet, wie viel Autonomie man dem Assistenten geben möchte.
Verwenden Sie breitere Prompts für risikoarme Inspektionen. Verwenden Sie präzise Prompts und explizite Bestätigungsanforderungen für Aktionen, die Live-Infrastruktur verändern.
Anstatt beispielsweise:
| Deploye diese App auf eine neue temporäre Hostinger-Website. |
verwenden Sie:
| Liste die Websites auf, die derzeit von Hostinger zurückgegeben werden. Identifiziere eine Node.js-Website nur, wenn sie in diesem Ergebnis erscheint. Zeige mir vor dem Deployment die genaue Domain und den Nachweis. Generiere, leite ab oder verwende keine Domain erneut, die nicht von Hostinger zurückgegeben wurde. |
Der zweite Prompt schränkt den Spielraum des Assistenten für Annahmen ein.
Hostinger Connector einzurichten war einfach, ohne die übliche Reibung beim Setup, und die granularen Tool-Kontrollen gaben mir echte Kontrolle darüber, was die KI berühren konnte.
Sobald eine echte Website mit bekannter Domain existierte, erledigte es die Aufgabe gut: Eine einzeilige Textänderung ging in etwa einer Minute von der Bearbeitung bis live, abgesichert durch nützliche Build-Logs.
Die Probleme zeigten sich früher im Prozess, nicht später. Wenn es mit einem neuen Ziel konfrontiert wurde, das es nicht finden konnte, erfand der Connector eine Domain und handelte darauf, bevor er prüfte. Er markierte außerdem ein defektes Deployment als „abgeschlossen“, obwohl die App tatsächlich ausgefallen war, und in seinen eigenen Logs erschien kein Laufzeitfehler. Keines dieser Probleme macht das Tool für bestehende Websites unzuverlässig, aber beide bedeuten, dass neue Deployments und der Status nach dem Deployment vor dem Vertrauen eine zweite Prüfung brauchen.
Hostinger baut seinen Support um Live-Chat und Selbsthilfe statt um Telefonanrufe auf, daher konzentrierte ich meine Tests auf die Bereiche, in denen die meisten Nutzer tatsächlich landen: den in hPanel eingebetteten KI-Assistenten, die menschliche Eskalation dahinter und die Wissensdatenbank, zu der ein Entwickler greifen würde, bevor er überhaupt einen Chat öffnet.
| Kanal | Verfügbarkeit | Hinweise |
|---|---|---|
| Live-Chat (Kodee, KI) | 24/7 | Zugriff über „Ask AI“ in hPanel |
| Live-Chat (Mensch) | Nur Eskalation | Keine direkte Warteschlange, Weiterleitung über Kodee |
| E-Mail / Ticket | support@hostinger.com | Angegebene Antwortzeit von 1 Geschäftstag |
| Telefon | Nicht angeboten | Keine öffentliche Telefonleitung für allgemeinen Support |
| Wissensdatenbank | Self-Service | support.hostinger.com |
| Tutorials und Academy | Self-Service | Schritt-für-Schritt-Anleitungen und ein YouTube-Kanal |
Da Live-Chat der Kanal ist, auf den Hostinger Entwickler für alles Dringende verweist, und der Kanal, den man während des Debuggens eines Deployments am ehesten tatsächlich nutzt, testete ich diesen Weg direkt, statt ein E-Mail-Ticket zu eröffnen.
Ich öffnete den Live-Chat über „Ask AI“ in hPanel und stellte Kodee eine Frage mit einer klaren, aber fehleranfälligen Antwort: ob ein abgeschlossener Build-Status bei einer Node.js-Bereitstellung garantiert, dass die App tatsächlich läuft, und wo ich sonst einen Beweis finden würde.
Kodees erste Antwort war spezifisch und korrekt:
„Completed“ bedeutet normalerweise, dass der Build-Schritt erfolgreich abgeschlossen wurde; es garantiert nicht, dass die App nach dem Start gesund ist. Um einen falschen Startbefehl oder einen anderen Laufzeitabsturz zu erkennen, prüfen Sie die Laufzeit-Logs: Gehen Sie in hPanel zu Websites → Dashboard → Deployments für Build-Logs und öffnen Sie dann die stderr.log im nodejs -Ordner für Startfehler wie Port already in use oder Module not found.
Diese eine Antwort hätte genau die Unklarheit beseitigt, auf die mein Fehlerwiederherstellungstest weiter oben in diesem Bericht gestoßen war. Kodee nannte eine echte Logdatei, den richtigen Ordner und zog die richtige Grenze zwischen Build-Erfolg und Laufzeitgesundheit.
Ich wollte aber auch sehen, ob ich Zugriff auf einen echten menschlichen Agenten bekomme, also sagte ich Kodee, dass ich das gern direkt mit einem Support-Mitarbeiter bestätigen möchte.
Aber die Kontaktaufnahme mit einem Menschen war schwieriger als erwartet. Ich fragte direkt nach einem Live-Agenten und wurde zweimal zurück zu Kodee geleitet, jeweils mit dem Hinweis, dass es schneller sei, statt zu warten:
Ich verstehe, warum Sie das möchten. Ich kann Ihnen hier direkt helfen, den Build, den Startbefehl und die Laufzeit-Logs zu überprüfen, was normalerweise der schnellste Weg ist, das Problem zu finden.
Bevor wir einen Spezialisten einreihen. Ich kann das Problem lösen und Ihnen das Warten ersparen.
| Versuch | Meine Anfrage | Kodees Antwort |
|---|---|---|
| 1 | „Kannst du mich mit einem Live-Agenten verbinden?“ | Bot bot an, das Problem selbst zu lösen |
| 2 | „Ich würde trotzdem gern mit einem menschlichen Agenten sprechen. Bitte verbinde mich.“ | Bot bot erneut an, fragte nach Domain und Startbefehl |
| 3 | Klickte „Go to human“ / tippte „I want to continue with a human“ | Eskaliert |
Es brauchte zwei direkte, explizite Anfragen, bevor Kodee aufhörte, mich zurück zu sich selbst zu leiten. Bei einer Frage, die ich selbst lösen konnte, ist diese Reibung gering. Für jemanden mitten in einem Ausfall, der eine Person möchte, ist das ein echter Frustpunkt.
Was danach geschah, war keine Live-Übergabe im üblichen Sinn von „verbinden Sie mich mit einem Menschen“. Kodee erklärte das tatsächliche Modell offen:
Ich habe Ihre Anfrage an einen Spezialisten aus unserem Team weitergegeben, der unseren Chat persönlich überprüft und uns seine Antwort sendet, die ich Ihnen dann hier weiterleite.
Das ist eine asynchrone Prüfung, keine Live-Übergabe. Kodee bleibt die Schnittstelle; ein Mensch prüft den Verlauf im Hintergrund und Kodee leitet die Antwort weiter, sobald sie eintrifft. Dieser Unterschied ist wichtig für Leser, die entscheiden, ob sie eskalieren sollen, denn „menschlicher Agent“ bedeutet hier nicht, dass eine neue Person sich direkt dem Chatfenster anschließt, wie es bei den meisten Live-Chat-Systemen der Fall wäre.
Ich trieb denselben technischen Thread weiter, während ich wartete, und fragte Kodee, um den genauen Log-Pfad zu bestätigen und ob stderr.log immer befüllt wird. Es gab eine solide Antwort und wies korrekt darauf hin, dass das Log leer sein kann, wenn die App nie vollständig gestartet wurde oder ihren Fehler woanders schrieb.
Die Überprüfung durch den Spezialisten kam nach etwa 3 Minuten zurück, im Chat einem Teammitglied namens Mayas zugeschrieben, und sie war präziser als Kodees Antwort statt sie nur zu wiederholen:
domains/[your-domain]/nodejs/stderr.log ist der korrekte Speicherort. Es wird nicht immer erzeugt oder befüllt. Sie sehen dort nur Einträge, wenn die App nach stderr schreibt, etwa bei nicht abgefangenen Ausnahmen oder unbehandelten Rejections. Wenn der Startbefehl falsch ist und der Prozess stillschweigend beendet wird, kann stderr.log leer oder nicht vorhanden sein.
Mayas fügte außerdem zwei Fallback-Prüfungen hinzu, die Kodee nicht erwähnt hatte: stdout.log auf die letzte Ausgabe vor einem Absturz zu prüfen und nach einer fehlenden Startbestätigungszeile zu suchen als Zeichen dafür, dass die App nie gestartet wurde.
| Prüfung | Ergebnis |
|---|---|
| Erste technische Antwort korrekt | Ja |
| Menschliche Eskalation verfügbar | Ja, aber zweimal widerstanden, bevor sie gewährt wurde |
| Eskalationsmodell | Asynchrone Prüfung und Weiterleitung, keine Live-Übergabe |
| Genannter Antwortender | Mayas |
| Antwortzeit für menschliche Prüfung | Etwa 3 Minuten |
| Menschliche Antwort präziser als KI-Antwort | Ja |
Die Wissensdatenbank von Hostinger ist in breite Produktkategorien gegliedert: Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel und About Hostinger.
Keine dieser Kategorien ist speziell Hostinger Connector gewidmet. Den richtigen Artikel fand ich nur durch die direkte Suche nach „Hostinger Connector“, die fünf Ergebnisse lieferte, von denen die meisten nur lose damit zusammenhingen, darunter ein Leitfaden zu einem Affiliate-Marketing-Plugin und ein allgemeiner Artikel zum Node.js-Hosting.
Der Artikel, der die Connector-Einrichtung tatsächlich dokumentiert, heißt „How to Set Up Web Hosting MCP on Local IDEs“ und ist unter Features → General Information abgelegt.
Die Suche mit dem tatsächlichen Produktmarketingnamen fand ihn, aber ein Leser, der Kategorien durchsucht oder nach „MCP“ sucht, ohne Hostingers Branding zu kennen, könnte ihn genauso gut übersehen, und die Abweichung zwischen dem vermarkteten Namen und dem dokumentierten Namen ist etwas, das man vor der Suche wissen sollte.
Der Artikel selbst ist stark, sobald man ihn gefunden hat. Er wurde zuletzt sechs Tage vor meinem Test aktualisiert und behandelt:
Der letzte Punkt stimmte mit etwas überein, auf das ich während des Tests direkt gestoßen bin: Devin Desktop wird automatisch erkannt, während OpenAI Codex die manuelle Methode benötigt. Der Artikel gibt diesen Unterschied korrekt wieder.
Kodees erste Antwort auf eine schwierige technische Frage war korrekt und spezifisch, was nicht jeder KI-Support-Assistent schafft. Der Wissensdatenbank-Artikel, der das untermauert, ist aktuell und detailliert, sobald man ihn findet, obwohl Produktmarketingname und Dokumentationstitel nicht übereinstimmen, sodass die Suche zuverlässiger ist als das Durchstöbern von Kategorien.
Der schwächere Punkt ist der Weg zur menschlichen Eskalation. Kodee leitete mich zweimal zurück zu sich selbst, bevor es eine direkte Bitte um eine Person akzeptierte, und selbst dann bedeutet „menschlicher Agent“ eine asynchrone Prüfung, die über denselben Chat weitergeleitet wird, statt einer Live-Übergabe. Sobald ein Mensch sich den Fall ansah, war die Antwort besser als Kodees eigene, präziser und mit zwei zusätzlichen Diagnose-Schritten, die Kodee nicht angeboten hatte.
Für die meisten Fragen wird Kodee allein schnell eine genaue Antwort liefern. Wenn Sie wirklich möchten, dass ein Mensch die Antwort bestätigt, müssen Sie damit rechnen, mehr als einmal zu fragen, und mit einer kurzen Wartezeit auf eine weitergeleitete Antwort statt auf ein Live-Gespräch.
Ja, für Entwickler, die bereits bei Hostinger hosten und Routine-Deployments direkt aus dem Editor erledigen möchten. Die Einrichtung dauerte Minuten, OAuth machte API-Schlüssel überflüssig, und sobald eine Website mit bekannter Domain existierte, schickte der Connector ein Live-Update in etwa einer Minute heraus, abgesichert durch Logs. Kodees eigene Support-Antworten waren präzise genug, um ein echtes technisches Problem beim ersten Versuch zu lösen.
Der Haken ist Vertrauen, nicht Bequemlichkeit. Wenn ein neues Ziel nicht gefunden werden konnte, erfand der Connector eine Domain und handelte darauf, bevor er prüfte.
Außerdem markierte er ein defektes Deployment als „abgeschlossen“, obwohl die App tatsächlich ausgefallen war, und in seinen eigenen Logs tauchte kein Laufzeitfehler auf. Nutzen Sie es, um Arbeiten an bereits existierenden Websites zu beschleunigen, prüfen Sie alles, was es auf einem brandneuen Ziel tut, und kontrollieren Sie nach jedem wichtigen Deployment selbst die Live-Seite.
| Description | Expert Review |
|---|---|
| Kostengünstiges Hosting mit hoher Leistung und einfachen Verwaltungstools. | Read Shared Hosting Review |
| Schnelles und sicheres WordPress-Hosting mit Ein-Klick-Installation und Premium-Funkt... | Read Wordpress Hosting Review |
| Skalierbares VPS-Hosting mit dedizierten Ressourcen und Root-Zugriff. | Read VPS Review |
| Schnelles, flexibles Cloud-Hosting mit exzellenter Verfügbarkeit und skalierbaren Re... | Read Cloud Hosting Review |
| Sichere und private Hosting-Lösungen mit Offshore-Rechenzentrumsstandorten. | Read Offshore Hosting Review |
| Sicheres und zuverlässiges E-Mail-Hosting mit professionellen Funktionen. | Read Email Hosting Review |
| Zuverlässiges Python-Hosting mit flexiblen Umgebungen für Entwickler. | Read Python Hosting Review |
| Hochleistungs-PHP-Hosting mit voller Unterstützung für dynamische Websites und Anwe... | Read PHP Hosting Review |
| Zuverlässiges Windows-VPS-Hosting mit voller Kontrolle und Anpassungsoptionen. | Read Windows VPS Review |
| Schnelles und flexibles Hosting, zugeschnitten auf Node.js-Anwendungen mit optimaler ... | Read Nodejs Hosting Review |
| Optimiertes Hosting für WooCommerce-Shops mit hoher Geschwindigkeit und sicherer Int... | Read Woocommerce Hosting Review |
| Dediziertes Server-Hosting für nahtlose Minecraft-Spielerlebnisse. | Read Minecraft Server Hosting Review |
| Skalierbare Hosting-Lösungen mit erweiterten Funktionen für Digitalagenturen und En... | Read Agency Hosting Review |
| Schnelles, sicheres Hosting, optimiert für Magento-E-Commerce-Websites. | Read Magento Hosting Review |
| Leistungsstarkes, Linux-basiertes Hosting für einen stabilen und sicheren Website-Be... | Read Linux Hosting Review |
| Robuste Java-Hosting-Lösungen für dynamische Webanwendungen und Projekte. | Read Java Hosting Review |
| Optimiertes Hosting für E-Commerce-Websites mit sicherer, schneller und zuverlässig... | Read Ecommerce Hosting Review |
| Zuverlässiges Django-Hosting mit hoher Geschwindigkeit und sicherer Umgebung. | Read Django Hosting Review |
| Benutzerfreundliches cPanel-Hosting mit robuster Leistung und zuverlässigem Support. | Read Cpanel Hosting Review |
| Leistungsstarkes Hosting für Unternehmen mit schnellen Geschwindigkeiten, Sicherheit... | Read Business Hosting Review |
| Easy-to-use website builder with drag-and-drop tools and customizable templates. | Read Website Builder Review |
| Optimized hosting for Joomla sites with one-click installation and reliable performan... | Read Joomla Hosting Review |
| Powerful hosting with full PostgreSQL database support for data-driven applications. | Read PostgreSQL Hosting Review |
| Flexible hosting with MongoDB integration for scalable, modern web applications. | Read MongoDB Hosting Review |
| AI-powered website creation platform for building professional sites in minutes. | Read Horizons Review |
| Reliable hosting for n8n workflow automation with easy setup and management. | Read n8n Hosting Review |
| VPS hosting with Docker support for containerized application deployment and scaling. | Read Docker VPS Review |
| Dedizierter SMTP-Server-Hosting für zuverlässige und sichere E-Mail-Zustellung. | Read SMTP Server Review |
| Schnelles und optimiertes Hosting, zugeschnitten auf Ruby-on-Rails-Webanwendungen. | Read Ruby on Rails Review |
| Funktionsreiches Hosting mit OpenClaw-Integration zum Erstellen und Verwalten von Gre... | Read OpenClaw Review |
| Schnelles und zuverlässiges Hosting mit Servern in Großbritannien für optimale lok... | Read UK Hosting Review |
| Erschwingliches und zuverlässiges Hosting mit in Indien ansässigen Servern für lat... | Read India Review |
| Read Singapore Review | |
| Read Australia Review | |
| Read AI Agent Review | |
| Read Paperclip VPS Review | |
| Read Hermes Agent Review | |
| Read Web Apps Hosting Review | |
| Read Hostinger Reach Review | |
| Read MCP Review | |
| Read hpanel Review | |
| Read Odoo Review | |
| Read Laravel Review | |
| Read MERN VPS Review | |
| Read Ubuntu Review | |
| Read Drupal Hosting Review |
Hostinger Connector ist eine MCP-basierte Integration, die unterstützte KI-Coding-Umgebungen mit Hostinger-Diensten verbindet.
Sie ermöglicht es einem KI-Assistenten, unterstützte Hostinger-Tools für Aufgaben rund um Websites, Bereitstellungen, Domains, DNS, Datenbanken, E-Mail und VPS-Ressourcen aufzurufen.
Connector ist keine separate Hosting-Plattform und ersetzt hPanel nicht. Es bietet eine weitere Möglichkeit, mit Hostinger-Ressourcen zu interagieren.
Hostinger listet derzeit:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger sagt außerdem, dass andere MCP-kompatible Clients unterstützt werden können. Einrichtung und Werkzeugverhalten können sich zwischen den Clients unterscheiden.
Hostinger Connector ist kostenlos zu installieren und in den Hostinger-Paketen enthalten. Es gibt kein separates Connector-Abonnement in der Preisgestaltung, die in diesem Test angezeigt wird. Sie müssen weiterhin für den zugrunde liegenden Hostinger-Dienst bezahlen, z. B. Webhosting, Cloud-Hosting oder einen VPS.
Nein. Der Hostinger Connector verwendet OAuth-Authentifizierung. Während meiner VS Code-Einrichtung habe ich mich über den browserbasierten Autorisierungsablauf von Hostinger angemeldet. Ich habe keinen API-Schlüssel generiert, kein Token in den Editor eingefügt und keine Anmeldedaten in einer Konfigurationsdatei gespeichert.
Nein. Hostinger sagt, dass Connector-API-Aufrufe mit dem Live-Konto interagieren. Verwenden Sie beim Erlernen des Workflows eine dedizierte Test-Website, Domain oder einen VPS. Gehen Sie nicht davon aus, dass eine Eingabe nur deshalb simuliert wird, weil sie über einen KI-Chat ausgegeben wird.
Ja. Hostinger dokumentiert standardmäßige Limits von:
• 60 Anfragen pro Minute
• 1.000 Anfragen pro Stunde
Hostinger sagt außerdem, dass Details zum Rate-Limit in den Antwort-Headern zurückgegeben werden.
Diese Limits sollten für die normale interaktive Nutzung ausreichend sein. Vermeiden Sie unnötige wiederholte Aufrufe, insbesondere wenn eine frühere Antwort bereits die benötigten Informationen enthält.
Ja. Ich habe eine Express.js-Anwendung auf Hostinger bereitgestellt und später Connector verwendet, um eine aktualisierte Version aus VS Code zu veröffentlichen. Hostinger erkannte Express, wählte Node.js 22.x aus und verwendete das Projektverzeichnis beim ersten hPanel-Deployment als Stammverzeichnis. Nachdem die Website als erkanntes Node.js-Ziel vorhanden war, funktionierte die erneute Bereitstellung über Connector erfolgreich.
Nicht unbedingt. In meinem kontrollierten Test meldete Hostinger einen abgeschlossenen Build, nachdem ich das Startskript so geändert hatte, dass es auf eine fehlende JavaScript-Datei verwies. Die abgerufenen Build-Logs zeigten eine erfolgreiche Abhängigkeitsinstallation, machten den Laufzeit-Startfehler jedoch nicht sichtbar. Überprüfen Sie nach der Bereitstellung immer die Live-Website oder rufen Sie einen Health-Endpunkt auf.
Nicht ganz. Connector kann die Häufigkeit verringern, mit der Entwickler ihren Editor verlassen müssen, insbesondere für routinemäßige Bereitstellungen und Kontoprüfungen. hPanel bleibt nützlich für die visuelle Kontoverwaltung, die anfängliche Einrichtung, detaillierte Konfiguration und Situationen, in denen die KI die erforderliche Ressource nicht korrekt erkennen oder bereitstellen kann.
Beantworten Sie ein paar einfache Fragen und finden Sie die perfekte Lösung für Sie!
Hosting-Suche starten
HostAdvice.com bietet professionelle Web-Hosting Bewertungen, die völlig unabhängig von irgendwelchen Unternehmen sind. Unsere Bewertungen sind unvoreingenommen, ehrlich, und es gelten für alle die gleichen Bedingungen.
Wir erhalten eine finanzielle Entschädigung von den Unternehmen, die wir bewerten. Etwaige Entschädigungen und Vergütungen haben keinen Einfluss auf die Richtung oder Schlussfolgerung unserer Bewertungen. Auch beeinflusst eine Vergütung nicht das von uns errechnete Ranking für ein bestimmtes Host-Unternehmen.
Diese Vergütung deckt die Kosten für die Tantiemen der Bewerter, den Kauf der Konten, und das Testen ab.
