Gerenciar hospedagem geralmente interrompe o desenvolvimento. Você escreve código em um editor, abre um painel de hospedagem para criar um site, alterna para um terminal para empacotar ou enviar o projeto, retorna ao painel para inspecionar uma implantação e abre mais ferramentas quando DNS, logs ou recursos do servidor precisam de atenção.
Hostinger Connector reduz essa alternância de contexto. Ele conecta os serviços da Hostinger a ferramentas de codificação por IA por meio do Model Context Protocol (MCP), permitindo que você peça a um assistente de IA para inspecionar ou gerenciar recursos de hospedagem compatíveis sem sair do editor.
Isso parece conveniente. Também levanta uma pergunta mais importante: Você pode confiar em um assistente de IA para executar tarefas reais de hospedagem com precisão?
Para descobrir, testei o Hostinger Connector com o VS Code e o GitHub Copilot em uma conta real da Hostinger. Usei um pequeno aplicativo Express.js chamado PulseWatch e segui o fluxo de trabalho desde a instalação até a implantação ao vivo. Também testei implantações repetidas, registros de build, logs e recuperação depois de quebrar deliberadamente o comando de inicialização do aplicativo.
Aqui está como atribuí notas ao Hostinger Connector nas áreas que mais importam para um desenvolvedor decidir se deve usá-lo: custo, amplitude de recursos, usabilidade no dia a dia, quão precisamente ele executa tarefas reais e o suporte disponível quando algo dá errado. Cada nota reflete o que realmente encontrei durante os testes, não a página de marketing.
| Parâmetro | Nota | Por que essa nota |
|---|---|---|
| Preços | 9.7/10 | O Connector não tem nenhuma taxa de assinatura separada e vem incluído gratuitamente em todos os planos. O único custo é o recurso de hospedagem subjacente que você precisaria de qualquer forma. |
| Recursos | 9.5/10 | A gama de recursos vai além da implantação e cobre websites, domínios, DNS, bancos de dados, campanhas de email, recursos de VPS, logs e diagnósticos, abrangendo mais do que uma ferramenta típica de deploy. |
| Facilidade de Uso | 9.1/10 | A instalação e o OAuth foram rápidos e não exigiram configuração manual, e as implantações repetidas foram fáceis. A configuração inicial do site Node.js exigiu o hPanel porque a IA não conseguiu identificar um destino válido, a única lacuna real em uma configuração de outro modo tranquila. |
| Precisão de Execução | 8.5/10 | A análise do projeto, a edição de código, o empacotamento, a implantação e a recuperação funcionaram bem. A IA reutilizou um domínio inventado e interpretou demais uma verificação de acessibilidade antes de esse destino existir. |
| Suporte | 9.5/10 | Kodee deu uma resposta precisa e específica a uma pergunta técnica real na primeira tentativa, e o acompanhamento do especialista humano foi ainda mais afiado. Escalar levou dois pedidos diretos, mas tanto as respostas da IA quanto as humanas foram confiáveis depois de dadas. |
| Geral | 9.3/10 | Uma ferramenta de fluxo de trabalho valiosa para usuários da Hostinger que trabalham em editores com IA. Não custa nada a mais, cobre um amplo conjunto de recursos e tanto a configuração quanto o suporte se saíram bem nos testes. A precisão de execução em novos destinos de implantação é o ponto a observar. |
O Hostinger Connector não é vendido como um produto independente. A Hostinger informa que o Connector está incluído gratuitamente em todos os planos, o que significa que não há cobrança mensal separada do Connector para acrescentar à sua fatura de hospedagem.
No entanto, “gratuito” precisa de contexto. O Connector gerencia recursos da Hostinger; ele não os substitui. Você ainda precisa de um serviço elegível de hospedagem, cloud, VPS, domínio, email ou outro serviço Hostinger para as tarefas que deseja que ele execute.
No momento desta análise, a página de destino do Connector destacava Business Web Hosting e Cloud Startup.
| Plano | Preço promocional | Prazo inicial exibido | Preço de renovação | Web apps | Websites |
|---|---|---|---|---|---|
| Business | $3.79/month | $181.92 for 48 months | $16.99/month | 5 | 50 |
| Cloud Startup | $7.99/month | $383.52 for 48 months | $25.99/month | 10 | Unlimited |
Os preços eram exibidos antes dos impostos aplicáveis. Os preços promocionais e as taxas de renovação podem mudar, então verifique o total atual no checkout em vez de julgar o plano apenas pelo valor mensal anunciado.
Insight sobre preços: Não compre um plano mais caro apenas para acessar o Connector. Escolha o plano de acordo com o número de websites e web apps de que você precisa, os recursos que eles exigem e o nível de suporte que você quer. O Connector é uma camada de gerenciamento incluída, não o produto principal que está sendo precificado.
A Hostinger anuncia uma garantia de reembolso de 30 dias para compras de hospedagem elegíveis. Não há uma política separada de reembolso do Connector a avaliar porque o Connector não tem uma taxa independente.
As ações exatas disponíveis dependem dos serviços Hostinger em sua conta e das ferramentas expostas ao cliente de IA conectado.
A Hostinger também documenta limites de taxa. De acordo com o FAQ do Connector, a permissão padrão é de 60 solicitações por minuto e 1.000 solicitações por hora, com informações de limite de taxa retornadas nos cabeçalhos de resposta.
Esses limites são generosos para uso interativo, embora fluxos de trabalho automatizados ou altamente repetitivos devam ainda evitar chamadas duplicadas desnecessárias.
Antes de eu poder julgar se o Hostinger Connector implanta e gerencia hospedagem bem, eu precisava saber o que é necessário para colocá-lo para funcionar em primeiro lugar.
Uma ferramenta construída para permanecer dentro do editor perde rapidamente seu apelo se a configuração significar editar arquivos de configuração, gerar tokens de API ou reautenticação repetida. Esta seção cobre apenas a configuração. Os testes práticos de tarefas vêm logo depois.
Instalei o Hostinger Connector na VS Code Marketplace. Ele apareceu como o primeiro resultado quando busquei “Hostinger”, o editor listou o publisher como Hostinger Official, e a instalação foi concluída na primeira tentativa em menos de dois minutos.
| Detalhe | Resultado |
|---|---|
| Busca na marketplace | Aprovada, apareceu imediatamente |
| Verificação do publisher | Hostinger Official |
| Instalação | Concluída em menos de dois minutos |
| Versão da extensão no momento do teste | 1.3.1 |
| Instalações na marketplace | 8,140 |
| Avaliação de usuários | 5 estrelas, com base em duas avaliações |
Essa última linha merece uma ressalva. Cinco estrelas parecem fortes, mas uma amostra de duas avaliações me diz quase nada sobre a experiência típica do usuário. Eu não apoiaria a copy da análise nessa nota.
Um pré-requisito me surpreendeu: o Hostinger Connector fornece as ferramentas da Hostinger, mas precisa de um agente de IA já ativo no editor para realmente chamá-las.
A extensão em si não tem com o que se comunicar sozinha. No VS Code, esse agente é o GitHub Copilot Chat, já que ele é atualmente a interface de IA que o VS Code expõe para chamadas de ferramentas MCP. Eu já tinha o Copilot ativo, então isso não me atrasou, mas os leitores devem saber que o Connector só é útil se houver um agente de IA por trás dele.
Sem um instalado e autenticado, não há nada a que ele possa se conectar.
O que a instalação não exigiu:
Instalar a extensão em si foi uma das partes mais tranquilas de todo o teste. A única ressalva real é uma dependência que a Hostinger não destaca logo de cara: a extensão precisa de um agente de IA ativo no seu editor para fazer qualquer coisa.
Com a extensão instalada, a próxima pergunta era se conectá-la a uma conta real seria tão simples quanto.
A conexão da conta usou OAuth por meio de um botão “1-Click Connect”. O VS Code abriu uma página de autorização da Hostinger no meu navegador, detectou minha sessão existente da Hostinger e pediu que eu aprovasse o acesso para algo rotulado como hostinger-mcp.
Depois que cliquei em Allow, voltei ao VS Code vendo “Connected via OAuth.”
| Verificação | Resultado |
|---|---|
| Conexão em um clique | Aprovada |
| Navegador abriu automaticamente | Aprovada |
| Sessão existente da Hostinger detectada | Aprovada |
| Token de API manual foi exigido | Não |
| Tela de autorização exibida | Sim |
| Permissões explicadas | Sim, mas de forma ampla |
| Retorno ao VS Code com sucesso | Aprovada |
A tela de autorização me informou que o Connector poderia gerenciar websites, hospedagem, domínios, assinaturas e outros serviços Hostinger.
Isso é uma lista de categorias, não um detalhamento de permissão por permissão. Eu teria gostado de mais granularidade aqui, já que “gerenciar assinaturas” e “gerenciar websites” cobrem níveis de risco muito diferentes.
O que me deu um pouco desse controle foi um painel separado dentro da extensão que lista cada categoria de ferramenta e permite ativar ou desativar cada uma individualmente:
| Categoria de ferramenta | Ferramentas disponíveis | Status padrão |
|---|---|---|
| Websites | 80 | Ativado |
| Domínios | 26 | Ativado |
| Assinaturas e Pagamentos | 7 | Ativado |
| Email Marketing | 12 | Ativado |
| Ecommerce | 12 | Desativado |
| VPS | 62 | Desativado |
Isso totaliza 199 ferramentas, com 125 ativadas por padrão. Mantive Ecommerce e VPS desativados até estar pronto para testá-los diretamente, e a extensão respeitou esse limite durante todo o teste.
Esse é o tipo de detalhe de segurança que não aparece na página de marketing da Hostinger, mas que importa para qualquer pessoa decidindo quanto acesso conceder a um assistente de IA. Eu chamaria isso de um ponto forte genuíno.
Desconectar a conta está disponível no mesmo painel, sem precisar alterar sua senha da Hostinger ou procurar por um token armazenado.
A autorização foi rápida e não exigiu que eu gerenciasse um token manualmente, mas a tela de permissão é ampla em vez de granular. Os controles de ferramentas em nível de categoria dentro da extensão fazem mais para limitar o risco real do que a tela OAuth.
A Hostinger lista suporte para os seguintes clientes, reunidos da tela de onboarding da própria extensão:
| Editor ou cliente | Listado pela Hostinger |
|---|---|
| VS Code | Sim |
| Cursor | Sim |
| Windsurf | Sim |
| Devin Desktop | Sim |
| Antigravity | Sim |
| Claude Code | Sim |
| OpenAI Codex CLI | Sim |
Usei VS Code com GitHub Copilot como meu ambiente principal de teste.
A configuração me disse que o Connector é fácil de acessar. Ainda não dizia nada sobre se ele realmente faz bem o trabalho depois de conectado, que é a pergunta mais difícil que eu tratei em seguida.
Instalar e conectar uma extensão é a parte fácil. O que realmente importa é se ela executa bem o trabalho real de hospedagem, então construí um pequeno aplicativo Express.js chamado PulseWatch e coloquei o Connector no mesmo caminho que um desenvolvedor seguiria depois de instalá-lo: inspecionar a conta, encontrar um destino de implantação, implantar o projeto, atualizá-lo, inspecionar os resultados e recuperar-se de uma falha que introduzi de propósito.
| Teste | O que eu queria descobrir |
|---|---|
| Ler dados da conta | Ele consegue entender a conta de hospedagem com precisão? |
| Encontrar um destino de implantação | Ele consegue identificar o website certo sem adivinhar? |
| Analisar o projeto Node.js | Ele entende o app antes de mexer nele? |
| Implantar o PulseWatch | Ele consegue mover um projeto real do editor para a hospedagem ao vivo? |
| Publicar uma atualização de conteúdo | Ele é útil para trabalho rotineiro de desenvolvimento? |
| Inspecionar builds e logs | Ele fornece evidências úteis após uma implantação? |
| Implantar uma versão quebrada | Ele revela uma falha real do aplicativo? |
| Recuperar o aplicativo | Ele consegue restaurar uma versão conhecida e boa com segurança? |
O PulseWatch foi deliberadamente simples: um servidor Express, uma homepage, um script start do package.json e um endpoint /api/health retornando JSON. Esse endpoint de saúde acabou sendo importante mais tarde.
Uma plataforma de hospedagem pode relatar um build concluído mesmo enquanto o aplicativo falha na inicialização. Um endpoint ao vivo me deu uma forma independente de verificar se o processo implantado realmente estava respondendo, em vez de confiar em um selo de status.
Comecei com prompts somente de leitura antes de permitir que o assistente chegasse perto de mudanças reais. Se ele não conseguisse descrever minha conta com precisão, eu teria pouca razão para confiar nele com implantações, DNS ou ações de VPS.
A ferramenta de listagem de websites do Connector retornou cinco sites:
Minha conta na verdade continha mais do que isso. O hPanel mostrava websites distribuídos entre planos Premium, Business e Growth, incluindo sites WordPress, sites PHP/HTML, projetos do Website Builder e vários domínios temporários.
Em um prompt separado perguntando sobre meus planos de hospedagem ativos, o assistente me disse que eu tinha “one active hosting plan.” O hPanel mostrava três: Premium, Growth e Business.
| Verificação | Resultado |
|---|---|
| Listou websites conhecidos | Aprovado |
| Listou todos os planos de hospedagem | Falhou |
| Detectou o plano Business não utilizado | Falhou |
| Fez alguma alteração na conta | Não |
Para ser justo com o Connector, quando eu contestei e apontei a discrepância, ele se corrigiu, separou claramente o que tinha verificado do que tinha assumido e não repetiu a afirmação incorreta.
Essa é uma falha melhor do que insistir no erro, mas isso significa que a primeira resposta a uma pergunta sobre a conta não deve ser aceita pelo valor de face.
Acesso somente leitura funcionou, mas a primeira resposta a qualquer pergunta em nível de conta ficou incompleta. Ele se corrigiu quando contestado, o que importa, mas eu não deveria ter precisado contestá-lo.
Essa lacuna na visibilidade da conta acabou sendo um prenúncio de um problema maior. O teste real de se isso importava veio em seguida, quando pedi ao Connector que encontrasse um website que nunca havia sido informado a ele pelo nome.
Aqui foi onde o teste revelou mais. Pedi ao assistente para identificar um website Node.js recém-criado sem nomear o domínio, e sem tocar em nenhum site existente.
A seleção de destino é um requisito básico de segurança para uma ferramenta que pode agir sobre uma conta real, então eu queria ver como ela lidava com a incerteza em vez de uma resposta limpa.
Veja o que aconteceu, na ordem:
| Etapa | O que o Connector fez | Resultado |
|---|---|---|
| 1 | Reutilizou um nome de domínio de uma tentativa anterior malsucedida: pulsewatch-temp-20260714.hostingersite.com | Esse domínio nunca havia sido retornado por nenhuma chamada de listagem de websites |
| 2 | Executou uma verificação de acessibilidade nesse domínio | Retornou is_accessible: true |
| 3 | Tratou esse resultado como confirmação de que o website existia | Incorreto. Acessibilidade não é o mesmo que um registro existente e implantável de website |
| 4 | Tentou a implantação usando IDs de recursos que não havia verificado como IDs de pedido de hospedagem | A Hostinger retornou [Hosting:9999] Not found, duas vezes |
O problema principal: os dois IDs que ele usou eram IDs de recurso de domínio, não IDs de pedido de hospedagem. Ele nunca confirmou a distinção antes de chamar uma ferramenta de criação de site em produção com eles.
Quando pedi que explicasse, o assistente eventualmente deu um relato preciso: ele tinha uma ferramenta de listagem de websites funcionando o tempo todo, mas não a chamou novamente depois que criei um novo site pelo hPanel, então preencheu a lacuna com um domínio não verificado em vez de atualizar seus dados.
Quando pedi diretamente para ele executar novamente essa ferramenta de listagem e verificar se havia um novo registro, ele chamou três ferramentas de consulta de implantação não relacionadas e relatou “no new website appeared,” uma conclusão que as chamadas de ferramentas que ele realmente fez não poderiam ter sustentado.
Nada disso criou um website extra na minha conta. As chamadas malsucedidas não deixaram nada para trás. Mas o padrão vale a pena ser nomeado com clareza. Diante de dados incompletos, o assistente preencheu a lacuna com uma suposição plausível, tratou um sinal fraco como evidência forte e agiu sobre uma conta real antes que essa suposição fosse verificada.
Esta é a descoberta mais importante desta seção. O Connector vai adivinhar um destino e agir com base nessa suposição em vez de parar e perguntar. Ele falhou de forma segura aqui, mas o hábito de tratar um sinal fraco como prova é o que você deve observar na sua própria conta.
Com o Connector incapaz de localizar o destino por conta própria, eu tinha apenas uma opção: construir o destino manualmente e ver se isso mudava alguma coisa.
Como o Connector não conseguiu localizar de forma confiável o novo destino por conta própria, concluí a configuração inicial manualmente no hPanel para ver o que a Hostinger prepara antes que a implantação via Connector se torne possível.
O caminho foi: Criar um novo site → Node.js web app → domínio temporário → a Hostinger selecionou automaticamente um data center no Reino Unido com latência estimada de 147ms → uma escolha de três métodos de implantação.
Aquela terceira tela merece destaque por si só. A Hostinger oferece “Build with Hostinger Connector” como um método de implantação ao lado de importação do GitHub e upload manual de arquivos. Selecionei-o esperando que concluísse a configuração do site.
Em vez disso, ele me redirecionou para a própria página de instalação do Connector, que eu já havia concluído. Isso é uma lacuna real de onboarding. A opção apresentada como um caminho nativo do Connector não provisionou nada de fato.
Voltei e escolhi upload manual de arquivos. A Hostinger aceitou meu arquivo compactado do projeto (11.46 KB, com node_modules excluído), e a tela de configurações mostrou autodetecção precisa:
Cliquei em Deploy. Ele foi concluído com sucesso, e a Hostinger atribuiu um domínio temporário real: orange-walrus-700988.hostingersite.com. Esse é um domínio diferente daquele que o Connector havia inventado antes. Abri manualmente a homepage e /api/health e confirmei que ambos funcionavam.
O caminho manual funcionou sem atrito assim que parei de esperar que o Connector encontrasse o alvo. O botão “Build with Hostinger Connector” nessa tela deveria ser corrigido ou removido. No momento, ele promete algo que não faz.
Agora existia um website real e confirmado. A próxima pergunta era se o Connector se comportaria de forma diferente agora que tinha algo sólido para encontrar.
Com um website real e confirmado em funcionamento, voltei ao Connector e pedi que inspecionasse exatamente esse domínio. Dessa vez funcionou limpo.
| Verificação | Resultado |
|---|---|
| Reconheceu o site como um destino de implantação Node.js | Aprovado |
| Encontrou o registro de implantação concluída | Aprovado |
| Encontrou o registro de build Node.js correspondente | Aprovado |
| A implantação e o build compartilharam o mesmo UUID | Aprovado |
Isso confirmou algo importante: as falhas anteriores eram sobre localizar e criar um novo destino, não sobre a capacidade do Connector de trabalhar com um site Node.js depois que ele existe.
Em seguida, testei o recurso que a Hostinger promove com mais força: fazer uma alteração de código localmente e publicá-la sem abrir o hPanel.
Pedi ao assistente para alterar uma linha do texto da homepage, de “Monitor Every Service. Catch Every Issue.” para “Monitor Every Service. Resolve Issues Faster.”
| Etapa | Resultado |
|---|---|
| Encontrou o texto existente | Aprovado |
| Alterou apenas a linha solicitada | Aprovado |
| Verificou o app localmente antes de implantar | Aprovado |
Empacotou o projeto, excluindo node_modules e .git | Aprovado |
| Implantou no website existente e confirmado | Aprovado |
| Verificou o status de implantação e build depois | Aprovado |
Todo o update levou cerca de um minuto. O assistente relatou a nova implantação como “pending” imediatamente após enviá-la, simplesmente porque verificou antes de a Hostinger terminar o processamento.
Quando atualizei o site ao vivo manualmente, o novo título já estava lá.
Os logs de build que ele recuperou depois eram específicos e úteis: 67 packages adicionados, 68 auditados, zero vulnerabilidades encontradas, sem erros.
Para sites estabelecidos, isso está perto do fluxo de trabalho que a Hostinger promete. Editar, verificar localmente, publicar e confirmar, tudo sem sair do editor, em cerca de um minuto. Este é o melhor resultado de todo o teste.
Um deploy limpo apenas me diz que o caminho feliz funciona. Para descobrir o que o Connector realmente faz sob pressão, quebrei o aplicativo de propósito.
Uma ferramenta só conquista confiança quando sobrevive ao contato com uma falha real, não apenas a uma demonstração limpa. Eu quebrei o aplicativo deliberadamente para ver se o status e os logs do Connector realmente poderiam me ajudar a diagnosticá-lo.
Antes de fazer qualquer alteração, o assistente fez backup de package.json para package.json.bak, um bom hábito por si só.
Depois pedi que ele alterasse o script start de “start”: “node server.js” para “start”: “node missing-server.js”, um arquivo que não existe.
Executá-lo localmente confirmou uma falha real e reproduzível: Error: Cannot find module ‘…/missing-server.js’.
Implantei a versão quebrada mesmo assim, de propósito, para ver o que a Hostinger relataria.
| Status exibido | O que confirmou | O que não confirmou |
|---|---|---|
| Build: completed | Dependências instaladas, etapa de build concluída | O aplicativo realmente iniciou |
| Deployment: completed | A Hostinger aceitou e processou a release | Toda rota estava saudável |
Os logs de build acessíveis pelo Connector mostraram a instalação bem-sucedida das dependências e nada mais. O erro de runtime de módulo ausente nunca apareceu neles. Um desenvolvedor olhando apressadamente para um selo verde de “completed” não teria motivo para suspeitar que o site estava quebrado.
A recuperação correu bem. O assistente restaurou package.json a partir do backup, verificou o app localmente, fez o redeploy e confirmou a correção chamando diretamente o endpoint /api/health ao vivo em vez de confiar apenas no status da implantação.
Esse endpoint retornou uma resposta operacional, que foi a única evidência em todo o teste que realmente provou que o aplicativo estava em execução.
Esta é a segunda grande descoberta. Um status concluído não é prova de um aplicativo funcionando, e os próprios logs do Connector não vão dizer isso a você. A recuperação em si funcionou bem depois que eu soube que havia um problema para recuperar.
Depois de uma falha que um selo de status não conseguiu revelar, eu queria saber em que outros pontos a confiança do Connector poderia superar sua capacidade real. As variáveis de ambiente foram o próximo teste.
Pedi ao assistente para adicionar uma variável de ambiente inofensiva, confirmar que a configuração existia como um recurso dedicado do Connector antes de tocar em qualquer coisa e parar se não existisse.
Ele pesquisou nas ferramentas disponíveis, não encontrou nenhuma ação dedicada para gerenciar variáveis de ambiente do Node.js e parou antes de fazer qualquer alteração no código ou na implantação.
Esse é o comportamento que eu queria ver em todo o teste. Confrontado com um limite real, ele parou em vez de adivinhar. Eu não concluiria que o Hostinger Connector não tem suporte a variáveis de ambiente em lugar nenhum do seu conjunto de ferramentas, apenas que nenhuma ação desse tipo foi exposta durante este teste.
| Teste | Resultado | Conclusão principal |
|---|---|---|
| Fazer backup do manifesto funcional | Aprovado | Arquivo de recuperação criado antes da modificação |
| Introduzir ponto de entrada ausente | Aprovado | Falha controlada adicionada |
| Reproduzir a falha localmente | Aprovado | MODULE_NOT_FOUND confirmado |
| Implantar versão quebrada | Aprovado | A Hostinger aceitou o arquivo compactado |
| O status do build detecta falha | Falhou | O build ainda mostrava completed |
| Os logs de build expõem erro em runtime | Falhou | O erro de módulo ausente não apareceu |
| Restaurar manifesto funcional | Aprovado | Comando original de inicialização recuperado |
| Fazer redeploy da versão funcional | Aprovado | Implantação concluída |
| Verificar endpoint de saúde ao vivo | Aprovado | A API retornou status operacional |
O Hostinger Connector executou bem tarefas rotineiras e determinísticas:
Ele foi mais fraco quando a tarefa exigia interpretação em dados de conta incompletos:
Esse padrão é útil ao decidir quanta autonomia dar ao assistente.
Use prompts mais amplos para inspeções de baixo risco. Use prompts precisos e requisitos explícitos de confirmação para ações que alteram a infraestrutura ao vivo.
Por exemplo, em vez de:
| Implante este app em um novo site temporário da Hostinger. |
use:
| Liste os websites atualmente retornados pela Hostinger. Identifique um website Node.js somente se ele aparecer nesse resultado. Mostre-me o domínio exato e a evidência antes de implantar. Não gere, infira ou reutilize um domínio que não tenha sido retornado pela Hostinger. |
O segundo prompt restringe o espaço de suposição do assistente.
Colocar o Hostinger Connector para funcionar foi fácil, sem o atrito típico de configuração, e os controles granulares por categoria de ferramenta me deram uma influência real sobre o que a IA podia tocar.
Depois que um website real existiu com um domínio conhecido, ele executou bem a tarefa: uma alteração de uma linha do texto passou de edição para ao vivo em cerca de um minuto, com logs úteis para comprovar.
O problema apareceu antes, não depois. Diante de um novo destino que ele não conseguiu encontrar, o Connector inventou um domínio e agiu com base nele antes de verificar. Ele também marcou uma implantação quebrada como “completed” enquanto o app na verdade estava fora do ar, sem erro de runtime em seus próprios logs. Nenhum dos problemas torna a ferramenta não confiável para sites estabelecidos, mas ambos significam que novos deploys e o status pós-implantação precisam de uma segunda verificação antes de você confiar neles.
A Hostinger estrutura seu suporte em torno de chat ao vivo e autoatendimento em vez de chamadas telefônicas, então concentrei meus testes onde a maioria dos usuários realmente cairá: o assistente de IA embutido no hPanel, a escalada humana por trás dele e a base de conhecimento que um desenvolvedor consultaria antes de abrir um chat.
| Canal | Disponibilidade | Observações |
|---|---|---|
| Chat ao vivo (Kodee, IA) | 24/7 | Acessado via “Ask AI” no hPanel |
| Chat ao vivo (humano) | Somente por escalada | Não é uma fila direta, encaminhada por Kodee |
| Email / ticket | support@hostinger.com | Tempo de resposta informado de 1 business day |
| Telefone | Não oferecido | Sem linha telefônica pública para suporte geral |
| Base de Conhecimento | Autoatendimento | support.hostinger.com |
| Tutoriais e Academy | Autoatendimento | Guias passo a passo e um canal no YouTube |
Como o chat ao vivo é o canal para o qual a Hostinger aponta desenvolvedores para qualquer coisa urgente, e o que provavelmente seria usado enquanto se depura uma implantação, testei esse caminho diretamente em vez de abrir um ticket por email.
Abri o chat ao vivo por meio de “Ask AI” no hPanel e fiz ao Kodee uma pergunta com uma resposta real que poderia errar: se um status de build concluído em uma implantação Node.js garante que o app esteja realmente em execução, e onde eu encontraria evidências do contrário.
A primeira resposta de Kodee foi específica e correta:
“Completed” geralmente significa que a etapa de build terminou com sucesso; isso não garante que o app esteja saudável após o lançamento. Para detectar um comando de inicialização ruim ou outra falha em runtime, verifique os logs de runtime: no hPanel vá para Websites → Dashboard → Deployments para os logs de build e, em seguida, abra o seu stderr.log na pasta nodejs para erros de inicialização como Port already in use ou Module not found.
Essa única resposta teria resolvido a mesma ambiguidade com a qual meu teste de recuperação de falha esbarrou mais cedo nesta análise. Kodee nomeou um arquivo de log real, a pasta correta, e traçou a linha certa entre sucesso de build e saúde em runtime.
No entanto, eu também queria ver se consigo acesso a um agente humano de verdade, então disse a Kodee que gostaria de confirmar isso diretamente com um engenheiro de suporte.
Mas conseguir um humano no chat foi mais difícil do que eu esperava. Pedi diretamente um atendente ao vivo e fui redirecionado de volta para Kodee duas vezes, cada vez apresentado como mais rápido do que esperar:
Entendo por que você gostaria disso. Posso ajudar a verificar o build, o start command e os logs de runtime aqui mesmo, o que geralmente é a maneira mais rápida de localizar o problema.
Antes de acionar um especialista. Posso resolver o problema e poupar sua espera.
| Tentativa | Meu pedido | Resposta de Kodee |
|---|---|---|
| 1 | “Can you connect me with a live agent?” | Ofereceu resolver ele mesmo |
| 2 | “I’d still like to speak with a human agent. Please connect me.” | Ofereceu de novo, pediu domínio e start command |
| 3 | Cliquei em “Go to human” / digitei “I want to continue with a human” | Escalou |
Foram necessários dois pedidos diretos e explícitos antes que Kodee parasse de me redirecionar de volta para si mesmo. Para uma pergunta que eu poderia resolver sozinho, essa fricção é pequena. Para alguém no meio de uma interrupção que quer uma pessoa, é um ponto real de frustração.
O que aconteceu depois não foi uma transferência ao vivo no sentido em que “connect me with a human” normalmente implica. Kodee explicou o modelo real de forma clara:
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.
Isso é uma revisão assíncrona, não uma transferência ao vivo. Kodee continua sendo a interface; um humano revisa o transcript em segundo plano e Kodee transmite a resposta quando ela chega. Essa distinção importa para leitores que estão decidindo se devem escalar, já que “agente humano” aqui não significa que uma nova pessoa entre na janela do chat como em outros sistemas de chat ao vivo.
Eu avancei no mesmo tópico técnico enquanto esperava, pedindo a Kodee para confirmar o caminho exato dos logs e se stderr.log está sempre preenchido. Ele deu uma resposta sólida por conta própria, observando corretamente que o log pode ficar vazio se o app nunca tiver iniciado totalmente ou gravado o erro em outro lugar.
A revisão do especialista chegou em cerca de 3 minutos, creditada no chat a um colega chamado Mayas, e melhorou a resposta de Kodee em vez de apenas repeti-la:
domains/[your-domain]/nodejs/stderr.log é o local correto. Ele nem sempre é gerado ou preenchido. Você só verá entradas ali quando o app escrever em stderr, como com exceções não tratadas ou rejeições não tratadas. Se o start command estiver errado e o processo sair silenciosamente, stderr.log pode estar vazio ou ausente.
Mayas também acrescentou duas verificações alternativas que Kodee não havia mencionado: verificar stdout.log para a última saída antes de uma falha e procurar por uma linha de confirmação de inicialização ausente como sinal de que o app nunca iniciou.
| Verificação | Resultado |
|---|---|
| Primeira resposta técnica correta | Sim |
| Escalada para humano disponível | Sim, mas resistiu duas vezes antes de conceder |
| Modelo de escalada | Revisão assíncrona e repasse, não transferência ao vivo |
| Responder nomeado | Mayas |
| Tempo de resposta para revisão humana | Cerca de 3 minutos |
| Resposta humana mais precisa que a da IA | Sim |
A base de conhecimento da Hostinger é organizada em categorias amplas de produto: 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.
Nenhuma dessas categorias é dedicada ao Hostinger Connector. A única forma de eu encontrar o artigo certo foi pesquisar diretamente por “Hostinger Connector”, o que retornou cinco resultados, a maioria apenas vagamente relacionada, incluindo um guia de plugin de marketing de afiliados e um artigo geral sobre hospedagem Node.js.
O artigo que realmente documenta a configuração do Connector se chama “How to Set Up Web Hosting MCP on Local IDEs”, listado em Features → General Information.
Pesquisar pelo nome de marketing do produto o encontrou, mas um leitor navegando por categorias ou pesquisando “MCP” sem conhecer a marca da Hostinger poderia não encontrá-lo com a mesma facilidade, e a discrepância entre o nome de marketing e o nome na documentação vale a pena ser conhecida antes de você procurar.
O artigo em si é forte depois que você o encontra. Ele foi atualizado pela última vez seis dias antes do meu teste, e cobre:
Esse último ponto correspondeu a algo que encontrei diretamente durante o teste: Devin Desktop é detectado automaticamente, enquanto OpenAI Codex requer o método manual. O artigo acerta essa distinção.
A primeira resposta de Kodee a uma pergunta técnica difícil foi correta e específica, o que não é algo que todo assistente de suporte de IA consegue fazer. O artigo da base de conhecimento que sustenta isso é atual e detalhado depois que você o encontra, embora o nome de marketing do produto e o título da documentação não coincidam, então a busca é um caminho mais confiável do que navegar pelas categorias.
O ponto mais fraco é o caminho de escalada humana. Kodee me redirecionou de volta para si mesmo duas vezes antes de atender a um pedido direto por uma pessoa, e mesmo assim “agente humano” significa uma revisão assíncrona repassada pelo mesmo chat em vez de uma transferência ao vivo. Quando um humano finalmente analisou o caso, a resposta foi melhor que a de Kodee, mais precisa e com dois passos diagnósticos extras que Kodee não havia oferecido.
Para a maioria das perguntas, Kodee sozinho lhe dará uma resposta precisa rapidamente. Se você realmente quiser que uma pessoa verifique a resposta, espere ter de pedir mais de uma vez e espere uma espera curta por uma resposta repassada em vez de uma conversa ao vivo.
Sim, para desenvolvedores que já hospedam com a Hostinger e querem lidar com implantações rotineiras no editor. A configuração levou minutos, o OAuth eliminou qualquer necessidade de chaves de API, e, depois que um website existia com um domínio conhecido, o Connector publicou uma atualização ao vivo em cerca de um minuto com logs para comprovar. As respostas de suporte do próprio Kodee foram afiadas o suficiente para resolver um problema técnico real na primeira tentativa.
O porém é a confiança, não a conveniência. Diante de um novo destino que ele não conseguiu encontrar, o Connector inventou um domínio e agiu com base nele antes de verificar.
Ele também marcou uma implantação quebrada como “completed” enquanto o app na verdade estava fora do ar, sem nenhum erro de runtime em seus próprios logs. Use-o para acelerar o trabalho em sites que já existem, verifique qualquer coisa que ele fizer em um novo destino e confira o site ao vivo você mesmo após qualquer implantação que importe.
| Description | Expert Review |
|---|---|
| Hospedagem econômica com alto desempenho e ferramentas de gerenciamento fáceis. | Read Shared Hosting Review |
| Hospedagem WordPress rápida e segura com instalação em um clique e recursos premiu... | Read Wordpress Hosting Review |
| Hospedagem VPS escalável com recursos dedicados e acesso root. | Read VPS Review |
| Hospedagem em nuvem rápida, flexível com excelente tempo de atividade e recursos es... | Read Cloud Hosting Review |
| Soluções de hospedagem seguras e privadas com data centers offshore. | Read Offshore Hosting Review |
| Hospedagem de e-mail segura e confiável com recursos de nível profissional. | Read Email Hosting Review |
| Hospedagem Python confiável com ambientes flexíveis para desenvolvedores. | Read Python Hosting Review |
| Hospedagem PHP de alto desempenho com suporte completo para sites e aplicações din�... | Read PHP Hosting Review |
| Hospedagem VPS Windows confiável com controle total e opções de personalização. | Read Windows VPS Review |
| Hospedagem rápida e flexível sob medida para aplicações Node.js com desempenho id... | Read Nodejs Hosting Review |
| Hospedagem otimizada para lojas WooCommerce com alta velocidade e integração segura... | Read Woocommerce Hosting Review |
| Hospedagem de servidor dedicado para experiências de jogo de Minecraft sem interrup�... | Read Minecraft Server Hosting Review |
| Soluções de hospedagem escaláveis com recursos avançados para agências digitais ... | Read Agency Hosting Review |
| Hospedagem rápida e segura otimizada para sites de comércio eletrônico Magento. | Read Magento Hosting Review |
| Hospedagem baseada em Linux de alto desempenho para operações de sites estáveis e ... | Read Linux Hosting Review |
| Soluções robustas de hospedagem Java para aplicações web dinâmicas e projetos. | Read Java Hosting Review |
| Hospedagem otimizada para websites de ecommerce com desempenho seguro, rápido e conf... | Read Ecommerce Hosting Review |
| Hospedagem confiável para Django com velocidades rápidas e ambiente seguro. | Read Django Hosting Review |
| Hospedagem cPanel fácil de usar com desempenho robusto e suporte confiável. | Read Cpanel Hosting Review |
| Hospedagem poderosa para empresas com alta velocidade, segurança e escalabilidade. | 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 |
| Hospedagem de servidor SMTP dedicado para entrega de e-mails confiável e segura. | Read SMTP Server Review |
| Hospedagem rápida e otimizada, feita sob medida para aplicações web Ruby on Rails. | Read Ruby on Rails Review |
| Hospedagem rica em recursos com integração OpenClaw para construir e gerenciar jogo... | Read OpenClaw Review |
| Hospedagem rápida e confiável com servidores baseados no Reino Unido para desempenh... | Read UK Hosting Review |
| Hospedagem acessível e confiável com servidores baseados na Índia para acesso de b... | 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 |
O Hostinger Connector é uma integração baseada em MCP que conecta ambientes de programação de IA compatíveis aos serviços da Hostinger.
Ele permite que um assistente de IA chame ferramentas da Hostinger compatíveis para tarefas relacionadas a sites, implementações, domínios, DNS, bancos de dados, e-mail e recursos de VPS.
O Connector não é uma plataforma de hospedagem separada e não substitui o hPanel. Ele oferece outra forma de interagir com os recursos da Hostinger.
A Hostinger atualmente lista:
– VS Code
– Cursor
– Devin
– Antigravity
– Claude
– Codex
A Hostinger também diz que outros clientes compatíveis com MCP podem ser suportados. A configuração e o comportamento das ferramentas podem diferir entre os clientes.
O Hostinger Connector é gratuito para instalar e está incluído nos planos da Hostinger. Não há uma assinatura separada do Connector nos preços mostrados durante esta análise. Você ainda precisa pagar pelo serviço Hostinger subjacente, como hospedagem web, hospedagem em nuvem ou um VPS.
Não. O Hostinger Connector usa autenticação OAuth. Durante a minha configuração no VS Code, entrei através do fluxo de autorização baseado no navegador da Hostinger. Não gerei uma chave de API, não colei um token no editor e não armazenei credenciais em um ficheiro de configuração.
Não. A Hostinger diz que as chamadas da API Connector interagem com a conta real. Use um site, domínio ou VPS de teste dedicado ao aprender o fluxo de trabalho. Não assuma que um prompt é simulado apenas porque é emitido por meio de um chat de IA.
Sim. A documentação da Hostinger indica limites padrão de:
– 60 solicitações por minuto
– 1.000 solicitações por hora
A Hostinger também informa que os detalhes do limite de taxa são retornados nos cabeçalhos da resposta.
Esses limites devem ser suficientes para o uso interativo normal. Evite chamadas repetidas desnecessárias, especialmente quando uma resposta anterior já contém as informações necessárias.
Sim. Implantei uma aplicação Express.js na Hostinger e, mais tarde, usei o Connector para publicar uma versão atualizada a partir do VS Code. A Hostinger detectou o Express, selecionou Node.js 22.x e usou a raiz do projeto como diretório raiz durante a implantação inicial no hPanel. Assim que o site passou a existir como um destino Node.js reconhecido, a implantação repetida através do Connector funcionou com sucesso.
Não necessariamente. No meu teste controlado, a Hostinger relatou uma build concluída depois que alterei o script de início para referenciar um arquivo JavaScript ausente. Os logs de build obtidos mostraram a instalação bem-sucedida das dependências, mas não expuseram a falha de inicialização em tempo de execução. Verifique sempre o site ao vivo ou chame um endpoint de saúde após a implantação.
Não completamente. O Connector pode reduzir a frequência com que os desenvolvedores precisam sair do editor, especialmente para implantações rotineiras e verificações de conta. O hPanel continua sendo útil para gerenciamento visual da conta, configuração inicial, configuração detalhada e situações em que a IA não consegue descobrir ou expor corretamente o recurso necessário.
Responda a algumas perguntas simples e encontre a solução perfeita para você!
Iniciar pesquisa de hospedagem
HostAdvice.com fornece opiniões profissionais sobre hospedagem Web totalmente independentes de qualquer outra entidade. Nossas análises são imparciais, honestas e aplicam os mesmos parâmetros para todos os hosts.
Recebemos uma compensação monetária das empresas que analisamos. A remuneração de serviços e produtos não tem nenhuma influência sobre a direção ou as conclusões de nossos comentários. A compensação também não influencia a pontuação de determinadas empresas de hospedagem.
Esta compensação cobre os custos de royalties aos revisores, da compra de contas e dos testes.
