Administration af hosting afbryder som regel udviklingen. Du skriver kode i et editor, åbner et hosting-dashboard for at oprette et website, skifter til en terminal for at pakke eller pushe projektet, vender tilbage til dashboardet for at inspicere en deployment og åbner flere værktøjer, når DNS, logs eller serverressourcer kræver opmærksomhed.
Hostinger Connector reducerer dette kontekstskift. Det forbinder Hostinger-tjenester med AI-kodningsværktøjer via Model Context Protocol (MCP), så du kan bede en AI-assistent om at inspicere eller administrere understøttede hostingressourcer uden at forlade dit editor.
Det lyder praktisk. Det rejser også et vigtigere spørgsmål: Kan du stole på, at en AI-assistent udfører reelle hostingopgaver korrekt?
For at finde ud af det testede jeg Hostinger Connector med VS Code og GitHub Copilot mod en rigtig Hostinger-konto. Jeg brugte en lille Express.js-applikation kaldet PulseWatch og fulgte workflowet fra installation til live deployment. Jeg testede også gentagne deploymenter, build-records, logs og gendannelse efter bevidst at have ødelagt applikationens startkommando.
Her er, hvordan jeg bedømte Hostinger Connector på de områder, der betyder mest for en udvikler, der skal beslutte, om værktøjet skal bruges: pris, funktionsomfang, daglig brugervenlighed, hvor præcist det udfører virkelige opgaver, og den support, der står bag, når noget går galt. Hver score afspejler, hvad jeg faktisk fandt under test, ikke marketing-siden.
| Parameter | Score | Hvorfor denne score |
|---|---|---|
| Priser | 9.7/10 | Connectoren har ingen separat abonnementspris overhovedet og er inkluderet gratis med alle planer. Den eneste omkostning er de underliggende hostingressourcer, du alligevel ville have brug for. |
| Funktioner | 9.5/10 | Funktionsområdet rækker ud over deployment til websites, domæner, DNS, databaser, e-mailkampagner, VPS-ressourcer, logs og diagnostik, hvilket dækker mere end et typisk deployment-værktøj. |
| Brugervenlighed | 9.1/10 | Installation og OAuth var hurtige og krævede ingen manuel konfiguration, og gentagne deploymenter var nemme. Den indledende opsætning af Node.js-websitet krævede hPanel, da AI’en ikke kunne identificere et gyldigt mål, den eneste reelle mangel i en ellers problemfri opsætning. |
| Udførelsesnøjagtighed | 8.5/10 | Projektanalyse, kodeændring, pakning, deployment og gendannelse fungerede godt. AI’en genbrugte et opfundet domæne og overfortolkede en tilgængelighedskontrol, før det mål eksisterede. |
| Support | 9.5/10 | Kodee gav et korrekt og specifikt svar på et reelt teknisk spørgsmål i første forsøg, og den menneskelige specialists opfølgning var endnu skarpere. Eskalering krævede to direkte anmodninger, men både AI- og menneskesvar var pålidelige, når de først kom. |
| Samlet | 9.3/10 | Et værdifuldt workflow-værktøj for Hostinger-brugere, der arbejder i AI-aktiverede editorer. Det koster intet ekstra, dækker et bredt funktionssæt, og både opsætning og support holdt godt under test. Udførelsesnøjagtighed omkring nye deployment-mål er det ene område, man skal holde øje med. |
Hostinger Connector sælges ikke som et selvstændigt produkt. Hostinger siger, at Connector er inkluderet gratis med alle planer, hvilket betyder, at der ikke er nogen separat månedlig Connector-afgift at lægge til din hostingregning.
“Gratis” kræver dog kontekst. Connector administrerer Hostinger-ressourcer; det erstatter dem ikke. Du skal stadig have en gyldig hosting-, cloud-, VPS-, domæne-, e-mail- eller anden Hostinger-tjeneste til de opgaver, du vil have den til at udføre.
På tidspunktet for denne anmeldelse fremhævede Connector-landing-siden Business Web Hosting og Cloud Startup.
| Plan | Promoveringspris | Forhåndsbetalt periode vist | Fornyelsespris | 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 |
Priserne blev vist før gældende skatter. Promoveringspriser og fornyelsespriser kan ændre sig, så tjek den aktuelle checkout-total i stedet for kun at vurdere planen ud fra den annoncerede månedspris.
Prisindsigt: Køb ikke en højere plan kun for at få adgang til Connector. Vælg planen ud fra antallet af websites og webapps, du har brug for, de ressourcer de kræver, og det supportniveau, du ønsker. Connector er et inkluderet administrationslag, ikke hovedproduktet, der prissættes.
Hostinger annoncerer en 30-dages pengene-tilbage-garanti for berettigede hostingkøb. Der er ingen separat Connector-refusionspolitik at vurdere, fordi Connector ikke har nogen selvstændig pris.
De præcise handlinger, der er tilgængelige, afhænger af de Hostinger-tjenester, der er i din konto, og de værktøjer, der er eksponeret for den tilkoblede AI-klient.
Hostinger dokumenterer også rate limits. Ifølge Connector FAQ er standardtilladelsen 60 anmodninger pr. minut og 1.000 anmodninger pr. time, med rate-limit-oplysninger returneret i response headers.
Disse grænser er generøse til interaktiv brug, men automatiserede eller meget gentagne workflows bør stadig undgå unødvendige duplikerede kald.
Før jeg kunne bedømme, om Hostinger Connector deployer og administrerer hosting godt, måtte jeg vide, hvad der kræves for overhovedet at få det i gang.
Et værktøj, der er bygget op omkring at blive i editoren, mister hurtigt sin appel, hvis opsætningen kræver redigering af konfigurationsfiler, generering af API-tokens eller gentagen re-autentifikation. Dette afsnit dækker kun opsætningen. Den praktiske opgavetest kommer lige efter.
Jeg installerede Hostinger Connector fra VS Code Marketplace. Den dukkede op som det første resultat, da jeg søgte efter “Hostinger”, udgiveren var angivet som Hostinger Official, og den blev installeret i første forsøg på under to minutter.
| Detalje | Resultat |
|---|---|
| Marketplace-søgning | Bestået, dukkede op med det samme |
| Verificering af udgiver | Hostinger Official |
| Installation | Færdiggjort på under to minutter |
| Udvidelsesversion på testtidspunktet | 1.3.1 |
| Marketplace-installationer | 8,140 |
| Brugervurdering | 5 stjerner, baseret på to vurderinger |
Den sidste række er værd at knytte en advarsel til. Fem stjerner lyder stærkt, men et sample på to anmeldelser fortæller mig næsten intet om den typiske brugeroplevelse. Jeg ville ikke lægge vægt på det tal i anmeldelsesteksten.
En forudsætning overraskede mig: Hostinger Connector leverer Hostinger-værktøjerne, men den har brug for en AI-agent, der allerede er aktiv i editoren, for faktisk at kunne kalde dem.
Udvidelsen i sig selv har intet at tale med. I VS Code er den agent GitHub Copilot Chat, da det i øjeblikket er den AI-grænseflade, som VS Code stiller til rådighed for MCP-værktøjskald. Jeg havde allerede Copilot aktiv, så dette bremsede mig ikke, men læserne bør vide, at Connector kun er så nyttig som den AI-agent, der sidder bagved.
Uden en installeret og indlogget agent er der intet, den kan kobles til.
Hvad installationen ikke krævede:
Selve installationen af udvidelsen var en af de mest problemfri dele af hele testen. Den eneste reelle hake er en afhængighed, Hostinger ikke fremhæver tydeligt: udvidelsen har brug for en aktiv AI-agent i din editor for overhovedet at gøre noget.
Med udvidelsen på plads var det næste spørgsmål, om forbindelsen til en rigtig konto ville være lige så enkel.
Kontoforbindelsen brugte OAuth via en “1-Click Connect”-knap. VS Code åbnede en Hostinger-autorisationsside i min browser, registrerede min eksisterende Hostinger-session og bad mig godkende adgang for noget, der hed hostinger-mcp.
Efter jeg klikkede Allow, blev jeg ført tilbage til VS Code med teksten “Connected via OAuth”.
| Tjek | Resultat |
|---|---|
| Forbindelse med ét klik | Bestået |
| Browser åbnede automatisk | Bestået |
| Eksisterende Hostinger-session blev registreret | Bestået |
| Manuelt API-token krævet | Nej |
| Autorisationsskærm vist | Ja |
| Tilladelser forklaret | Ja, men overordnet |
| Vendte tilbage til VS Code korrekt | Bestået |
Autorisationsskærmen fortalte mig, at Connectoren kunne administrere websites, hosting, domæner, abonnementer og andre Hostinger-tjenester.
Det er en kategoriliste, ikke en detaljeret tilladelsesoversigt. Jeg ville gerne have haft mere granularitet her, da “administrere abonnementer” og “administrere websites” dækker meget forskellige risikoniveauer.
Det, der gav mig en del af den kontrol, var et separat panel i udvidelsen, der viste alle værktøjskategorier og lod mig aktivere eller deaktivere hver enkelt individuelt:
| Værktøjskategori | Værktøjer tilgængelige | Standardstatus |
|---|---|---|
| Websites | 80 | Aktiveret |
| Domæner | 26 | Aktiveret |
| Abonnementer og betalinger | 7 | Aktiveret |
| E-mailmarketing | 12 | Aktiveret |
| E-commerce | 12 | Deaktiveret |
| VPS | 62 | Deaktiveret |
Det er 199 værktøjer i alt, hvoraf 125 er aktiveret som standard. Jeg lod E-commerce og VPS være slået fra, indtil jeg var klar til at teste dem direkte, og udvidelsen respekterede den grænse gennem hele testen.
Dette er den slags sikkerhedsdetalje, der ikke fremgår af Hostingers marketing-side, men som betyder noget for enhver, der overvejer, hvor meget kontoadgang man vil give en AI-assistent. Jeg vil kalde det en reel styrke.
At afbryde forbindelsen til kontoen er muligt fra det samme panel uden at skulle ændre din Hostinger-adgangskode eller lede efter et gemt token.
Autorisation var hurtig og krævede ikke, at jeg selv håndterede et token, men tilladelsesskærmen er bred snarere end granular. Kategori-baserede værktøjskontroller i udvidelsen gør mere for at begrænse den reelle risiko end OAuth-skærmen gør.
Hostinger angiver support for følgende klienter, hentet fra udvidelsens egen onboarding-skærm:
| Editor eller klient | Angivet af Hostinger |
|---|---|
| VS Code | Ja |
| Cursor | Ja |
| Windsurf | Ja |
| Devin Desktop | Ja |
| Antigravity | Ja |
| Claude Code | Ja |
| OpenAI Codex CLI | Ja |
Jeg brugte VS Code med GitHub Copilot som mit primære testmiljø.
Opsætningen fortalte mig, at Connector er let at komme til. Den sagde endnu intet om, hvorvidt den faktisk løser opgaven godt, når først den er forbundet, hvilket er det sværere spørgsmål, jeg tog fat på derefter.
Installation og forbindelse af en udvidelse er den lette del. Det, der faktisk betyder noget, er, om den udfører reelt hostingarbejde korrekt, så jeg byggede en lille Express.js-applikation kaldet PulseWatch og satte Connectoren igennem samme forløb, som en udvikler ville følge efter installationen: inspicere kontoen, finde et deployment-mål, deploye projektet, opdatere det, inspicere resultaterne og gendanne efter en fejl, jeg bevidst introducerede.
| Test | Hvad jeg ville lære |
|---|---|
| Læs kontodata | Kan den forstå hostingkontoen korrekt? |
| Find et deployment-mål | Kan den identificere det rigtige website uden at gætte? |
| Analyser Node.js-projektet | Forstår den appen, før den rører ved den? |
| Deploy PulseWatch | Kan den flytte et rigtigt projekt fra editor til live hosting? |
| Udgiv en indholdsopdatering | Er den nyttig til rutinemæssigt udviklingsarbejde? |
| Inspicer builds og logs | Giver den brugbare beviser efter en deployment? |
| Deploy en ødelagt version | Afslører den en reel applikationsfejl? |
| Gendan applikationen | Kan den sikkert gendanne en kendt god version? |
PulseWatch var bevidst enkel: en Express-server, en hjemmeside, et package.json-startscript og et /api/health-endpoint, der returnerer JSON. Det health-endpoint viste sig at være vigtigt senere.
En hostingplatform kan rapportere et færdigt build, samtidig med at applikationen fejler ved opstart. Et live endpoint gav mig en uafhængig måde at tjekke, om den deployede proces faktisk svarede, i stedet for at stole på en status-badge.
Jeg begyndte med skrivebeskyttede prompts, før jeg overhovedet lod assistenten komme i nærheden af live ændringer. Hvis den ikke kunne beskrive min konto korrekt, havde jeg kun ringe grund til at stole på den med deploymenter, DNS eller VPS-handlinger.
Connectorens website-listningsværktøj returnerede fem sites:
Min konto indeholdt faktisk flere end det. hPanel viste websites fordelt på Premium-, Business- og Growth-planer, inklusive WordPress-sites, PHP/HTML-sites, Website Builder-projekter og flere midlertidige domæner.
På en separat prompt, der spurgte om mine aktive hostingplaner, fortalte assistenten mig, at jeg havde “one active hosting plan.” hPanel viste tre: Premium, Growth og Business.
| Tjek | Resultat |
|---|---|
| Listede kendte websites | Bestået |
| Listede alle hostingplaner | Fejlet |
| Opdagede den ubrugte Business-plan | Fejlet |
| Foretog ændringer i kontoen | Nej |
Fair nok for Connectoren korrigerede den sig selv, da jeg udfordrede den og påpegede uoverensstemmelsen, den skelnede tydeligt mellem det, den havde verificeret, og det, den havde antaget, og den gentog ikke den forkerte påstand.
Det er en bedre fejltilstand end at holde fast i noget forkert, men det betyder, at det første svar på et konto-omfattende spørgsmål ikke bør tages for gode varer.
Skrivebeskyttet adgang fungerede, men det første svar på ethvert konto-omfattende spørgsmål var ufuldstændigt. Det korrigerede sig selv, når det blev udfordret, hvilket er vigtigt, men jeg burde ikke have været nødt til at udfordre det.
Det hul i kontooverblikket viste sig at være en forsmag på et større problem. Den reelle test af, om det betød noget, kom næste gang, da jeg bad Connectoren om at finde et website, den aldrig var blevet fortalt om ved navn.
Det er her, testen afslørede mest. Jeg bad assistenten om at identificere et nyoprettet Node.js-website uden at jeg navngav dets domæne og uden at røre ved et eksisterende site.
Målvalg er et grundlæggende sikkerhedskrav for et værktøj, der kan handle på en live konto, så jeg ville se, hvordan det håndterede usikkerhed frem for et rent svar.
Her er, hvad der skete, i rækkefølge:
| Trin | Hvad Connectoren gjorde | Resultat |
|---|---|---|
| 1 | Genbrugte et domænenavn fra et tidligere mislykket forsøg: pulsewatch-temp-20260714.hostingersite.com | Dette domæne var aldrig blevet returneret af noget website-listningskald |
| 2 | Kørte en tilgængelighedskontrol på det domæne | Returnerede is_accessible: true |
| 3 | Tolkede det resultat som bekræftelse på, at websitet eksisterede | Forkert. Tilgængelighed er ikke det samme som en eksisterende, deploybar webstedsrecord |
| 4 | Forsøgte deployment ved brug af ressource-ID’er, som den ikke havde verificeret som hosting-order-ID’er | Hostinger returnerede [Hosting:9999] Not found, to gange |
Hovedproblemet: de to ID’er, den brugte, var domæneresource-ID’er, ikke hosting-order-ID’er. Den bekræftede aldrig forskellen, før den kaldte et live website-oprettelsesværktøj med dem.
Da jeg bad den forklare sig, gav assistenten til sidst en korrekt forklaring: den havde haft et fungerende website-listningsværktøj til rådighed hele tiden, men kaldte det aldrig igen, efter jeg oprettede et nyt site gennem hPanel, så den udfyldte hullet med et uverificeret domæne i stedet for at opdatere sine data.
Da jeg direkte bad den om at køre det listningsværktøj igen og tjekke efter en ny record, kaldte den i stedet tre ikke-relaterede deployment-lookup-værktøjer og rapporterede “no new website appeared,” en konklusion, som de værktøjskald, den faktisk lavede, ikke kunne understøtte.
Intet af dette skabte et uønsket website i min konto. De mislykkede kald efterlod intet. Men mønsteret er værd at nævne direkte. Med ufuldstændige data udfyldte assistenten hullet med en plausibel antagelse, tog et svagt signal som stærkt bevis og handlede på en live konto, før antagelsen blev kontrolleret.
Dette er det vigtigste fund i dette afsnit. Connectoren vil gætte på et mål og handle på det gæt i stedet for at stoppe og spørge. Den fejlede sikkert her, men vanen med at behandle et svagt signal som bevis er det, du skal være opmærksom på i din egen konto.
Da Connectoren ikke selv kunne lokalisere målet, havde jeg kun én mulighed tilbage: at bygge målet selv og se, om det ændrede noget.
Da Connectoren ikke pålideligt kunne finde det nye mål på egen hånd, afsluttede jeg den indledende opsætning manuelt via hPanel for at se, hvad Hostinger forbereder, før Connector-baseret deployment bliver muligt.
Forløbet var: Opret et nyt site → Node.js webapp → midlertidigt domæne → Hostinger valgte automatisk et datacenter i Storbritannien med en anslået latenstid på 147ms → et valg mellem tre deploymentmetoder.
Den tredje skærm er værd at fremhæve i sig selv. Hostinger tilbyder “Build with Hostinger Connector” som en deploymentmetode side om side med GitHub-import og manuel filupload. Jeg valgte den i forventning om, at den ville færdiggøre opsætningen af websitet.
I stedet sendte den mig videre til Connectorens egen installationsside, som jeg allerede havde gennemført. Det er et reelt onboarding-hul. Den mulighed, der blev præsenteret som en Connector-nativ vej, provisionerede faktisk ingenting.
Jeg gik tilbage og valgte manuel filupload i stedet. Hostinger accepterede mit projektarkiv (11.46 KB, med node_modules udeladt), og indstillingsskærmen viste korrekt automatisk registrering:
Jeg klikkede Deploy. Det blev gennemført succesfuldt, og Hostinger tildelte et rigtigt midlertidigt domæne: orange-walrus-700988.hostingersite.com. Det er et andet domæne end det, Connectoren havde opfundet tidligere. Jeg åbnede både hjemmesiden og /api/health manuelt og bekræftede, at begge virkede.
Den manuelle vej fungerede uden friktion, når jeg først holdt op med at vente på, at Connectoren skulle finde den. Knappen “Build with Hostinger Connector” på denne skærm bør rettes eller fjernes. Lige nu lover den noget, den ikke gør.
Et rigtigt, bekræftet website eksisterede nu. Det næste spørgsmål var, om Connectoren ville opføre sig anderledes nu, hvor den havde noget solidt at finde.
Med et rigtigt, bekræftet website på plads vendte jeg tilbage til Connectoren og bad den inspicere det præcise domæne. Denne gang virkede det gnidningsfrit.
| Tjek | Resultat |
|---|---|
| Genkendte sitet som et Node.js-deployment-mål | Bestået |
| Fandt den færdige deployment-record | Bestået |
| Fandt den matchende Node.js-build-record | Bestået |
| Deployment og build delte samme UUID | Bestået |
Det bekræftede noget vigtigt: de tidligere fejl handlede om at lokalisere og oprette et nyt mål, ikke om Connectorens evne til at arbejde med et Node.js-site, når først et eksisterer.
Dernæst testede jeg den funktion, Hostinger markedsfører mest: at lave en kodeændring lokalt og udgive den uden at åbne hPanel.
Jeg bad assistenten om at ændre én linje tekst på hjemmesiden fra “Monitor Every Service. Catch Every Issue.” til “Monitor Every Service. Resolve Issues Faster.”
| Trin | Resultat |
|---|---|
| Fandt den eksisterende tekst | Bestået |
| Ændrede kun den ønskede linje | Bestået |
| Verificerede appen lokalt før deployment | Bestået |
Pakkede projektet uden node_modules og .git | Bestået |
| Deployede til det eksisterende, bekræftede website | Bestået |
| Tjekkede deployment- og build-status efterfølgende | Bestået |
Hele opdateringen tog omkring ét minut. Assistenten rapporterede den nye deployment som “pending” umiddelbart efter afsendelsen, simpelthen fordi den tjekkede, før Hostinger var færdig med at behandle den.
Da jeg opdaterede det live site selv, var den nye overskrift allerede der.
De build-logs, den hentede bagefter, var specifikke og nyttige: 67 packages tilføjet, 68 auditeret, zero vulnerabilities found, ingen fejl.
For etablerede sites er dette tæt på det workflow, Hostinger lover. Redigér, verificér lokalt, send ud, og bekræft, alt sammen uden at forlade editoren, på omkring et minut. Dette er det stærkeste resultat i hele testen.
En ren deployment siger kun, at happy path virker. For at finde ud af, hvad Connectoren faktisk gør under pres, ødelagde jeg applikationen med vilje.
Et værktøj fortjener kun tillid, når det overlever mødet med en reel fejl, ikke kun en ren demo. Jeg ødelagde bevidst applikationen for at se, om Connectorens statusrapportering og logs faktisk kunne hjælpe mig med at diagnosticere den.
Før nogen ændring tog assistenten backup af package.json til package.json.bak, en god vane i sig selv.
Jeg lod derefter den ændre startscriptet fra “start”: “node server.js” til “start”: “node missing-server.js”, en fil, der ikke findes.
At køre det lokalt bekræftede en reel, reproducerbar fejl: Error: Cannot find module ‘…/missing-server.js’.
Jeg deployede den ødelagte version alligevel, med vilje, for at se, hvad Hostinger ville rapportere.
| Viste status | Hvad det bekræftede | Hvad det ikke bekræftede |
|---|---|---|
| Build: completed | Afhængigheder installeret, build-fasen afsluttet | At applikationen faktisk startede |
| Deployment: completed | Hostinger accepterede og behandlede udgivelsen | At hver route var sund |
De build-logs, der var tilgængelige via Connectoren, viste vellykket installation af afhængigheder og intet andet. Den manglende module runtime-fejl dukkede aldrig op i dem. En udvikler, der kigger på en grøn “completed”-badge, ville ikke have nogen grund til at mistænke, at sitet var ødelagt.
Gendannelsen gik glat. Assistenten genskabte package.json fra sin backup, verificerede appen lokalt, deployede igen og bekræftede rettelsen ved at kalde det live /api/health-endpoint direkte i stedet for at stole på deployment-status alene.
Det endpoint returnerede et operationelt svar, som var det eneste bevis i hele testen, der faktisk viste, at applikationen kørte.
Dette er det andet store fund. En completed-status er ikke bevis på en fungerende applikation, og Connectorens egne logs vil ikke fortælle dig det. Selve gendannelsen fungerede godt, når jeg først vidste, at der var et problem at gendanne.
Efter en fejl, som et statusbadge ikke kunne afsløre, ville jeg vide, hvor ellers Connectorens selvtillid kunne løbe foran dens faktiske evne. Miljøvariabler var den næste test.
Jeg bad assistenten om at tilføje en harmløs miljøvariabel, bekræfte, at indstillingen fandtes som en dedikeret Connector-funktion, før den rørte noget, og stoppe, hvis den ikke gjorde.
Den søgte i de tilgængelige værktøjer, fandt ingen dedikeret handling til at administrere Node.js-miljøvariabler og stoppede, før den foretog nogen kode- eller deploymentændringer.
Dette er den adfærd, jeg gerne ville se overalt i denne test. Stillet over for en reel begrænsning stoppede den i stedet for at gætte. Jeg vil ikke konkludere, at Hostinger Connector ikke har understøttelse af miljøvariabler nogen steder i dens værktøjssæt, kun at ingen sådan handling var eksponeret under denne test.
| Test | Resultat | Vigtigste fund |
|---|---|---|
| Lav backup af fungerende manifest | Bestået | Gendannelsesfil oprettet før ændring |
| Indfør manglende entry point | Bestået | Kontrolleret fejl tilføjet |
| Genskab fejlen lokalt | Bestået | MODULE_NOT_FOUND bekræftet |
| Deploy ødelagt version | Bestået | Hostinger accepterede arkivet |
| Build-status opdager fejl | Fejlet | Build viste stadig completed |
| Build-logs afslører runtime-fejl | Fejlet | Missing-module-fejl var fraværende |
| Genskab fungerende manifest | Bestået | Originalt startscript gendannet |
| Redeploy fungerende version | Bestået | Deployment færdiggjort |
| Verificer live health-endpoint | Bestået | API returnerede operationel status |
Hostinger Connector udførte rutinemæssige, deterministiske opgaver godt:
Den var svagere, når opgaven krævede fortolkning på tværs af ufuldstændige kontodata:
Dette mønster er nyttigt, når du skal beslutte, hvor meget autonomi du vil give assistenten.
Brug bredere prompts til lavrisiko-inspektion. Brug præcise prompts og eksplicitte krav om bekræftelse til handlinger, der ændrer live infrastruktur.
For eksempel, i stedet for:
| Deploy denne app til et nyt midlertidigt Hostinger-site. |
brug:
| List de websites, der aktuelt returneres af Hostinger. Identificér kun et Node.js-website, hvis det fremgår af det resultat. Vis mig det præcise domæne og beviset, før du deployer. Generér, slut ikke, og genbrug ikke et domæne, der ikke blev returneret af Hostinger. |
Den anden prompt indsnævrer assistentens spillerum for antagelser.
Det var nemt at få Hostinger Connector i gang, uden den sædvanlige opsætningsfriktion, og de granulerede værktøjskategori-kontroller gav mig reel indflydelse på, hvad AI’en kunne røre ved.
Når først et rigtigt website eksisterede med et kendt domæne, håndterede den opgaven godt: en ændring af én linje tekst gik fra redigering til live på omkring et minut, understøttet af nyttige build-logs.
Problemet viste sig tidligere i forløbet, ikke senere. Stillet over for et nyt mål, den ikke kunne finde, opfandt Connectoren et domæne og handlede på det, før det blev kontrolleret. Den markerede også en ødelagt deployment som “completed”, selv om appen faktisk var nede. Ingen af delene gør værktøjet upålideligt for etablerede sites, men begge betyder, at nye deploymenter og status efter deployment bør dobbelttjekkes, før du stoler på dem.
Hostinger bygger sin support omkring live chat og selvbetjening snarere end telefonopkald, så jeg fokuserede min test der, hvor de fleste brugere faktisk ender: AI-assistenten indbygget i hPanel, den menneskelige eskalering bagved og vidensbasen, som en udvikler ville vende sig til, før man åbner en chat.
| Kanal | Tilgængelighed | Noter |
|---|---|---|
| Live chat (Kodee, AI) | 24/7 | Tilgås via “Ask AI” i hPanel |
| Live chat (menneske) | Kun via eskalering | Ikke en direkte kø, rutes gennem Kodee |
| E-mail / ticket | support@hostinger.com | Angivet svartid på 1 business day |
| Telefon | Ikke tilbudt | Ingen offentlig telefonlinje til generel support |
| Vidensbase | Selvbetjening | support.hostinger.com |
| Vejledninger og Academy | Selvbetjening | Trin-for-trin vejledninger og en YouTube-kanal |
Da live chat er den kanal, Hostinger peger udviklere hen til for alt, der er presserende, og den kanal, der mest sandsynligt faktisk bruges under fejlfinding af en deployment, testede jeg den vej direkte i stedet for at oprette en e-mail-ticket.
Jeg åbnede live chat via “Ask AI” i hPanel og stillede Kodee et spørgsmål med et rigtigt svar, der kunne være forkert: om en completed build-status på en Node.js-deployment garanterer, at appen faktisk kører, og hvor jeg ville finde beviser for det modsatte.
Kodees første svar var specifikt og korrekt:
“Completed” betyder normalt, at build-trinnet blev afsluttet succesfuldt; det garanterer ikke, at appen er sund efter opstart. For at fange en dårlig startkommando eller andet runtime-crash skal du tjekke runtime-logs: i hPanel gå til Websites → Dashboard → Deployments for build-logs, og åbn derefter din apps stderr.log i nodejs mappen for startup-fejl som Port already in use eller Module not found.
Det ene svar ville have løst netop den tvetydighed, som min fejl- og gendannelsestest tidligere i denne anmeldelse stødte ind i. Kodee navngav en rigtig logfil, den korrekte mappe og trak den rigtige linje mellem build-succes og runtime-sundhed.
Jeg ville dog også se, om jeg kunne få adgang til en rigtig menneskelig agent, så jeg fortalte Kodee, at jeg gerne ville bekræfte dette direkte med en supportmedarbejder.
Men at få et menneske på linjen var sværere, end jeg havde forventet. Jeg bad direkte om en live agent og blev sendt tilbage til Kodee to gange, hver gang med en forklaring om, at det var hurtigere end at vente:
Jeg forstår godt, hvorfor du gerne vil det. Jeg kan hjælpe dig med at verificere build, startkommando og runtime-logs her, hvilket normalt er den hurtigste måde at finde problemet på.
Før vi køer en specialist. Jeg kan løse problemet og spare dig ventetiden.
| Forsøg | Min anmodning | Kodees svar |
|---|---|---|
| 1 | “Kan du forbinde mig med en live agent?” | Tilbød at løse det selv |
| 2 | “Jeg vil stadig gerne tale med en menneskelig agent. Forbind mig venligst.” | Tilbød igen og bad om domæne og startkommando |
| 3 | Klikkede “Go to human” / skrev “I want to continue with a human” | Eskalere |
Det krævede to direkte, eksplicitte anmodninger, før Kodee holdt op med at sende mig tilbage til sig selv. For et spørgsmål, jeg selv kunne løse, er den friktion mindre. For en, der står midt i et nedbrud og ønsker en person, er det et reelt irritationspunkt.
Det, der skete derefter, var ikke et live håndoff i den forstand, man normalt forbinder med “forbind mig med et menneske”. Kodee forklarede modellen helt åbent:
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.
Dette er en asynkron gennemgang, ikke en live overførsel. Kodee forbliver interfacet; en menneskelig specialist gennemgår transskriptionen i baggrunden, og Kodee videresender svaret, når det kommer. Den forskel er vigtig for læsere, der skal beslutte, om de vil eskalere, da “menneskelig agent” her ikke betyder, at en ny person deltager i chatvinduet, som det ville være tilfældet i de fleste live-chat-systemer.
Jeg pressede den samme tekniske tråd videre, mens jeg ventede, og bad Kodee bekræfte den præcise logsti og om stderr.log altid er udfyldt. Den gav et solidt svar på egen hånd og bemærkede korrekt, at loggen kan være tom, hvis appen aldrig nåede at starte helt eller skrev sin fejl et andet sted.
Specialistens gennemgang kom efter omkring 3 minutter, tilskrevet en medarbejder ved navn Mayas i chatten, og den forbedrede Kodees svar i stedet for blot at gentage det:
domains/[your-domain]/nodejs/stderr.log er den korrekte placering. Den bliver ikke altid oprettet eller udfyldt. Du vil kun se poster der, når appen skriver til stderr, såsom ved uncaught exceptions eller unhandled rejections. Hvis startkommandoen er forkert, og processen afslutter lydløst, kan stderr.log være tom eller mangle.
Mayas tilføjede også to fallback-tjek, som Kodee ikke havde nævnt: at kontrollere stdout.log for den sidste output før et crash og se efter en manglende startup-bekræftelseslinje som tegn på, at appen aldrig startede overhovedet.
| Tjek | Resultat |
|---|---|
| Første tekniske svar korrekt | Ja |
| Menneskelig eskalering tilgængelig | Ja, men modstod to gange, før den blev givet |
| Eskaleringsmodel | Asynkron gennemgang og videresendelse, ikke live transfer |
| Navngiven responder | Mayas |
| Svartid for menneskelig gennemgang | Omkring 3 minutter |
| Menneskesvar mere præcist end AI-svar | Ja |
Hostingers vidensbase er organiseret i brede produktkategorier: 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 og About Hostinger.
Ingen af de kategorier er dedikeret til Hostinger Connector. Den eneste måde, jeg fandt den rigtige artikel på, var ved at søge direkte efter “Hostinger Connector”, hvilket gav fem resultater, hvoraf de fleste kun var løst relaterede, inklusive en guide til et affiliate marketing-plugin og en generel artikel om Node.js-hosting.
Artiklen, der faktisk dokumenterer Connector-opsætningen, hedder “How to Set Up Web Hosting MCP on Local IDEs” og ligger under Features → General Information.
At søge efter produktets faktiske marketingnavn fandt den, men en læser, der browsede kategorier eller søgte efter “MCP” uden at kende Hostingers branding, kunne lige så let overse den, og misforholdet mellem det markedsførte navn og det dokumenterede navn er værd at kende til, før du leder efter den.
Selve artiklen er stærk, når man først har fundet den. Den blev senest opdateret seks dage før min test, og den dækker:
Det sidste punkt matchede noget, jeg selv stødte på under testen: Devin Desktop bliver auto-detekteret, mens OpenAI Codex kræver den manuelle metode. Artiklen får den forskel korrekt.
Kodees første svar på et vanskeligt teknisk spørgsmål var korrekt og specifikt, hvilket ikke er noget, alle AI-supportassistenter klarer. Vidensbaseartiklen, der understøtter det, er aktuel og detaljeret, når man først finder den, men produktets marketingnavn og dets dokumentationstitel matcher ikke, så søgning er en mere pålidelig vej end at browse kategorier.
Det svagere punkt er den menneskelige eskaleringsvej. Kodee sendte mig tilbage til sig selv to gange, før den adlød en direkte anmodning om en person, og selv da betyder “menneskelig agent” en asynkron gennemgang, der videresendes gennem den samme chat, ikke en live overførsel. Da et menneske først så på det, var svaret bedre end Kodees eget, mere præcist og med to ekstra diagnosticeringsskridt, som Kodee ikke havde tilbudt.
Til de fleste spørgsmål vil Kodee alene give dig et korrekt svar hurtigt. Hvis du faktisk vil have en person til at bekræfte svaret, så forvent at skulle spørge mere end én gang, og forvent en kort ventetid på et videresendt svar i stedet for en live samtale.
Ja, for udviklere, der allerede hoster hos Hostinger og ønsker rutinemæssige deploymenter håndteret fra editoren. Opsætningen tog minutter, OAuth fjernede behovet for API-nøgler, og når først et website eksisterede med et kendt domæne, sendte Connectoren en live opdatering ud på omkring et minut med logs som dokumentation. Kodees egen support var skarp nok til at løse et reelt teknisk problem i første forsøg.
Hagen er tillid, ikke bekvemmelighed. Givet et nyt mål, den ikke kunne finde, opfandt Connectoren et domæne og handlede på det, før det blev tjekket.
Den markerede også en ødelagt deployment som “completed”, mens appen faktisk var nede, uden nogen runtime-fejl i sine egne logs. Brug den til at accelerere arbejde på sites, der allerede eksisterer, verificér alt, hvad den gør på et helt nyt mål, og tjek selv det live site efter enhver deployment, der betyder noget.
| Description | Expert Review |
|---|---|
| Budgetvenlig hosting med høj ydeevne og nemme administrationsværktøjer. | Read Shared Hosting Review |
| ast og sikker WordPress-hosting med ét-klik-installation og premiumfunktioner. | Read Wordpress Hosting Review |
| Skalerbar VPS-hosting med dedikerede ressourcer og root-adgang. | Read VPS Review |
| Hurtig, fleksibel cloud-hosting med fremragende oppetid og skalerbare ressourcer. | Read Cloud Hosting Review |
| Sikre og private hostingløsninger med offshore datacenterlokationer. | Read Offshore Hosting Review |
| Sikker og pålidelig e-mailhosting med professionelle funktioner. | Read Email Hosting Review |
| Pålidelig Python-hosting med fleksible miljøer til udviklere. | Read Python Hosting Review |
| Højtydende PHP-hosting med fuld support til dynamiske websites og applikationer. | Read PHP Hosting Review |
| Pålidelig Windows VPS-hosting med fuld kontrol og tilpasningsmuligheder. | Read Windows VPS Review |
| Hurtig og fleksibel hosting skræddersyet til Node.js-applikationer med optimal ydeev... | Read Nodejs Hosting Review |
| Optimeret hosting til WooCommerce-butikker med høj hastighed og sikker integration. | Read Woocommerce Hosting Review |
| Dedikeret serverhosting til problemfri Minecraft-spiloplevelser. | Read Minecraft Server Hosting Review |
| Skalerbare hostingløsninger med avancerede funktioner til digitale bureauer og udvik... | Read Agency Hosting Review |
| Hurtig, sikker hosting optimeret til Magento e-handelswebsites. | Read Magento Hosting Review |
| Højtydende Linux-baseret hosting til stabil og sikker drift af websites. | Read Linux Hosting Review |
| Robuste Java-hostingløsninger til dynamiske webapplikationer og projekter. | Read Java Hosting Review |
| Optimeret hosting til e-handelswebsites med sikker, hurtig og pålidelig ydeevne. | Read Ecommerce Hosting Review |
| Pålidelig Django-hosting med hurtige hastigheder og et sikkert miljø. | Read Django Hosting Review |
| Brugervenlig cPanel-hosting med robust ydeevne og pålidelig support. | Read Cpanel Hosting Review |
| Kraftfuld hosting til virksomheder med hurtige hastigheder, sikkerhed, og skalerbarhe... | 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 |
| Dedikeret SMTP-serverhosting til pålidelig og sikker e-maillevering. | Read SMTP Server Review |
| Hurtig og optimeret hosting skræddersyet til Ruby on Rails-webapplikationer. | Read Ruby on Rails Review |
| Funktionsrig hosting med OpenClaw-integration til at bygge og administrere claw machi... | Read OpenClaw Review |
| Hurtig og pålidelig hosting med servere baseret i Storbritannien for optimal lokal y... | Read UK Hosting Review |
| Overkommelig og pålidelig hosting med India-baserede servere for lav-latensadgang. | 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 er en MCP-baseret integration, der forbinder understøttede AI-kodningsmiljøer med Hostinger-tjenester.
Det giver en AI-assistent mulighed for at kalde understøttede Hostinger-værktøjer til opgaver, der involverer websites, deployment, domæner, DNS, databaser, e-mail og VPS-ressourcer.
Connector er ikke en separat hostingplatform og erstatter ikke hPanel. Det giver en anden måde at interagere med Hostinger-ressourcer på.
Hostinger angiver i øjeblikket:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger siger også, at andre MCP-kompatible klienter kan være understøttet. Opsætning og værktøjsadfærd kan variere mellem klienter.
Hostinger Connector er gratis at installere og inkluderet i Hostinger-planer. Der er intet separat Connector-abonnement i den pris, der vises under denne anmeldelse. Du skal stadig betale for den underliggende Hostinger-tjeneste, såsom webhosting, cloudhosting eller en VPS.
Nej. Hostinger Connector bruger OAuth-godkendelse. Under min VS Code-opsætning loggede jeg ind via Hostingers browserbaserede godkendelsesflow. Jeg genererede ikke en API-nøgle, indsatte ikke en token i editoren og gemte ikke legitimationsoplysninger i en konfigurationsfil.
Nej. Hostinger siger, at Connector API-kald interagerer med den live konto. Brug en dedikeret testwebsted, domæne eller VPS, når du lærer workflowet. Antag ikke, at en prompt er simuleret, blot fordi den er udstedt via en AI-chat.
Ja. Hostinger dokumenterer standardgrænser på:
60 anmodninger pr. minut
1.000 anmodninger pr. time
Hostinger siger også, at detaljer om ratebegrænsning returneres i svarheadere.
Disse grænser burde være tilstrækkelige til normal interaktiv brug. Undgå unødvendige gentagne kald, især når et tidligere svar allerede indeholder de nødvendige oplysninger.
Ja. Jeg implementerede en Express.js-applikation på Hostinger og brugte senere Connector til at publicere en opdateret version fra VS Code. Hostinger registrerede Express, valgte Node.js 22.x og brugte projektroden som rodmappen under den indledende hPanel-implementering. Da webstedet først eksisterede som et genkendt Node.js-mål, fungerede gentagen implementering via Connector korrekt.
Ikke nødvendigvis. I min kontrollerede test rapporterede Hostinger et fuldført build efter at jeg ændrede startscriptet til at referere til en manglende JavaScript-fil. De hentede build-logs viste en vellykket installation af afhængigheder, men afslørede ikke startfejlen under kørsel. Verificér altid den live hjemmeside eller kald et health-endpoint efter deployment.
Ikke helt. Connector kan reducere, hvor ofte udviklere behøver at forlade deres editor, især ved rutinemæssige implementeringer og kontotjek. hPanel er stadig nyttigt til visuel kontoadministration, indledende opsætning, detaljeret konfiguration og i situationer, hvor AI’en ikke kan finde eller eksponere den nødvendige ressource korrekt.
Besvar nogle få enkle spørgsmål og find den perfekte løsning til dig!
Start søgning efter hosting
Hostadvice.com udbyder professionelle anmeldelser om web-hosting, helt uafhængigt af andre virksomheder. Vores anmeldelser er objektive, ærlige, og anvender den samme evaluering til alle de anmeldte.
Økonomisk kompensation modtages fra de firmaer vi anmelder. Kompensation i form af service og produkter, har ingen indflydelse på retningen eller konklusionen af vores anmeldelser. Ej heller påvirker kompensationen vores ranglister for visse hostfirmaer.
Støt hjemmesideejernes fællesskab, ved at tilføje din ærlige anmeldelse af web-hostingudbyderen for din hjemmeside
