Gestire l’hosting di solito interrompe lo sviluppo. Scrivi codice in un editor, apri un pannello di hosting per creare un sito web, passi a un terminale per pacchettizzare o inviare il progetto, torni al pannello per esaminare una distribuzione e apri altri strumenti quando DNS, log o risorse del server richiedono attenzione.
Hostinger Connector riduce questo cambio di contesto. Collega i servizi Hostinger agli strumenti di coding AI tramite il Model Context Protocol (MCP), permettendoti di chiedere a un assistente AI di ispezionare o gestire risorse di hosting supportate senza lasciare il tuo editor.
Sembra comodo. Solleva anche una domanda più importante: Puoi fidarti di un assistente AI per eseguire con precisione attività reali di hosting?
Per scoprirlo, ho testato Hostinger Connector con VS Code e GitHub Copilot su un account Hostinger reale. Ho usato una piccola applicazione Express.js chiamata PulseWatch e ho seguito il flusso di lavoro dall’installazione fino alla distribuzione live. Ho testato anche le distribuzioni ripetute, i record di build, i log e il recupero dopo aver rotto deliberatamente il comando di avvio dell’applicazione.
Ecco come ho valutato Hostinger Connector nelle aree che contano di più per uno sviluppatore che deve decidere se usarlo: costo, gamma di funzionalità, usabilità quotidiana, accuratezza nell’esecuzione di attività reali e supporto disponibile quando qualcosa va storto. Ogni punteggio riflette ciò che ho effettivamente trovato durante i test, non la pagina di marketing.
| Parametro | Punteggio | Perché questo punteggio |
|---|---|---|
| Prezzi | 9.7/10 | Connector non comporta alcun costo di abbonamento separato ed è incluso gratuitamente in ogni piano. L’unico costo è la risorsa di hosting sottostante di cui avresti bisogno comunque. |
| Funzionalità | 9.5/10 | La gamma di funzionalità va oltre la distribuzione e include siti web, domini, DNS, database, campagne email, risorse VPS, log e diagnostica, coprendo più ambiti di un tipico strumento di deployment. |
| Facilità d’uso | 9.1/10 | Installazione e OAuth sono stati rapidi e non hanno richiesto configurazioni manuali, e le distribuzioni ripetute sono state semplici. La configurazione iniziale del sito Node.js ha richiesto hPanel dopo che l’AI non è riuscita a identificare un target valido, l’unica vera lacuna in un setup altrimenti fluido. |
| Accuratezza di esecuzione | 8.5/10 | Analisi del progetto, modifica del codice, packaging, distribuzione e recupero hanno funzionato bene. L’AI ha riutilizzato un dominio inventato e ha interpretato eccessivamente un controllo di accessibilità prima che quel target esistesse. |
| Supporto | 9.5/10 | Kodee ha fornito una risposta accurata e specifica a una vera domanda tecnica al primo tentativo, e il follow-up dello specialista umano è stato ancora più preciso. L’escalation ha richiesto due richieste dirette, ma sia le risposte dell’AI sia quelle umane sono state affidabili una volta ottenute. |
| Totale | 9.3/10 | Uno strumento di flusso di lavoro valido per gli utenti Hostinger che lavorano in editor abilitati all’AI. Non costa nulla in più, copre un ampio set di funzionalità e sia il setup sia il supporto hanno retto bene nei test. L’accuratezza di esecuzione sui nuovi target di distribuzione è l’area da tenere d’occhio. |
Hostinger Connector non viene venduto come prodotto autonomo. Hostinger afferma che Connector è incluso gratuitamente in ogni piano, il che significa che non c’è alcun costo mensile separato di Connector da aggiungere alla bolletta dell’hosting.
Tuttavia, “gratis” ha bisogno di contesto. Connector gestisce risorse Hostinger; non le sostituisce. Hai comunque bisogno di un servizio Hostinger idoneo di hosting, cloud, VPS, dominio, email o altro per le attività che vuoi che esegua.
Al momento di questa recensione, la pagina di destinazione di Connector evidenziava Business Web Hosting e Cloud Startup.
| Piano | Prezzo promozionale | Termine iniziale mostrato | Prezzo al rinnovo | Web app | Siti web |
|---|---|---|---|---|---|
| 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 |
I prezzi sono stati mostrati prima delle tasse applicabili. I prezzi promozionali e le tariffe di rinnovo possono cambiare, quindi controlla il totale attuale al checkout invece di giudicare il piano solo dal prezzo mensile pubblicizzato.
Osservazione sui prezzi: Non acquistare un piano superiore solo per accedere a Connector. Scegli il piano in base al numero di siti web e web app di cui hai bisogno, alle risorse richieste e al livello di supporto che desideri. Connector è un livello di gestione incluso, non il prodotto principale a essere prezzato.
Hostinger pubblicizza una garanzia di rimborso di 30 giorni per gli acquisti di hosting idonei. Non esiste una politica di rimborso separata per Connector da valutare perché Connector non comporta alcun costo autonomo.
Le azioni esatte disponibili dipendono dai servizi Hostinger presenti nel tuo account e dagli strumenti esposti al client AI connesso.
Hostinger documenta anche dei limiti di velocità. Secondo le FAQ di Connector, l’allocazione predefinita è di 60 richieste al minuto e 1,000 richieste all’ora, con le informazioni sui limiti restituite nelle intestazioni di risposta.
Questi limiti sono generosi per l’uso interattivo, anche se i flussi di lavoro automatizzati o altamente ripetitivi dovrebbero comunque evitare chiamate duplicate non necessarie.
Prima di poter giudicare se Hostinger Connector distribuisce e gestisce bene l’hosting, dovevo capire cosa serve per metterlo in funzione.
Uno strumento costruito per restare dentro l’editor perde rapidamente il suo appeal se il setup richiede la modifica di file di configurazione, la generazione di token API o autenticazioni ripetute. Questa sezione copre solo il setup. I test pratici delle attività arrivano subito dopo.
Ho installato Hostinger Connector dal VS Code Marketplace. È apparso come primo risultato quando ho cercato “Hostinger”, il publisher era indicato come Hostinger Official e l’installazione è riuscita al primo tentativo in meno di due minuti.
| Dettaglio | Risultato |
|---|---|
| Ricerca nel marketplace | Superata, apparsa immediatamente |
| Verifica del publisher | Hostinger Official |
| Installazione | Completata in meno di due minuti |
| Versione dell’estensione al momento del test | 1.3.1 |
| Installazioni nel marketplace | 8,140 |
| Valutazione degli utenti | 5 stelle, basate su due valutazioni |
L’ultima riga merita una precisazione. Cinque stelle sembrano solide, ma un campione di due recensioni non mi dice quasi nulla sull’esperienza tipica degli utenti. Non mi affiderei a quel numero nel testo della recensione.
Un prerequisito mi ha sorpreso: Hostinger Connector fornisce gli strumenti Hostinger, ma ha bisogno di un agente AI già attivo nell’editor per chiamarli davvero.
L’estensione da sola non ha nulla a cui parlare. In VS Code, quell’agente è GitHub Copilot Chat, poiché attualmente è l’interfaccia AI che VS Code espone per le chiamate agli strumenti MCP. Avevo già Copilot attivo, quindi questo non mi ha rallentato, ma i lettori dovrebbero sapere che Connector è utile solo quanto l’agente AI che sta dietro.
Senza uno installato e autenticato, non c’è nulla a cui collegarsi.
Ciò che l’installazione non ha richiesto:
L’installazione dell’estensione è stata una delle parti più fluide dell’intero test. L’unico vero intoppo è una dipendenza che Hostinger non mette in primo piano: l’estensione ha bisogno di un agente AI attivo nel tuo editor per fare davvero qualcosa.
Con l’estensione installata, la domanda successiva era se collegarla a un account reale sarebbe stato altrettanto semplice.
La connessione dell’account ha usato OAuth tramite un pulsante “1-Click Connect”. VS Code ha aperto una pagina di autorizzazione Hostinger nel mio browser, ha rilevato la mia sessione Hostinger già attiva e mi ha chiesto di approvare l’accesso per qualcosa etichettato come hostinger-mcp.
Dopo aver fatto clic su Allow, sono tornato in VS Code con la dicitura “Connected via OAuth”.
| Controllo | Risultato |
|---|---|
| Connessione con un clic | Superata |
| Browser aperto automaticamente | Superata |
| Sessione Hostinger esistente rilevata | Superata |
| Richiesto token API manuale | No |
| Schermata di autorizzazione mostrata | Sì |
| Permessi spiegati | Sì, ma in modo generico |
| Ritorno a VS Code riuscito | Superata |
La schermata di autorizzazione mi ha detto che Connector poteva gestire siti web, hosting, domini, abbonamenti e altri servizi Hostinger.
Questa è una lista di categorie, non un dettaglio permesso per permesso. Avrei voluto maggiore granularità qui, visto che “gestire abbonamenti” e “gestire siti web” coprono livelli di rischio molto diversi.
Ciò che mi ha dato un certo controllo è stato un pannello separato all’interno dell’estensione che elencava ogni categoria di strumento e mi permetteva di abilitarla o disabilitarla singolarmente:
| Categoria di strumento | Strumenti disponibili | Stato predefinito |
|---|---|---|
| Siti web | 80 | Abilitato |
| Domini | 26 | Abilitato |
| Abbonamenti e Pagamenti | 7 | Abilitato |
| Email Marketing | 12 | Abilitato |
| Ecommerce | 12 | Disabilitato |
| VPS | 62 | Disabilitato |
Questo fa 199 strumenti in totale, con 125 abilitati per impostazione predefinita. Ho lasciato Ecommerce e VPS disattivati finché non sono stato pronto a testarli direttamente, e l’estensione ha rispettato questo confine per tutta la durata del test.
Questo è il tipo di dettaglio sulla sicurezza che non compare nella pagina di marketing di Hostinger ma che conta per chiunque stia decidendo quanto accesso concedere a un assistente AI. Lo definirei un vero punto di forza.
La disconnessione dell’account è disponibile dallo stesso pannello, senza dover cambiare la password Hostinger o cercare un token memorizzato.
L’autorizzazione è stata rapida e non ha richiesto la gestione manuale di un token, ma la schermata dei permessi è ampia piuttosto che granulare. I controlli di categoria degli strumenti all’interno dell’estensione fanno molto di più per limitare il rischio reale rispetto alla schermata OAuth.
Hostinger elenca il supporto per i seguenti client, raccolti dalla schermata di onboarding dell’estensione:
| Editor o client | Elencato da Hostinger |
|---|---|
| VS Code | Sì |
| Cursor | Sì |
| Windsurf | Sì |
| Devin Desktop | Sì |
| Antigravity | Sì |
| Claude Code | Sì |
| OpenAI Codex CLI | Sì |
Ho usato VS Code con GitHub Copilot come ambiente di test principale.
Il setup mi ha detto che Connector è facile da raggiungere. Non ha ancora detto se svolge davvero bene il lavoro una volta connesso, che è la domanda più difficile a cui ho dato risposta dopo.
Installare e collegare un’estensione è la parte facile. Ciò che conta davvero è se svolge correttamente un lavoro di hosting reale, quindi ho costruito una piccola applicazione Express.js chiamata PulseWatch e ho messo Connector alla prova lungo lo stesso percorso che uno sviluppatore seguirebbe dopo l’installazione: ispezionare l’account, trovare un target di distribuzione, distribuire il progetto, aggiornarlo, ispezionare i risultati e recuperare da un fallimento che ho introdotto di proposito.
| Test | Cosa volevo scoprire |
|---|---|
| Leggere i dati dell’account | Riesce a comprendere con precisione l’account di hosting? |
| Trovare un target di distribuzione | Riesce a identificare il sito web giusto senza tirare a indovinare? |
| Analizzare il progetto Node.js | Capisce l’app prima di toccarla? |
| Distribuire PulseWatch | Riesce a spostare un progetto reale dall’editor all’hosting live? |
| Pubblicare un aggiornamento dei contenuti | È utile per il lavoro di sviluppo ordinario? |
| Ispezionare build e log | Fornisce prove utili dopo una distribuzione? |
| Distribuire una versione non funzionante | Rivela un vero guasto dell’applicazione? |
| Recuperare l’applicazione | Riesce a ripristinare in modo sicuro una release nota come valida? |
PulseWatch era volutamente semplice: un server Express, una homepage, uno script di avvio package.json e un endpoint /api/health che restituiva JSON. Quel endpoint di salute si è rivelato importante più avanti.
Una piattaforma di hosting può segnalare una build completata anche quando l’applicazione fallisce all’avvio. Un endpoint live mi ha dato un modo indipendente per verificare se il processo distribuito stesse davvero rispondendo, invece di fidarmi di un badge di stato.
Ho iniziato con prompt di sola lettura prima di consentire all’assistente di avvicinarsi a modifiche live. Se non riusciva a descrivere con precisione il mio account, avrei avuto pochi motivi per fidarmi di lui per distribuzioni, DNS o azioni VPS.
Lo strumento di elenco dei siti del Connector ha restituito cinque siti:
Il mio account in realtà ne conteneva di più. hPanel mostrava siti web distribuiti su piani Premium, Business e Growth, inclusi siti WordPress, siti PHP/HTML, progetti Website Builder e diversi domini temporanei.
In un altro prompt che chiedeva i miei piani di hosting attivi, l’assistente mi ha detto che avevo “one active hosting plan.” hPanel ne mostrava tre: Premium, Growth e Business.
| Controllo | Risultato |
|---|---|
| Elencati i siti web noti | Superata |
| Elencati tutti i piani di hosting | Fallita |
| Rilevato il piano Business inutilizzato | Fallita |
| Fatte modifiche all’account | No |
A onor del vero, quando ho contestato la discrepanza, ha corretto se stesso, ha separato chiaramente ciò che aveva verificato da ciò che aveva ipotizzato e non ha ripetuto l’affermazione sbagliata.
Quello è un modo di fallire migliore che insistere sull’errore, ma significa che la prima risposta a una domanda sull’account non dovrebbe essere presa alla lettera.
L’accesso in sola lettura ha funzionato, ma la prima risposta a qualsiasi domanda sull’account era incompleta. Si è corretto una volta contestato, il che conta, ma non avrei dovuto doverlo contestare.
Questa lacuna nella visibilità dell’account si è rivelata un’anticipazione di un problema più grande. Il vero test per capire se contasse arrivò subito dopo, quando chiesi al Connector di trovare un sito web che non gli era mai stato indicato per nome.
Qui i test hanno rivelato il punto più importante. Ho chiesto all’assistente di identificare un sito Node.js appena creato senza nominare il dominio e senza toccare alcun sito esistente.
La selezione del target è un requisito di sicurezza basilare per uno strumento che può agire su un account reale, quindi volevo vedere come gestiva l’incertezza invece di una risposta pulita.
Ecco cosa è successo, in ordine:
| Passo | Cosa ha fatto Connector | Risultato |
|---|---|---|
| 1 | Ha riutilizzato un nome di dominio di un tentativo fallito precedente: pulsewatch-temp-20260714.hostingersite.com | Questo dominio non era mai stato restituito da alcuna chiamata di elenco siti web |
| 2 | Ha eseguito un controllo di accessibilità su quel dominio | Ha restituito is_accessible: true |
| 3 | Ha trattato quel risultato come conferma dell’esistenza del sito web | Errato. L’accessibilità non è la stessa cosa di un record di sito web esistente e distribuibile |
| 4 | Ha tentato una distribuzione usando ID risorsa che non aveva verificato come ID ordine di hosting | Hostinger ha restituito [Hosting:9999] Not found, due volte |
Il problema principale: i due ID usati erano ID di risorse di dominio, non ID di ordine di hosting. Non ha mai confermato la distinzione prima di chiamare con essi uno strumento live di creazione sito web.
Quando gli ho chiesto di spiegarsi, l’assistente ha finito per fornire un resoconto accurato: aveva sempre a disposizione uno strumento funzionante per l’elenco dei siti web, ma non l’aveva richiamato dopo che avevo creato un nuovo sito tramite hPanel, quindi ha colmato il vuoto con un dominio non verificato invece di aggiornare i dati.
Quando gli ho chiesto direttamente di rieseguire quello strumento di elenco e controllare la presenza di un nuovo record, ha invece chiamato tre strumenti non correlati di ricerca distribuzioni e ha riferito che “no new website appeared,” una conclusione che le chiamate che aveva realmente eseguito non potevano supportare.
Nessuna di queste azioni ha creato un sito web indesiderato nel mio account. Le chiamate fallite non hanno lasciato nulla. Ma il modello merita di essere nominato chiaramente. In presenza di dati incompleti, l’assistente ha colmato il vuoto con un’ipotesi plausibile, ha trattato un segnale debole come prova forte e ha agito su un account reale prima che quell’ipotesi fosse verificata.
Questa è la scoperta più importante in questa sezione. Il Connector tirerà a indovinare un target e agirà su quell’ipotesi invece di fermarsi e chiedere. Qui ha fallito in modo sicuro, ma l’abitudine di trattare un segnale debole come prova è ciò a cui fare attenzione nel tuo account.
Con Connector incapace di individuare il target da solo, mi rimaneva un’unica opzione: creare io stesso il target e vedere se questo cambiava qualcosa.
Poiché Connector non riusciva a localizzare in modo affidabile il nuovo target da solo, ho completato la configurazione iniziale manualmente tramite hPanel per vedere cosa prepara Hostinger prima che la distribuzione tramite Connector diventi possibile.
Il percorso era: Create a new site → Node.js web app → temporary domain → Hostinger ha selezionato automaticamente un data center nel Regno Unito con una latenza stimata di 147ms → una scelta di tre metodi di distribuzione.
Quella terza schermata merita di essere segnalata da sola. Hostinger offre “Build with Hostinger Connector” come metodo di distribuzione proprio accanto all’importazione GitHub e al caricamento manuale dei file. L’ho selezionato aspettandomi che completasse la configurazione del sito.
Invece, mi ha reindirizzato alla pagina di installazione dello stesso Connector, che avevo già completato. Questo è un vero problema di onboarding. L’opzione presentata come percorso nativo di Connector non ha effettivamente effettuato alcun provisioning.
Sono tornato indietro e ho scelto invece il caricamento manuale dei file. Hostinger ha accettato l’archivio del mio progetto (11.46 KB, con node_modules escluso) e la schermata delle impostazioni ha mostrato un rilevamento automatico accurato:
Ho fatto clic su Deploy. È andato a buon fine e Hostinger ha assegnato un vero dominio temporaneo: orange-walrus-700988.hostingersite.com. È un dominio diverso da quello inventato in precedenza dal Connector. Ho aperto manualmente sia la homepage sia /api/health e ho confermato che entrambe funzionavano.
Il percorso manuale ha funzionato senza attriti una volta che ho smesso di aspettare che Connector lo trovasse. Il pulsante “Build with Hostinger Connector” in questa schermata dovrebbe essere corretto o rimosso. Al momento promette qualcosa che non fa.
Ora esisteva un sito web reale e confermato. La domanda successiva era se Connector si sarebbe comportato diversamente ora che aveva qualcosa di concreto da trovare.
Con un sito web reale e confermato in posizione, sono tornato al Connector e gli ho chiesto di ispezionare esattamente quel dominio. Questa volta ha funzionato bene.
| Controllo | Risultato |
|---|---|
| Riconosciuto il sito come target di distribuzione Node.js | Superata |
| Trovato il record di distribuzione completata | Superata |
| Trovato il record di build Node.js corrispondente | Superata |
| Distribuzione e build condividevano lo stesso UUID | Superata |
Questo ha confermato qualcosa di importante: i fallimenti precedenti riguardavano l’individuazione e la creazione di un nuovo target, non la capacità di Connector di lavorare con un sito Node.js una volta che ne esiste uno.
Poi ho testato la funzione che Hostinger promuove di più: fare una modifica al codice in locale e pubblicarla senza aprire hPanel.
Ho chiesto all’assistente di modificare una riga del testo della homepage, da “Monitor Every Service. Catch Every Issue.” a “Monitor Every Service. Resolve Issues Faster.”
| Passo | Risultato |
|---|---|
| Trovato il testo esistente | Superata |
| Modificata solo la riga richiesta | Superata |
| Verificata l’app localmente prima della distribuzione | Superata |
Pacchettizzato il progetto, escludendo node_modules e .git | Superata |
| Distribuito sul sito web esistente e confermato | Superata |
| Controllato lo stato della distribuzione e della build dopo | Superata |
L’intero aggiornamento ha richiesto circa un minuto. L’assistente ha segnalato la nuova distribuzione come “pending” subito dopo l’invio, semplicemente perché ha controllato prima che Hostinger avesse finito di elaborare.
Quando ho aggiornato il sito live da solo, il nuovo titolo era già presente.
I log di build recuperati dopo erano specifici e utili: 67 pacchetti aggiunti, 68 auditati, zero vulnerabilità trovate, nessun errore.
Per i siti esistenti, questo è molto vicino al flusso di lavoro che Hostinger promette. Modifica, verifica in locale, pubblica e conferma, tutto senza lasciare l’editor, in circa un minuto. Questo è il risultato migliore di tutto il test.
Una distribuzione pulita mi dice solo che il percorso felice funziona. Per capire cosa fa davvero Connector sotto pressione, ho rotto deliberatamente l’applicazione.
Uno strumento si guadagna fiducia solo quando sopravvive all’impatto con un vero errore, non solo con una demo pulita. Ho rotto deliberatamente l’applicazione per vedere se il reporting di stato e i log di Connector potessero davvero aiutarmi a diagnosticare il problema.
Prima di fare qualsiasi modifica, l’assistente ha creato un backup di package.json come package.json.bak, una buona abitudine già di per sé.
Gli ho poi fatto cambiare lo script di avvio da “start”: “node server.js” a “start”: “node missing-server.js”, un file che non esiste.
Eseguirlo in locale ha confermato un vero errore riproducibile: Error: Cannot find module ‘…/missing-server.js’.
Ho distribuito comunque la versione rotta, di proposito, per vedere cosa avrebbe segnalato Hostinger.
| Stato mostrato | Cosa ha confermato | Cosa non ha confermato |
|---|---|---|
| Build: completed | Dipendenze installate, fase di build completata | L’applicazione è davvero partita |
| Deployment: completed | Hostinger ha accettato ed elaborato la release | Ogni route era sana |
I log di build disponibili tramite Connector mostravano l’installazione riuscita delle dipendenze e nient’altro. L’errore runtime del modulo mancante non compariva affatto nei log. Uno sviluppatore che guardasse un badge verde “completed” non avrebbe motivo di sospettare che il sito fosse rotto.
Il recupero è andato liscio. L’assistente ha ripristinato package.json dal backup, ha verificato l’app localmente, ha ridistribuito e ha confermato la correzione chiamando direttamente l’endpoint /api/health live invece di fidarsi dello stato della distribuzione.
Quell’endpoint ha restituito una risposta operativa, che è stata l’unica prova in tutto il test che dimostrasse davvero che l’applicazione fosse in esecuzione.
Questa è la seconda grande scoperta. Uno stato completato non è prova di un’applicazione funzionante, e i log stessi di Connector non te lo diranno. Il recupero in sé ha funzionato bene una volta che sapevo che c’era un problema da recuperare.
Dopo un errore che un badge di stato non poteva rivelare, volevo capire dove altro la fiducia di Connector potesse superare le sue reali capacità. Le variabili d’ambiente erano il test successivo.
Ho chiesto all’assistente di aggiungere una variabile d’ambiente innocua, confermare che l’impostazione esistesse come capacità dedicata di Connector prima di toccare qualsiasi cosa, e fermarsi se non fosse così.
Ha cercato negli strumenti disponibili, non ha trovato alcuna azione dedicata alla gestione delle variabili d’ambiente Node.js e si è fermato prima di apportare qualsiasi modifica al codice o alla distribuzione.
Questo è il comportamento che volevo vedere in tutto il resto del test. Di fronte a un limite reale, si è fermato invece di tirare a indovinare. Non concluderei che Hostinger Connector non supporti le variabili d’ambiente da nessuna parte nel suo set di strumenti, solo che nessuna azione del genere era esposta durante questo test.
| Test | Risultato | Scoperta principale |
|---|---|---|
| Backup del manifest funzionante | Superata | File di recupero creato prima della modifica |
| Introduzione di un entry point mancante | Superata | Fallimento controllato aggiunto |
| Riproduzione del fallimento in locale | Superata | MODULE_NOT_FOUND confermato |
| Distribuzione della versione rotta | Superata | Hostinger ha accettato l’archivio |
| Lo stato della build rileva il fallimento | Fallita | La build mostrava ancora completed |
| I log di build rivelano l’errore runtime | Fallita | L’errore del modulo mancante era assente |
| Ripristino del manifest funzionante | Superata | Comando di avvio originale recuperato |
| Ridistribuzione della versione funzionante | Superata | Distribuzione completata |
| Verifica dell’endpoint di salute live | Superata | API ha restituito uno stato operativo |
Hostinger Connector ha svolto bene le attività ordinarie e deterministiche:
È stato più debole quando l’attività richiedeva interpretazione su dati dell’account incompleti:
Questo schema è utile quando si decide quanta autonomia concedere all’assistente.
Usa prompt ampi per ispezioni a basso rischio. Usa prompt precisi e requisiti di conferma espliciti per le azioni che modificano l’infrastruttura live.
Per esempio, invece di:
| Distribuisci questa app su un nuovo sito temporaneo Hostinger. |
usa:
| Elenca i siti web attualmente restituiti da Hostinger. Identifica un sito Node.js solo se appare in quel risultato. Mostrami il dominio esatto e la prova prima di distribuire. Non generare, inferire o riutilizzare un dominio che non sia stato restituito da Hostinger. |
Il secondo prompt restringe lo spazio di manovra dell’assistente per fare assunzioni.
Far funzionare Hostinger Connector è stato facile, senza le solite difficoltà di configurazione, e i controlli granulari per categoria di strumenti mi hanno dato un vero margine su ciò che l’AI poteva toccare.
Una volta che esisteva un sito web reale con un dominio noto, ha gestito bene il lavoro: una modifica di una sola riga è passata da editing a live in circa un minuto, con log di build utili a supporto.
Il problema è emerso prima nel processo, non dopo. Di fronte a un nuovo target che non riusciva a trovare, Connector ha inventato un dominio e ha agito su quello prima di verificare. Ha anche marcato una distribuzione rotta come “completed” mentre l’app era in realtà down, senza alcun errore runtime nei suoi log. Questo non rende lo strumento inaffidabile per i siti esistenti, ma significa che i nuovi deployment e lo stato post-distribuzione devono essere controllati una seconda volta prima di fidarsi.
Hostinger organizza il supporto attorno alla live chat e all’autoassistenza invece che ai telefoni, quindi ho concentrato i test dove la maggior parte degli utenti arriva davvero: l’assistente AI integrato in hPanel, l’escalation umana dietro di esso e la knowledge base a cui uno sviluppatore si rivolgerebbe prima di aprire una chat.
| Canale | Disponibilità | Note |
|---|---|---|
| Live chat (Kodee, AI) | 24/7 | Accessibile tramite “Ask AI” in hPanel |
| Live chat (umano) | Solo escalation | Non una coda diretta, instradata tramite Kodee |
| Email / ticket | support@hostinger.com | Finestra di risposta indicata di 1 giorno lavorativo |
| Telefono | Non offerto | Nessuna linea telefonica pubblica per il supporto generale |
| Knowledge Base | Autoassistenza | support.hostinger.com |
| Tutorial e Academy | Autoassistenza | Guide passo passo e canale YouTube |
Dato che la live chat è il canale che Hostinger indica agli sviluppatori per qualsiasi cosa urgente, e quello che con maggiore probabilità verrà davvero usato mentre si esegue il debug di una distribuzione, ho testato direttamente quel percorso invece di aprire un ticket via email.
Ho aperto la live chat tramite “Ask AI” in hPanel e ho fatto a Kodee una domanda con una risposta facile da sbagliare: se uno stato build completato su una distribuzione Node.js garantisce che l’app sia davvero in esecuzione e dove avrei trovato prove del contrario.
La prima risposta di Kodee è stata specifica e corretta:
“Completed” di solito significa che la fase di build è terminata con successo; non garantisce che l’app sia sana dopo l’avvio. Per individuare un comando di start errato o un altro crash runtime, controlla i log runtime: in hPanel vai su Websites → Dashboard → Deployments per i log di build, e poi apri stderr.log della tua app nella cartella nodejs per errori di avvio come Port already in use o Module not found.
Quella singola risposta avrebbe risolto esattamente l’ambiguità in cui il mio test di recupero da un fallimento si era imbattuto poco prima in questa recensione. Kodee ha nominato un vero file di log, la cartella corretta e ha tracciato il giusto confine tra successo della build e salute runtime.
Tuttavia, volevo anche vedere se riuscivo ad accedere a un vero agente umano, quindi ho detto a Kodee che volevo confermare la cosa con un tecnico del supporto direttamente.
Ma ottenere una persona vera è stato più difficile del previsto. Ho chiesto direttamente un agente live e sono stato reindirizzato di nuovo a Kodee due volte, ogni volta con l’idea che fosse più veloce che aspettare:
Capisco perché lo vorresti. Posso aiutarti a verificare qui stesso la build, il comando di avvio e i log runtime, che di solito è il modo più rapido per individuare il problema.
Prima di metterti in coda per uno specialista. Posso risolvere il problema e farti risparmiare l’attesa.
| Tentativo | La mia richiesta | Risposta di Kodee |
|---|---|---|
| 1 | “Puoi mettermi in contatto con un agente live?” | Ha proposto di risolverlo lui stesso |
| 2 | “Vorrei comunque parlare con un agente umano. Per favore, mettimici in contatto.” | Ha riproposto la soluzione, chiedendo dominio e comando di avvio |
| 3 | Ho cliccato “Go to human” / ho scritto “I want to continue with a human” | Ha passato l’escalation |
Ci sono volute due richieste dirette ed esplicite prima che Kodee smettesse di rimandarmi a se stesso. Per una domanda che potevo risolvere da solo, questo attrito è minore. Per qualcuno in piena interruzione che vuole una persona, è una vera fonte di frustrazione.
Quello che è successo dopo non è stato un passaggio live nel senso in cui di solito si intende “mettetemi in contatto con un umano”. Kodee ha spiegato chiaramente il modello reale:
Ho condiviso la tua richiesta con uno specialista del nostro team che esaminerà personalmente la nostra chat e mi invierà la sua risposta, che poi ti riporterò qui.
Questa è una revisione asincrona, non un trasferimento live. Kodee resta l’interfaccia; un umano rivede la trascrizione in background e Kodee inoltra la risposta quando arriva. Questa distinzione è importante per i lettori che stanno decidendo se procedere all’escalation, perché qui “agente umano” non significa che una nuova persona si unisca alla finestra della chat come accadrebbe nella maggior parte dei sistemi di live chat.
Ho spinto oltre lo stesso filo tecnico mentre aspettavo, chiedendo a Kodee di confermare il percorso esatto del log e se stderr.log è sempre popolato. Ha dato una buona risposta da solo, osservando correttamente che il log può essere vuoto se l’app non è mai partita completamente o ha scritto l’errore altrove.
La revisione dello specialista è arrivata in circa 3 minuti, attribuita in chat a una collega di nome Mayas, e ha migliorato la risposta di Kodee invece di limitarvisi a ripeterla:
domains/[your-domain]/nodejs/stderr.log è la posizione corretta. Non è sempre generato o popolato. Vedrai voci lì solo quando l’app scrive su stderr, ad esempio con eccezioni non gestite o rejection non gestite. Se il comando di avvio è errato e il processo termina in silenzio, stderr.log può essere vuoto o assente.
Mayas ha anche aggiunto due controlli di fallback che Kodee non aveva menzionato: controllare stdout.log per l’ultimo output prima di un crash e cercare una mancata riga di conferma di avvio come segno che l’app non è mai partita.
| Controllo | Risultato |
|---|---|
| Prima risposta tecnica accurata | Sì |
| Escalation umana disponibile | Sì, ma opposta due volte prima di essere concessa |
| Modello di escalation | Revisione asincrona e inoltro, non passaggio live |
| Respondente nominato | Mayas |
| Tempo di risposta per la revisione umana | Circa 3 minuti |
| Risposta umana più precisa di quella AI | Sì |
La knowledge base di Hostinger è organizzata in ampie categorie di prodotto: 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 e About Hostinger.
Nessuna di queste categorie è dedicata a Hostinger Connector. L’unico modo che ho trovato per individuare l’articolo giusto è stato cercare direttamente “Hostinger Connector”, che ha restituito cinque risultati, perlopiù solo vagamente collegati, tra cui una guida a un plugin di affiliate marketing e un articolo generale sull’hosting Node.js.
L’articolo che documenta davvero la configurazione di Connector si intitola “How to Set Up Web Hosting MCP on Local IDEs”, archiviato sotto Features → General Information.
Cercare il nome di marketing del prodotto lo ha trovato, ma un lettore che navighi per categorie o cerchi “MCP” senza conoscere il branding di Hostinger potrebbe perderlo con la stessa facilità, e la discrepanza tra il nome di marketing e il nome nella documentazione è utile da sapere prima di iniziare a cercarlo.
L’articolo in sé è ottimo una volta trovato. È stato aggiornato l’ultima volta sei giorni prima del mio test e copre:
Quel punto finale corrispondeva a qualcosa che ho incontrato direttamente durante il test: Devin Desktop viene rilevato automaticamente, mentre OpenAI Codex richiede il metodo manuale. L’articolo distingue correttamente tra i due casi.
La prima risposta di Kodee a una domanda tecnica difficile era accurata e specifica, cosa che non tutti gli assistenti di supporto AI riescono a fare. L’articolo della knowledge base che la sostiene è aggiornato e dettagliato una volta trovato, anche se il nome di marketing del prodotto e il titolo della documentazione non coincidono, quindi la ricerca è un percorso più affidabile della navigazione per categorie.
Il punto più debole è il percorso di escalation verso un umano. Kodee mi ha rimandato a se stesso due volte prima di accogliere una richiesta diretta per una persona, e anche allora “agente umano” significa una revisione asincrona inoltrata tramite la stessa chat piuttosto che un passaggio live. Una volta che un umano ha effettivamente esaminato la cosa, la risposta era migliore di quella di Kodee, più precisa e con due passaggi diagnostici extra che Kodee non aveva offerto.
Per la maggior parte delle domande Kodee da solo ti darà una risposta accurata rapidamente. Se vuoi davvero che una persona verifichi la risposta, aspettati di dover chiedere più di una volta e di attendere una risposta inoltrata anziché una conversazione live.
Sì, per gli sviluppatori che già ospitano con Hostinger e vogliono gestire distribuzioni ordinarie direttamente dall’editor. Il setup ha richiesto minuti, OAuth ha eliminato la necessità di chiavi API e, una volta che esisteva un sito web con un dominio noto, Connector ha pubblicato un aggiornamento live in circa un minuto con log a supporto. Le risposte di supporto di Kodee sono state abbastanza precise da risolvere al primo tentativo un vero problema tecnico.
Il punto critico è la fiducia, non la comodità. Di fronte a un nuovo target che non riusciva a trovare, Connector ha inventato un dominio.
Ha anche marcato una distribuzione rotta come “completed” mentre l’app era in realtà inattiva, con nessun errore runtime nei suoi log. Usalo per velocizzare il lavoro su siti che esistono già, verifica tutto ciò che fa su un target appena creato e controlla tu stesso il sito live dopo ogni distribuzione che conti davvero.
| Description | Expert Review |
|---|---|
| Hosting economico con elevate prestazioni e strumenti di gestione facili. | Read Shared Hosting Review |
| Hosting WordPress veloce e sicuro con installazione con un clic e funzionalità premi... | Read Wordpress Hosting Review |
| Hosting VPS scalabile con risorse dedicate e accesso root. | Read VPS Review |
| Hosting cloud veloce e flessibile con eccellente disponibilità e risorse scalabili. | Read Cloud Hosting Review |
| Soluzioni di hosting sicure e private con sedi di data center offshore. | Read Offshore Hosting Review |
| Hosting di posta elettronica sicuro e affidabile con funzionalità di livello profess... | Read Email Hosting Review |
| Hosting Python affidabile con ambienti flessibili per sviluppatori. | Read Python Hosting Review |
| Hosting PHP ad alte prestazioni con pieno supporto per siti Web e applicazioni dinami... | Read PHP Hosting Review |
| Hosting VPS Windows affidabile con pieno controllo e opzioni di personalizzazione. | Read Windows VPS Review |
| Hosting rapido e flessibile su misura per applicazioni Node.js con prestazioni ottima... | Read Nodejs Hosting Review |
| Hosting ottimizzato per negozi WooCommerce con elevata velocità e integrazione sicur... | Read Woocommerce Hosting Review |
| Hosting di server dedicati per esperienze di gioco Minecraft senza interruzioni. | Read Minecraft Server Hosting Review |
| Soluzioni di hosting scalabili con funzionalità avanzate per agenzie digitali e svil... | Read Agency Hosting Review |
| Hosting veloce e sicuro ottimizzato per siti ecommerce Magento. | Read Magento Hosting Review |
| Hosting basato su Linux ad alte prestazioni per operazioni di siti web stabili e sicu... | Read Linux Hosting Review |
| Soluzioni di hosting Java robuste per applicazioni web dinamiche e progetti. | Read Java Hosting Review |
| Hosting ottimizzato per siti e-commerce con prestazioni sicure, veloci e affidabili. | Read Ecommerce Hosting Review |
| Hosting Django affidabile con velocità elevate e un ambiente sicuro. | Read Django Hosting Review |
| Hosting cPanel facile da usare con prestazioni robuste e supporto affidabile. | Read Cpanel Hosting Review |
| Hosting potente per le aziende con velocità elevate, sicurezza e scalabilità. | 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 |
| Hosting SMTP dedicato per una consegna email affidabile e sicura. | Read SMTP Server Review |
| Hosting veloce e ottimizzato su misura per applicazioni web Ruby on Rails. | Read Ruby on Rails Review |
| Hosting ricco di funzionalità con integrazione OpenClaw per creare e gestire giochi ... | Read OpenClaw Review |
| Hosting veloce e affidabile con server basati nel Regno Unito per prestazioni locali ... | Read UK Hosting Review |
| Hosting conveniente e affidabile con server basati in India per un accesso a bassa la... | 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 è un’integrazione basata su MCP che collega gli ambienti di coding AI supportati ai servizi Hostinger.
Consente a un assistente AI di chiamare strumenti Hostinger supportati per attività che coinvolgono siti web, distribuzioni, domini, DNS, database, email e risorse VPS.
Connector non è una piattaforma di hosting separata e non sostituisce hPanel. Offre un altro modo per interagire con le risorse Hostinger.
Hostinger attualmente elenca:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
Hostinger afferma inoltre che potrebbero essere supportati altri client compatibili con MCP. La configurazione iniziale e il comportamento degli strumenti possono variare a seconda del client.
Hostinger Connector è gratuito da installare ed è incluso nei piani Hostinger. Non c’è alcun abbonamento separato a Connector nel prezzo mostrato durante questa recensione. È comunque necessario pagare per il servizio Hostinger sottostante, come hosting web, cloud hosting o un VPS.
No. Hostinger Connector utilizza l’autenticazione OAuth. Durante la configurazione di VS Code, ho effettuato l’accesso tramite il flusso di autorizzazione basato sul browser di Hostinger. Non ho generato una chiave API, incollato un token nell’editor o salvato credenziali in un file di configurazione.
No. Hostinger afferma che le chiamate all’API Connector interagiscono con l’account live. Usa un sito web di test, un dominio o un VPS dedicati quando impari il flusso di lavoro. Non presumere che un prompt sia simulato solo perché viene fornito tramite una chat AI.
Sì. La documentazione di Hostinger indica limiti predefiniti di:
60 richieste al minuto
1.000 richieste all’ora
Hostinger afferma inoltre che i dettagli del rate limit vengono restituiti negli header della risposta.
Questi limiti dovrebbero essere sufficienti per un uso interattivo normale. Evita chiamate ripetute non necessarie, soprattutto quando una risposta precedente contiene già le informazioni richieste.
Sì. Ho distribuito un’applicazione Express.js su Hostinger e in seguito ho usato Connector per pubblicare una versione aggiornata da VS Code. Hostinger ha rilevato Express, ha selezionato Node.js 22.x e ha usato la cartella principale del progetto come directory principale durante la distribuzione iniziale da hPanel. Una volta che il sito web esisteva come target Node.js riconosciuto, la distribuzione ripetuta tramite Connector ha funzionato correttamente.
Non necessariamente. Nel mio test controllato, Hostinger ha segnalato un build completato dopo che ho modificato lo script di avvio per fare riferimento a un file JavaScript mancante. I log di build recuperati mostravano un’installazione delle dipendenze riuscita, ma non esponevano il fallimento di avvio in fase di runtime. Verifica sempre il sito live o chiama un endpoint di health dopo la distribuzione.
Non completamente. Connector può ridurre la frequenza con cui gli sviluppatori devono lasciare il proprio editor, soprattutto per le distribuzioni di routine e i controlli dell’account. hPanel rimane utile per la gestione visiva dell’account, la configurazione iniziale, la configurazione dettagliata e nelle situazioni in cui l’AI non riesce a individuare o esporre correttamente la risorsa necessaria.
Rispondi a qualche semplice domanda e trova la soluzione perfetta per te!
Trova il tuo hosting
