Het beheren van hosting onderbreekt doorgaans de ontwikkeling. Je schrijft code in een editor, opent een hostingdashboard om een website aan te maken, schakelt over naar een terminal om het project te verpakken of te pushen, gaat terug naar het dashboard om een deployment te inspecteren, en opent meer tools wanneer DNS, logs of serverresources aandacht nodig hebben.
Hostinger Connector vermindert dat wisselen van context. Het verbindt Hostinger-services met AI-codingtools via het Model Context Protocol (MCP), zodat je een AI-assistent kunt vragen om ondersteunde hostingresources te inspecteren of te beheren zonder je editor te verlaten.
Dat klinkt handig. Het roept ook een belangrijkere vraag op: Kun je een AI-assistent vertrouwen om echte hostingtaken nauwkeurig uit te voeren?
Om dat uit te vinden, heb ik Hostinger Connector getest met VS Code en GitHub Copilot tegen een echt Hostinger-account. Ik gebruikte een kleine Express.js-applicatie genaamd PulseWatch en volgde de workflow van installatie tot live deployment. Ik testte ook herhaalde deployments, buildrecords, logs en herstel nadat ik opzettelijk het startcommando van de applicatie had kapotgemaakt.
Hier is hoe ik Hostinger Connector heb gescoord op de gebieden die het belangrijkst zijn voor een developer die wil beslissen of hij het wil gebruiken: kosten, functierange, dagelijkse bruikbaarheid, hoe nauwkeurig het echte taken uitvoert, en de ondersteuning erachter wanneer er iets misgaat. Elke score weerspiegelt wat ik daadwerkelijk tijdens het testen vond, niet de marketingpagina.
| Parameter | Score | Waarom deze score |
|---|---|---|
| Prijzen | 9.7/10 | Connector brengt helemaal geen apart abonnementstarief met zich mee en zit gratis inbegrepen bij elk abonnement. De enige kosten zijn de onderliggende hostingresource die je sowieso nodig zou hebben. |
| Functies | 9.5/10 | De functierange reikt verder dan deployment naar websites, domeinen, DNS, databases, e-mailcampagnes, VPS-resources, logs en diagnostiek, en dekt meer af dan een typische deploymenttool. |
| Gebruiksgemak | 9.1/10 | Installatie en OAuth waren snel en vereisten geen handmatige configuratie, en herhaalde deployments waren eenvoudig. De eerste Node.js-websiteopzet vereiste hPanel nadat de AI er niet in slaagde een geldig target te identificeren, de ene echte tekortkoming in een verder soepele setup. |
| Uitvoeringsnauwkeurigheid | 8.5/10 | Projectanalyse, codebewerking, verpakken, deployment en herstel werkten goed. De AI hergebruikte een verzonnen domein en interpreteerde een toegankelijkheidscheck te ver voordat dat target bestond. |
| Ondersteuning | 9.5/10 | Kodee gaf bij de eerste poging een accuraat, specifiek antwoord op een echte technische vraag, en de vervolgreactie van de menselijke specialist was nog scherper. Escaleren kostte twee directe verzoeken, maar zowel de AI- als de menselijke antwoorden waren betrouwbaar zodra ze gegeven werden. |
| Algemeen | 9.3/10 | Een waardevolle workflowtool voor Hostinger-gebruikers die in AI-ondersteunde editors werken. Het kost niets extra, dekt een brede functierange af, en zowel setup als ondersteuning hielden stand tijdens het testen. Nauwkeurigheid bij nieuwe deploymenttargets is het ene punt om op te letten. |
Hostinger Connector wordt niet als losstaand product verkocht. Hostinger zegt dat Connector gratis is inbegrepen bij elk abonnement, wat betekent dat er geen aparte maandelijkse Connector-kosten aan je hostingfactuur worden toegevoegd.
Maar “gratis” heeft context nodig. Connector beheert Hostinger-resources; het vervangt ze niet. Je hebt nog steeds een geschikte hosting-, cloud-, VPS-, domein-, e-mail- of andere Hostinger-service nodig voor de taken die je wilt uitvoeren.
Op het moment van deze review belichtte de Connector-landingpage Business Web Hosting en Cloud Startup.
| Abonnement | Promotieprijs | Getoonde vooruitbetaalde termijn | Verlengingsprijs | Webapps | 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 |
Prijzen werden weergegeven vóór toepasselijke belastingen. Promotieprijzen en verlengingstarieven kunnen veranderen, dus controleer het huidige afrekenbedrag in plaats van het abonnement alleen op basis van het geadverteerde maandbedrag te beoordelen.
Prijsinzicht: Koop niet een hoger abonnement alleen om toegang tot Connector te krijgen. Kies het abonnement op basis van het aantal websites en webapps dat je nodig hebt, de resources die ze vereisen en het ondersteuningsniveau dat je wilt. Connector is een inbegrepen beheerslaag, niet het hoofdproduct waarvoor wordt geprijsd.
Hostinger adverteert met een 30-dagen geld-terug-garantie voor in aanmerking komende hostingaankopen. Er is geen apart Connector-terugbetalingsbeleid om te beoordelen omdat Connector geen afzonderlijke vergoeding heeft.
De exacte acties die beschikbaar zijn, hangen af van de Hostinger-services in je account en de tools die beschikbaar worden gesteld aan de verbonden AI-client.
Hostinger documenteert ook rate limits. Volgens de Connector-FAQ is de standaardtoelage 60 verzoeken per minuut en 1,000 verzoeken per uur, waarbij rate-limitinformatie wordt teruggegeven in responseheaders.
Die limieten zijn ruim voor interactief gebruik, hoewel geautomatiseerde of zeer repetitieve workflows nog steeds onnodige dubbele calls moeten vermijden.
Voordat ik kon beoordelen of Hostinger Connector hosting goed deployt en beheert, moest ik eerst weten wat er nodig is om het überhaupt aan de praat te krijgen.
Een tool die draait om in de editor blijven verliest snel zijn aantrekkingskracht als de setup betekent dat je configuratiebestanden moet bewerken, API-tokens moet genereren of herhaaldelijk opnieuw moet authenticeren. Deze sectie behandelt alleen de setup. De praktijktest van de taken komt daarna.
Ik installeerde Hostinger Connector vanuit de VS Code Marketplace. Het verscheen als het eerste resultaat toen ik zocht op “Hostinger”, de uitgever stond vermeld als Hostinger Official, en het installeerde bij de eerste poging in minder dan twee minuten.
| Detail | Resultaat |
|---|---|
| Marketplace-zoekopdracht | Geslaagd, verscheen direct |
| Uitgeververificatie | Hostinger Official |
| Installatie | Voltooid in minder dan twee minuten |
| Extensieversie ten tijde van de test | 1.3.1 |
| Marketplace-installaties | 8,140 |
| Gebruikersbeoordeling | 5 sterren, gebaseerd op twee beoordelingen |
Die laatste regel verdient een waarschuwing. Vijf sterren klinkt sterk, maar een steekproef van twee reviews zegt me vrijwel niets over de gebruikelijke ervaring van gebruikers. Ik zou dat cijfer niet zwaar laten meewegen in de reviewtekst.
Een vereiste verraste me: Hostinger Connector levert de Hostinger-tools aan, maar heeft al een actieve AI-agent in de editor nodig om ze daadwerkelijk aan te roepen.
De extensie zelf heeft niets om mee te praten. In VS Code is die agent GitHub Copilot Chat, omdat dit momenteel de AI-interface is die VS Code blootstelt voor MCP-toolcalls. Ik had Copilot al actief, dus dit vertraagde me niet, maar lezers moeten weten dat Connector slechts zo bruikbaar is als de AI-agent erachter.
Zonder een geïnstalleerde en ingelogde agent is er niets waarop het kan aansluiten.
Wat installatie niet vereiste:
Het installeren van de extensie zelf was een van de soepelste onderdelen van de hele test. De enige echte adder onder het gras is een afhankelijkheid die Hostinger niet heel prominent benoemt: de extensie heeft een actieve AI-agent in je editor nodig om überhaupt iets te doen.
Met de extensie geïnstalleerd was de volgende vraag of verbinden met een echt account even eenvoudig zou zijn.
Accountverbinding gebruikte OAuth via een knop “1-Click Connect”. VS Code opende een Hostinger-autorisatiepagina in mijn browser, detecteerde mijn bestaande Hostinger-sessie en vroeg me om toegang goed te keuren voor iets dat hostinger-mcp heette.
Nadat ik op Allow had geklikt, keerde ik terug naar VS Code met “Connected via OAuth”.
| Controle | Resultaat |
|---|---|
| Verbinding met één klik | Geslaagd |
| Browser werd automatisch geopend | Geslaagd |
| Bestaande Hostinger-sessie gedetecteerd | Geslaagd |
| Handmatige API-token vereist | Nee |
| Autorisatiescherm getoond | Ja |
| Machtigingen uitgelegd | Ja, maar breed |
| Succesvol teruggekeerd naar VS Code | Geslaagd |
Het autorisatiescherm vertelde me dat de Connector websites, hosting, domeinen, abonnementen en andere Hostinger-services kon beheren.
Dat is een categorielijst, geen gedetailleerd overzicht per machtiging. Ik had hier meer granulariteit gewild, omdat “abonnementen beheren” en “websites beheren” heel verschillende risiconiveaus dekken.
Wat me wel enige controle gaf, was een apart paneel in de extensie dat elke toolcategorie liet zien en me toestond elke categorie afzonderlijk in of uit te schakelen:
| Toolcategorie | Beschikbare tools | Standaardstatus |
|---|---|---|
| Websites | 80 | Ingeschakeld |
| Domeinen | 26 | Ingeschakeld |
| Abonnementen en betalingen | 7 | Ingeschakeld |
| E-mailmarketing | 12 | Ingeschakeld |
| Ecommerce | 12 | Uitgeschakeld |
| VPS | 62 | Uitgeschakeld |
Dat zijn in totaal 199 tools, waarvan 125 standaard ingeschakeld. Ik liet Ecommerce en VPS uitgeschakeld totdat ik ze direct wilde testen, en de extensie respecteerde die grens gedurende het hele testen.
Dit is het soort beveiligingsdetail dat niet op Hostinger’s marketingpagina staat, maar wel belangrijk is voor iedereen die moet beslissen hoeveel accounttoegang hij aan een AI-assistent wil geven. Ik zou het een echte sterkte noemen.
Het ontkoppelen van het account is beschikbaar vanuit hetzelfde paneel, zonder dat je je Hostinger-wachtwoord hoeft te wijzigen of een opgeslagen token hoeft op te zoeken.
Autorisatie ging snel en vereiste niet dat ik zelf een token beheerde, maar het machtigingsscherm is breed in plaats van gedetailleerd. De toolcategoriecontroles op categorieniveau in de extensie doen meer om het echte risico te beperken dan het OAuth-scherm doet.
Hostinger noemt ondersteuning voor de volgende clients, verzameld vanaf het onboarding-scherm van de extensie:
| Editor of client | Door Hostinger vermeld |
|---|---|
| VS Code | Ja |
| Cursor | Ja |
| Windsurf | Ja |
| Devin Desktop | Ja |
| Antigravity | Ja |
| Claude Code | Ja |
| OpenAI Codex CLI | Ja |
Ik gebruikte VS Code met GitHub Copilot als mijn primaire testomgeving.
Setup vertelde me dat Connector eenvoudig te bereiken is. Het zei nog niets over de vraag of het de klus ook echt goed uitvoert zodra het verbonden is, en dat is de lastigere vraag die ik daarna stelde.
Een extensie installeren en verbinden is het makkelijke deel. Waar het echt om gaat is of het echte hostingwerk correct doet, dus ik bouwde een kleine Express.js-applicatie genaamd PulseWatch en zette Connector door hetzelfde pad dat een developer na installatie zou volgen: het account inspecteren, een deploymenttarget vinden, het project deployen, het bijwerken, de resultaten inspecteren, en herstellen van een fout die ik opzettelijk had ingebouwd.
| Test | Wat ik wilde leren |
|---|---|
| Accountgegevens lezen | Kan het de hostingaccount nauwkeurig begrijpen? |
| Een deploymenttarget vinden | Kan het de juiste website identificeren zonder te gokken? |
| Het Node.js-project analyseren | Begrijpt het de app voordat het eraan komt? |
| PulseWatch deployen | Kan het een echt project van editor naar live hosting verplaatsen? |
| Een contentupdate publiceren | Is het bruikbaar voor routinematig ontwikkelwerk? |
| Builds en logs inspecteren | Geeft het nuttig bewijs na een deployment? |
| Een kapotte versie deployen | Laat het een echte applicatiefout zien? |
| De applicatie herstellen | Kan het een bekende goede release veilig terugzetten? |
PulseWatch was bewust eenvoudig: een Express-server, een homepage, een package.json startscript en een /api/health-endpoint dat JSON teruggeeft. Dat health-endpoint bleek later belangrijk.
Een hostingplatform kan een voltooide build rapporteren terwijl de applicatie nog steeds faalt bij het opstarten. Een live endpoint gaf me een onafhankelijke manier om te controleren of het gedownloade proces daadwerkelijk reageerde, in plaats van een statusbadge te vertrouwen.
Ik begon met read-only prompts voordat ik de assistent ook maar in de buurt van live wijzigingen liet komen. Als het mijn account niet accuraat kon beschrijven, had ik weinig reden om het te vertrouwen met deployments, DNS of VPS-acties.
De website-lijsttool van Connector gaf vijf sites terug:
Mijn account bevatte in werkelijkheid meer dan dat. hPanel toonde websites verspreid over Premium-, Business- en Growth-abonnementen, waaronder WordPress-sites, PHP/HTML-sites, Website Builder-projecten en verschillende tijdelijke domeinen.
Op een aparte prompt over mijn actieve hostingabonnementen vertelde de assistent me dat ik “one active hosting plan” had. hPanel toonde er drie: Premium, Growth en Business.
| Controle | Resultaat |
|---|---|
| Bekende websites vermeld | Geslaagd |
| Alle hostingabonnementen vermeld | Mislukt |
| Ongebruikte Business-abonnement gedetecteerd | Mislukt |
| Geen accountwijzigingen gemaakt | Ja |
Om eerlijk te zijn tegenover Connector: toen ik erop wees en de discrepantie noemde, corrigeerde het zichzelf, maakte duidelijk onderscheid tussen wat het had geverifieerd en wat het had aangenomen, en herhaalde de verkeerde claim niet.
Dat is een betere foutmodus dan blijven volhouden, maar het betekent wel dat het eerste antwoord op een accountbrede vraag niet voor lief moet worden genomen.
Read-only toegang werkte, maar het eerste antwoord op elke accountbrede vraag was onvolledig. Het corrigeerde zichzelf nadat het werd tegengesproken, en dat is belangrijk, maar ik had het niet hoeven te betwisten.
Die kloof in accountzichtbaarheid bleek een voorproefje van een groter probleem. De echte test van de vraag of dat uitmaakte kwam daarna, toen ik de Connector vroeg een website te vinden die het nog nooit bij naam was verteld.
Hier liet het testen het meeste zien. Ik vroeg de assistent om een nieuw aangemaakte Node.js-website te identificeren zonder me het domein te noemen, en zonder een bestaande site aan te raken.
Targetselectie is een basisveiligheidsvereiste voor een tool die op een live account kan handelen, dus ik wilde zien hoe het omging met onzekerheid in plaats van met een kant-en-klaar antwoord.
Dit gebeurde er, in volgorde:
| Stap | Wat de Connector deed | Resultaat |
|---|---|---|
| 1 | Hergebruikte een domeinnaam uit een eerdere mislukte poging: pulsewatch-temp-20260714.hostingersite.com | Dit domein was nooit teruggegeven door een website-lijstcall |
| 2 | Voerde een toegankelijkheidscheck uit op dat domein | Gaf is_accessible: true terug |
| 3 | Beschouwde dat resultaat als bevestiging dat de website bestond | Onjuist. Toegankelijkheid is niet hetzelfde als een bestaand, deploybaar websiterecord |
| 4 | Poging tot deployment met resource-IDs die het niet had geverifieerd als hosting order IDs | Hostinger gaf tweemaal [Hosting:9999] Not found terug |
Het kernprobleem: de twee IDs die het gebruikte waren domeinresource-IDs, geen hosting order-IDs. Het bevestigde dat onderscheid nooit voordat het een live website-aanmaaktool ermee aanriep.
Toen ik het vroeg zichzelf uit te leggen, gaf de assistent uiteindelijk een accuraat verslag: het had de hele tijd een werkende website-lijsttool beschikbaar, maar riep die niet opnieuw aan nadat ik via hPanel een nieuwe site had aangemaakt, dus vulde het het gat met een ongeverifieerd domein in plaats van de gegevens te verversen.
Toen ik het er direct toe vroeg om die listingtool opnieuw uit te voeren en te controleren op een nieuw record, riep het in plaats daarvan drie ongerelateerde deployment-lookuptools aan en meldde het “geen nieuwe website verscheen”, een conclusie die de toolcalls die het daadwerkelijk deed niet konden ondersteunen.
Geen van dit alles creëerde een losse website in mijn account. De mislukte calls lieten niets achter. Maar het patroon is de moeite waard om duidelijk te benoemen. Met onvolledige data vulde de assistent het gat met een plausibele aanname, behandelde een zwak signaal als sterk bewijs, en handelde op een live account voordat die aanname was gecontroleerd.
Dit is de belangrijkste bevinding in deze sectie. De Connector zal een target gaan gokken en op die gok handelen in plaats van te stoppen en te vragen. Het faalde hier veilig, maar de gewoonte om een zwak signaal als bewijs te behandelen is iets om zelf op te letten in je account.
Omdat de Connector de target niet zelfstandig kon vinden, hield ik nog maar één optie over: ik bouwde de target zelf en keek of dat iets veranderde.
Omdat de Connector de nieuwe target niet betrouwbaar zelf kon vinden, maakte ik de eerste setup handmatig af via hPanel om te zien wat Hostinger voorbereidt voordat Connector-gebaseerde deployment mogelijk wordt.
Het pad was: Create a new site → Node.js web app → tijdelijk domein → Hostinger selecteerde automatisch een datacenter in het Verenigd Koninkrijk met een geschatte latency van 147ms → een keuze uit drie deploymentmethoden.
Dat derde scherm is op zichzelf de moeite waard om te noemen. Hostinger biedt “Build with Hostinger Connector” aan als deploymethode naast GitHub import en handmatige bestandsupload. Ik selecteerde het in de verwachting dat het de site zou afmaken.
In plaats daarvan werd ik doorgestuurd naar de installatiepagina van Connector zelf, die ik al had voltooid. Dat is een echt onboardinggat. De optie die als een Connector-native route werd gepresenteerd, voorzag feitelijk niets.
Ik ging terug en koos in plaats daarvan voor handmatige bestandsupload. Hostinger accepteerde mijn projectarchief (11.46 KB, met node_modules uitgezonderd), en het instellingenvenster liet een nauwkeurige autodetectie zien:
Ik klikte op Deploy. Het slaagde, en Hostinger wees een echt tijdelijk domein toe: orange-walrus-700988.hostingersite.com. Dat is een ander domein dan het domein dat de Connector eerder had verzonnen. Ik opende zowel de homepage als /api/health handmatig en bevestigde dat beide werkten.
De handmatige route werkte zonder frictie zodra ik stopte met wachten tot de Connector het zou vinden. De knop “Build with Hostinger Connector” op dit scherm moet worden gefixt of verwijderd. Op dit moment belooft het iets wat het niet doet.
Er bestond nu een echte, bevestigde website. De volgende vraag was of de Connector zich anders zou gedragen nu het iets stevigs had om te vinden.
Met een echte, bevestigde website op zijn plaats ging ik terug naar de Connector en vroeg ik het om precies dat domein te inspecteren. Deze keer werkte het netjes.
| Controle | Resultaat |
|---|---|
| Herkende de site als Node.js-deploymenttarget | Geslaagd |
| Vond het voltooide deploymentrecord | Geslaagd |
| Vond het bijbehorende Node.js-buildrecord | Geslaagd |
| Deployment en build deelden dezelfde UUID | Geslaagd |
Dat bevestigde iets belangrijks: de eerdere mislukkingen gingen over het lokaliseren en aanmaken van een nieuw target, niet over het vermogen van Connector om met een Node.js-site te werken zodra die bestaat.
Daarna testte ik de functie die Hostinger het sterkst promoot: lokaal code wijzigen en publiceren zonder hPanel te openen.
Ik vroeg de assistent om één regel homepage-tekst te wijzigen, van “Monitor Every Service. Catch Every Issue.” naar “Monitor Every Service. Resolve Issues Faster.”
| Stap | Resultaat |
|---|---|
| Bestaande tekst gevonden | Geslaagd |
| Alleen de gevraagde regel gewijzigd | Geslaagd |
| De app lokaal geverifieerd vóór deployment | Geslaagd |
Project verpakt, met uitsluiting van node_modules en .git | Geslaagd |
| Gedepubliceerd naar de bestaande, bevestigde website | Geslaagd |
| Deployment- en buildstatus daarna gecontroleerd | Geslaagd |
De hele update duurde ongeveer een minuut. De assistent meldde de nieuwe deployment onmiddellijk na het indienen als “pending”, simpelweg omdat het keek voordat Hostinger klaar was met verwerken.
Tegen de tijd dat ik de live site zelf ververste, stond de nieuwe kop er al.
De buildlogs die het daarna ophaalde waren specifiek en nuttig: 67 packages toegevoegd, 68 geauditeerd, nul kwetsbaarheden gevonden, geen fouten.
Voor gevestigde sites komt dit dicht in de buurt van de workflow die Hostinger belooft. Bewerk, verifieer lokaal, verstuur, en bevestig, allemaal zonder de editor te verlaten, in ongeveer een minuut. Dit is het sterkste resultaat in de hele test.
Een schone deployment vertelt me alleen dat het happy path werkt. Om te zien wat de Connector onder druk daadwerkelijk doet, brak ik de applicatie opzettelijk.
Een tool verdient pas vertrouwen wanneer het contact maakt met een echte fout, niet alleen met een schone demo. Ik brak de applicatie bewust om te zien of de statusrapportage en logs van Connector echt konden helpen bij de diagnose.
Voor ik iets wijzigde, maakte de assistent een back-up van package.json naar package.json.bak, wat op zichzelf al een goede gewoonte is.
Ik liet het daarna het startscript wijzigen van “start”: “node server.js” naar “start”: “node missing-server.js”, een bestand dat niet bestaat.
Het lokaal draaien bevestigde een echte, reproduceerbare fout: Error: Cannot find module ‘…/missing-server.js’.
Ik deployde de kapotte versie toch, met opzet, om te zien wat Hostinger zou rapporteren.
| Getoonde status | Wat het bevestigde | Wat het niet bevestigde |
|---|---|---|
| Build: completed | Afhankelijkheden geïnstalleerd, buildfase voltooid | Dat de applicatie daadwerkelijk startte |
| Deployment: completed | Hostinger accepteerde en verwerkte de release | Dat elke route gezond was |
De buildlogs die via de Connector beschikbaar waren, lieten succesvolle installatie van afhankelijkheden zien en verder niets. De runtimefout met ontbrekende module verscheen daar nooit in. Een developer die alleen naar een groen “completed”-badge kijkt, zou geen reden hebben om te vermoeden dat de site kapot was.
Herstel verliep soepel. De assistent zette package.json terug vanaf de back-up, verifieerde de app lokaal, deployde opnieuw, en bevestigde de fix door het live /api/health-endpoint direct aan te roepen in plaats van te vertrouwen op de deploymentstatus alleen.
Dat endpoint gaf een operationele respons terug, en dat was het enige bewijs in de hele test dat daadwerkelijk aantoonde dat de applicatie draaide.
Dit is de tweede grote bevinding. Een afgeronde status is geen bewijs van een werkende applicatie, en de logs van Connector zullen je dat niet vertellen. Het herstel zelf werkte goed zodra ik wist dat er een probleem was om te herstellen.
Nadat een fout die een statusbadge niet kon onthullen, wilde ik weten waar de zelfvertrouwen van Connector nog meer zijn daadwerkelijke capaciteit kon overtreffen. Omgevingsvariabelen waren de volgende test.
Ik vroeg de assistent om een onschuldige omgevingsvariabele toe te voegen, eerst te bevestigen dat de instelling als aparte Connector-mogelijkheid bestond voordat het iets aanraakte, en te stoppen als dat niet zo was.
Het doorzocht de beschikbare tools, vond geen specifieke actie voor het beheren van Node.js-omgevingsvariabelen, en stopte voordat er code- of deploymentwijzigingen werden gemaakt.
Dit is het gedrag dat ik overal in deze test had willen zien. Geconfronteerd met een echte beperking, stopte het in plaats van te gokken. Ik zou hieruit niet concluderen dat Hostinger Connector nergens in zijn toolset geen ondersteuning voor omgevingsvariabelen heeft; alleen dat tijdens deze test geen dergelijke actie werd blootgesteld.
| Test | Resultaat | Kernbevinding |
|---|---|---|
| Werkend manifest back-uppen | Geslaagd | Herstelbestand aangemaakt vóór wijziging |
| Ontbrekend entry point introduceren | Geslaagd | Gecontroleerde fout toegevoegd |
| Fout lokaal reproduceren | Geslaagd | MODULE_NOT_FOUND bevestigd |
| Kapotte versie deployen | Geslaagd | Hostinger accepteerde het archief |
| Buildstatus detecteert fout | Mislukt | Build toonde nog steeds completed |
| Buildlogs tonen runtimefout | Mislukt | Ontbrekende module-fout kwam niet voor |
| Werkend manifest herstellen | Geslaagd | Origineel startcommando hersteld |
| Werkende versie opnieuw deployen | Geslaagd | Deployment voltooid |
| Live health-endpoint verifiëren | Geslaagd | API gaf operationele status terug |
Hostinger Connector presteerde goed bij routinematige, deterministische taken:
Het was zwakker wanneer de taak interpretatie vereiste over onvolledige accountgegevens heen:
Dat patroon is nuttig wanneer je beslist hoeveel autonomie je de assistent geeft.
Gebruik bredere prompts voor inspectie met laag risico. Gebruik precieze prompts en expliciete bevestigingseisen voor acties die live-infrastructuur wijzigen.
Bijvoorbeeld, in plaats van:
| Deploy deze app naar een nieuwe tijdelijke Hostinger-site. |
gebruik:
| Geef de websites weer die momenteel door Hostinger worden teruggegeven. Identificeer alleen een Node.js-website als die in dat resultaat verschijnt. Toon me het exacte domein en bewijs voordat je deployt. Genereer, veronderstel of hergebruik geen domein dat niet door Hostinger is teruggegeven. |
De tweede prompt beperkt de ruimte voor aannames van de assistent.
Hostinger Connector aan de praat krijgen was eenvoudig, met geen van de gebruikelijke setupfricties, en de gedetailleerde toolcategoriecontroles gaven me echte inspraak in wat de AI kon aanraken.
Zodra er een echte website met een bekend domein bestond, deed het zijn werk goed: een eenregelige tekstwijziging ging van bewerken naar live in ongeveer een minuut, ondersteund door nuttige buildlogs.
De problemen verschenen eerder in het proces, niet later. Geconfronteerd met een nieuwe target die het niet kon vinden, verzon de Connector een domein en handelde erop voordat het controleerde. Het markeerde ook een kapotte deployment als “completed” terwijl de app feitelijk down was, met geen runtimefout in de eigen logs. Geen van beide problemen maakt de tool onbetrouwbaar voor bestaande sites, maar beide betekenen dat nieuwe deployments en post-deploystatus een tweede blik nodig hebben voordat je erop vertrouwt.
Hostinger bouwt zijn ondersteuning rond live chat en selfservice in plaats van telefoonoproepen, dus ik richtte mijn testen op de plekken waar de meeste gebruikers daadwerkelijk terechtkomen: de AI-assistent in hPanel, de menselijke escalatie daarachter, en de kennisbank waar een developer vóór het openen van een chat naar zou grijpen.
| Kanaal | Beschikbaarheid | Opmerkingen |
|---|---|---|
| Live chat (Kodee, AI) | 24/7 | Toegang via “Ask AI” in hPanel |
| Live chat (mens) | Alleen bij escalatie | Geen directe wachtrij, geleid via Kodee |
| E-mail / ticket | support@hostinger.com | Aangegeven reactietijd van 1 werkdag |
| Telefoon | Niet aangeboden | Geen openbaar telefoonnummer voor algemene ondersteuning |
| Kennisbank | Selfservice | support.hostinger.com |
| Tutorials en Academy | Selfservice | Stapsgewijze handleidingen en een YouTube-kanaal |
Gezien het feit dat live chat het kanaal is waar Hostinger developers naartoe stuurt voor alles wat urgent is, en het kanaal dat het meest waarschijnlijk tijdens het debuggen van een deployment wordt gebruikt, heb ik dat pad direct getest in plaats van een e-mailticket in te dienen.
Ik opende live chat via “Ask AI” in hPanel en stelde Kodee een vraag met een echt antwoord dat fout kon gaan: of een afgeronde buildstatus op een Node.js-deployment garandeert dat de app echt draait, en waar ik anders bewijs zou vinden.
Kodee’s eerste reactie was specifiek en correct:
“Completed” betekent meestal dat de buildfase succesvol is afgerond; het garandeert niet dat de app na het opstarten gezond is. Om een fout startcommando of andere runtimecrash op te sporen, controleer runtime logs: ga in hPanel naar Websites → Dashboard → Deployments voor buildlogs, en open vervolgens het stderr.log-bestand in de nodejs-map voor opstartfouten zoals Port already in use of Module not found.
Dat ene antwoord zou precies de ambiguïteit hebben opgelost waar mijn foutafhandelingstest eerder in deze review tegenaan liep. Kodee noemde een echt logbestand, de juiste map, en trok de juiste lijn tussen buildsucces en runtimegezondheid.
Ik wilde echter ook zien of ik toegang kon krijgen tot een echte menselijke agent, dus ik vertelde Kodee dat ik dit rechtstreeks met een supportmedewerker wilde bevestigen.
Maar het krijgen van een mens aan de lijn was moeilijker dan ik had verwacht. Ik vroeg direct om een live agent en werd twee keer teruggeleid naar Kodee, telkens gepresenteerd als sneller dan wachten:
Ik begrijp waarom je dat wilt. Ik kan je hier meteen helpen om de build, het startcommando en de runtime logs te verifiëren, wat meestal de snelste manier is om het probleem te vinden.
Voordat we een specialist inschakelen. Ik kan het probleem oplossen en je het wachten besparen.
| Poging | Mijn verzoek | Reactie van Kodee |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | Bood aan het zelf op te lossen |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | Bood opnieuw aan, vroeg om domein en startcommando |
| 3 | Klikte op “Go to human” / typte “I want to continue with a human” | Geëscaleerd |
Het kostte twee directe, expliciete verzoeken voordat Kodee stopte met me terug te leiden naar zichzelf. Voor een vraag die ik zelf kon oplossen, is die frictie klein. Voor iemand midden in een storing die een persoon wil, is het een echte bron van frustratie.
Wat daarna gebeurde was geen live overdracht in de gebruikelijke betekenis van “verbind me met een mens”. Kodee legde het werkelijke model duidelijk uit:
I have shared your request with a specialist from our team who will personally review our chat and send me their answer, which I will then relay back to you here.
Dit is een asynchrone review, geen live overdracht. Kodee blijft de interface; een mens bekijkt de transcriptie op de achtergrond en Kodee geeft het antwoord door zodra het arriveert. Dat onderscheid is belangrijk voor lezers die willen beslissen of ze escaleren, omdat “human agent” hier niet betekent dat er een nieuwe persoon in het chatvenster meedoet zoals bij de meeste livechatsystemen.
Ik duwde dezelfde technische thread verder terwijl ik wachtte, door Kodee te vragen het exacte logpad te bevestigen en of stderr.log altijd wordt gevuld. Het gaf op zichzelf een degelijk antwoord, en merkte correct op dat het log leeg kan zijn als de app nooit volledig is gestart of de fout ergens anders heeft weggeschreven.
De review van de specialist kwam na ongeveer 3 minuten binnen, in de chat toegeschreven aan een teamgenoot genaamd Mayas, en het verbeterde het antwoord van Kodee in plaats van het slechts te herhalen:
domains/[your-domain]/nodejs/stderr.log is de juiste locatie. Het wordt niet altijd gegenereerd of gevuld. Je ziet daar alleen vermeldingen wanneer de app naar stderr schrijft, zoals bij ongehandelde uitzonderingen of onopgevangen rejections. Als het startcommando onjuist is en het proces stilletjes stopt, kan stderr.log leeg zijn of ontbreken.
Mayas voegde ook twee fallbackcontroles toe die Kodee niet had genoemd: stdout.log controleren op de laatste output vóór een crash, en kijken naar een ontbrekende opstartbevestigingsregel als teken dat de app helemaal niet is gestart.
| Controle | Resultaat |
|---|---|
| Eerste technische antwoord accuraat | Ja |
| Menselijke escalatie beschikbaar | Ja, maar tweemaal geweigerd voordat het werd toegekend |
| Escalatiemodel | Asynchrone review en doorgeven, geen live overdracht |
| Genoemde responder | Mayas |
| Reactietijd voor menselijke review | Ongeveer 3 minuten |
| Menselijk antwoord preciezer dan AI-antwoord | Ja |
De kennisbank van Hostinger is georganiseerd in brede productcategorieën: 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 en About Hostinger.
Geen van die categorieën is specifiek gewijd aan Hostinger Connector. De enige manier waarop ik het juiste artikel vond, was door rechtstreeks te zoeken op “Hostinger Connector”, wat vijf resultaten opleverde, waarvan de meeste slechts losjes verband hielden, waaronder een handleiding voor een affiliate marketing plugin en een algemeen artikel over Node.js-hosting.
Het artikel dat de Connector-setup daadwerkelijk documenteert, heet “How to Set Up Web Hosting MCP on Local IDEs”, en staat onder Features → General Information.
Zoeken op de daadwerkelijke marketingnaam vond het, maar een lezer die door categorieën bladert of op “MCP” zoekt zonder Hostinger’s branding te kennen, kan het net zo gemakkelijk missen, en de mismatch tussen de gemarkete naam en de gedocumenteerde naam is de moeite waard om te weten voordat je gaat zoeken.
Het artikel zelf is sterk zodra je het gevonden hebt. Het is zes dagen vóór mijn test voor het laatst bijgewerkt en behandelt:
Dat laatste punt kwam overeen met iets waar ik tijdens het testen zelf tegenaan liep: Devin Desktop wordt automatisch gedetecteerd, terwijl OpenAI Codex de handmatige methode vereist. Het artikel heeft dat onderscheid correct.
Kodee’s eerste antwoord op een lastige technische vraag was accuraat en specifiek, wat niet iets is wat elke AI-ondersteuningsassistent voor elkaar krijgt. Het kennisbankartikel dat het ondersteunt is actueel en gedetailleerd zodra je het gevonden hebt, al komen de marketingnaam van het product en de titel van de documentatie niet overeen, dus zoeken is een betrouwbaardere route dan bladeren door categorieën.
Het zwakkere punt is het pad naar menselijke escalatie. Kodee stuurde me tweemaal terug naar zichzelf voordat het een direct verzoek om een persoon honoreerde, en zelfs dan betekent “human agent” een asynchrone review die via dezelfde chat wordt doorgegeven, niet een live overdracht. Zodra een mens er daadwerkelijk naar keek, was het antwoord beter dan dat van Kodee zelf, preciezer en met twee extra diagnosestappen die Kodee niet had aangeboden.
Voor de meeste vragen brengt Kodee je snel en correct naar een antwoord. Als je echt wilt dat een persoon het antwoord verifieert, verwacht dan dat je meer dan één keer moet vragen, en verwacht een korte wachttijd voor een doorgegeven antwoord in plaats van een live gesprek.
Ja, voor developers die al bij Hostinger hosten en routine-deployments vanuit de editor willen afhandelen. De setup duurde minuten, OAuth maakte API-keys overbodig, en zodra er een website met een bekend domein bestond, verstuurde Connector een live update in ongeveer een minuut met logs als ondersteuning. Kodee’s eigen ondersteuningsantwoorden waren scherp genoeg om bij de eerste poging een echt technisch probleem op te lossen.
De valkuil is vertrouwen, niet gemak. Geconfronteerd met een nieuw target dat het niet kon vinden, verzon de Connector een domein en handelde het daarop voordat het controleerde.
Het markeerde ook een kapotte deployment als “completed” terwijl de app eigenlijk down was, zonder runtimefout in de eigen logs. Gebruik het om werk op sites die al bestaan te versnellen, verifieer alles wat het doet op een nieuw target, en controleer de live site zelf na elke deployment die ertoe doet.
| Description | Expert Review |
|---|---|
| Budgetvriendelijke hosting met hoge prestaties en eenvoudige beheertools. | Read Shared Hosting Review |
| ast en veilige WordPress-hosting met installatie met één klik en premiumfuncties. | Read Wordpress Hosting Review |
| Schaalbare VPS-hosting met toegewijde resources en roottoegang. | Read VPS Review |
| Snelle, flexibele cloudhosting met uitstekende beschikbaarheid en schaalbare hulpbron... | Read Cloud Hosting Review |
| Veilige en privé-hostingoplossingen met offshore datacenterlocaties. | Read Offshore Hosting Review |
| Veilige en betrouwbare e-mailhosting met professionele functies. | Read Email Hosting Review |
| Betrouwbare Python-hosting met flexibele omgevingen voor ontwikkelaars. | Read Python Hosting Review |
| High-performance PHP-hosting met volledige ondersteuning voor dynamische websites en ... | Read PHP Hosting Review |
| Betrouwbare Windows VPS-hosting met volledige controle en aanpassingsmogelijkheden. | Read Windows VPS Review |
| Snelle en flexibele hosting op maat voor Node.js-toepassingen met optimale prestaties... | Read Nodejs Hosting Review |
| Geoptimaliseerde hosting voor WooCommerce-winkels met hoge snelheid en beveiligde int... | Read Woocommerce Hosting Review |
| Dedicated serverhosting voor naadloze Minecraft-gamingervaringen. | Read Minecraft Server Hosting Review |
| Schaalbare hostingoplossingen met geavanceerde functies voor digitale bureaus en ontw... | Read Agency Hosting Review |
| Snelle, beveiligde hosting geoptimaliseerd voor Magento e-commercewebsites. | Read Magento Hosting Review |
| Hoogpresterende Linux-gebaseerde hosting voor stabiele en veilige website-operaties. | Read Linux Hosting Review |
| Robuuste Java-hostingoplossingen voor dynamische webapplicaties en projecten. | Read Java Hosting Review |
| Geoptimaliseerde hosting voor e-commercewebsites met veilige, snelle en betrouwbare p... | Read Ecommerce Hosting Review |
| Betrouwbare Django-hosting met hoge snelheden en een veilige omgeving. | Read Django Hosting Review |
| Gebruiksvriendelijke cPanel-hosting met robuuste prestaties en betrouwbare ondersteun... | Read Cpanel Hosting Review |
| Krachtige hosting voor bedrijven met hoge snelheden, beveiliging en schaalbaarheid. | 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 |
| Toegewijde SMTP-serverhosting voor betrouwbare en veilige e-mailbezorging. | Read SMTP Server Review |
| Snel en geoptimaliseerd hosting op maat van Ruby on Rails-webapplicaties. | Read Ruby on Rails Review |
| Functierijke hosting met OpenClaw-integratie voor het bouwen en beheren van claw mach... | Read OpenClaw Review |
| Snelle en betrouwbare hosting met in het VK gevestigde servers voor optimale lokale p... | Read UK Hosting Review |
| Betaalbare en betrouwbare hosting met servers in India voor toegang met lage latentie... | 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 is een MCP-gebaseerde integratie die ondersteunde AI-codingomgevingen verbindt met Hostinger-diensten.
Het stelt een AI-assistent in staat om ondersteunde Hostinger-tools aan te roepen voor taken met betrekking tot websites, implementaties, domeinen, DNS, databases, e-mail en VPS-resources.
Connector is geen apart hostingplatform en vervangt hPanel niet. Het biedt een andere manier om met Hostinger-resources te werken.
Hostinger vermeldt momenteel:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger zegt ook dat andere MCP-compatibele clients mogelijk worden ondersteund. De configuratie en het toolgedrag kunnen per client verschillen.
Hostinger Connector is gratis te installeren en is inbegrepen bij Hostinger-abonnementen. Er is geen apart Connector-abonnement in de prijs die tijdens deze review wordt weergegeven. Je moet nog steeds betalen voor de onderliggende Hostinger-dienst, zoals webhosting, cloudhosting of een VPS.
Nee. Hostinger Connector gebruikt OAuth-authenticatie. Tijdens mijn VS Code-setup heb ik me aangemeld via Hostinger’s browsergebaseerde autorisatieproces. Ik heb geen API-sleutel gegenereerd, geen token in de editor geplakt en geen inloggegevens in een configuratiebestand opgeslagen.
Nee. Hostinger zegt dat Connector API-aanroepen met het live account werken. Gebruik een speciaal testwebsite, domein of VPS wanneer je de workflow leert. Ga er niet van uit dat een prompt gesimuleerd is alleen omdat deze via een AI-chat wordt gegeven.
Ja. Hostinger documenteert standaardlimieten van:
– 60 verzoeken per minuut
– 1.000 verzoeken per uur
Hostinger zegt ook dat details over de rate limit worden teruggegeven in response headers.
Deze limieten zouden voldoende moeten zijn voor normaal interactief gebruik. Vermijd onnodige herhaalde aanroepen, vooral wanneer een eerder antwoord al de benodigde informatie bevat.
Ja. Ik heb een Express.js-applicatie naar Hostinger geïmplementeerd en later Connector gebruikt om een bijgewerkte versie vanuit VS Code te publiceren. Hostinger detecteerde Express, selecteerde Node.js 22.x en gebruikte de projectroot als hoofdmap tijdens de eerste implementatie via hPanel. Zodra de website bestond als een herkende Node.js-doelomgeving, werkte herhaalde implementatie via Connector succesvol.
Niet per se. In mijn gecontroleerde test rapporteerde Hostinger een voltooide build nadat ik het startscript had gewijzigd zodat het verwees naar een ontbrekend JavaScript-bestand. De opgehaalde buildlogs toonden een succesvolle installatie van afhankelijkheden, maar gaven de runtime-startfout niet weer. Controleer na deployment altijd de live website of roep een health-endpoint aan.
Niet helemaal. Connector kan ervoor zorgen dat ontwikkelaars minder vaak hun editor hoeven te verlaten, vooral voor routinematige deployments en accountcontroles. hPanel blijft nuttig voor visueel accountbeheer, eerste installatie, gedetailleerde configuratie en situaties waarin de AI de vereiste bron niet kan ontdekken of correct kan weergeven.
Beantwoord een paar eenvoudige vragen en vind de perfecte oplossing voor jou!
Hosting zoeken starten
HostAdvice.com biedt professionele web hosting beoordelingen aan, compleet onafhankelijk van andere bedrijven. Onze beoordelingen zijn onpartijdig, eerlijk en de evalutieprocedure is hetzelfde voor alle beoordelingen.
Een compensatie wordt verkregen van de bedrijven die we beoordelen. Compensatie van diensten en producten hebben geen invloed op de richting of conclusies van onze beoordelingen. De compensatie beïnvloed onze ranglijsten voor bepaalde hostbedrijven ook niet.
Deze compensatie bestaat uit de kosten van royalty's voor beoordelaars, voor het aanschaffen van de accounts en voor het testen.
