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, volta 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 troca de contexto. Ele conecta os serviços da Hostinger às ferramentas de codificação com 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 questão mais importante: Você pode confiar em um assistente de IA para realizar 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.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Visite Hostinger

Prós e Contras do Hostinger Connector

Detalhamento da Avaliação

Aqui está como eu pontuei o Hostinger Connector nas áreas que mais importam para um desenvolvedor que está decidindo se deve usá-lo: custo, variedade de recursos, usabilidade no dia a dia, quão precisamente ele executa tarefas reais e o suporte por trás dele quando algo dá errado. Cada nota reflete o que eu realmente encontrei durante os testes, não a página de marketing.

Planos e Preços do Hostinger Connector

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á uma cobrança mensal separada do Connector para adicionar à sua conta 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, e-mail ou outro serviço da Hostinger para que ele execute as tarefas desejadas.

No momento desta análise, a página do Connector destacava Business Web Hosting e Cloud Startup.

Os preços foram exibidos antes dos impostos aplicáveis. Os preços promocionais e as taxas de renovação podem mudar, então verifique o total atual do checkout em vez de julgar o plano apenas pelo valor mensal anunciado.

Insight de preço: Não compre um plano superior 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ê deseja. O Connector é uma camada de gerenciamento incluída, não o principal produto precificado.

A Hostinger anuncia uma garantia de reembolso de 30 dias para compras elegíveis de hospedagem. Não há uma política de reembolso separada do Connector para avaliar porque o Connector não tem uma taxa independente.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Visite Hostinger

Recursos

• Implantação de aplicações Node.js
• Implantação de PHP e HTML
• Gerenciamento de websites WordPress
• Fluxos de trabalho do Website Builder e Horizons
• Implantações conectadas ao GitHub
• Conexão e organização de domínios
• Inspeção e atualização de DNS
• SSL e diagnósticos de websites
• Gerenciamento de bancos de dados
• Configuração e administração de VPS
• Implantação de projetos Docker
• Monitoramento de CPU e memória
• Verificação de largura de banda e disco
• Reinicializações de serviços e containers
• Verificação de malware
• Restauração de backups
• Configuração de campanhas de e-mail
• Inspeção de implantação e build

As ações exatas disponíveis dependem dos serviços Hostinger presentes na sua conta e das ferramentas expostas ao cliente de IA conectado.

A Hostinger também documenta limites de taxa. De acordo com a 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 da resposta.

Esses limites são generosos para uso interativo, embora fluxos de trabalho automatizados ou altamente repetitivos ainda devam evitar chamadas duplicadas desnecessárias.

Facilidade de Uso

1. Instalação e Autenticação

Antes de poder avaliar se o Hostinger Connector implanta e gerencia hospedagem bem, eu precisava saber o que é necessário para fazê-lo funcionar em primeiro lugar.

Uma ferramenta construída em torno de permanecer dentro do editor perde rapidamente o apelo se a configuração exigir editar arquivos de configuração, gerar tokens de API ou reautenticação repetida. Esta seção cobre apenas a configuração. O teste prático das tarefas vem logo depois.

Instalando a Extensão

Instalei o Hostinger Connector pela VS Code Marketplace. Ele apareceu como o primeiro resultado quando busquei por “Hostinger”, o publisher era listado como Hostinger Official, e a instalação ocorreu na primeira tentativa em menos de dois minutos.

Essa última linha merece uma ressalva. Cinco estrelas parece forte, mas uma amostra de duas avaliações não me diz quase nada sobre a experiência típica do usuário. Eu não me basearia nesse número no texto da análise.

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 própria extensão não tem nada com que falar 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 atrasou meu trabalho, mas os leitores devem saber que o Connector é útil apenas na medida em que houver um agente de IA por trás dele.

Sem um instalado e autenticado, não há nada para ele conectar.

O que a instalação não exigiu:

• Uma chave de API
• Um token copiado do hPanel
• Edição manual de um arquivo de configuração MCP
• Credenciais armazenadas localmente
• Um comando de servidor personalizado

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 na frente: 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 igualmente simples.

Conectando a Conta

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 na Hostinger e pediu que eu aprovasse o acesso para algo rotulado hostinger-mcp.

Depois que cliquei em Allow, voltei ao VS Code vendo “Connected via OAuth”.

A tela de autorização me informou que o Connector poderia gerenciar websites, hospedagem, domínios, assinaturas e outros serviços da Hostinger.

Isso é uma lista de categorias, não uma descrição de permissões item por item. 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 listando cada categoria de ferramenta e permitindo que eu habilitasse ou desabilitasse cada uma individualmente:

Isso totaliza 199 ferramentas, com 125 habilitadas por padrão. Eu deixei 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 dar 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 a senha da Hostinger ou caçar um token armazenado.

A autorização foi rápida e não exigiu que eu gerenciasse um token por conta própria, mas a tela de permissões é ampla em vez de granular. Os controles de ferramentas por categoria dentro da extensão fazem mais para limitar o risco real do que a tela OAuth.

Editores Compatíveis

A Hostinger lista suporte para os seguintes clientes, reunidos a partir da própria tela de onboarding da extensão:

Usei o VS Code com GitHub Copilot como meu ambiente principal de teste.

A configuração me disse que o Connector é fácil de alcançar. Ainda não me disse se ele realmente faz o trabalho bem depois de conectado, que é a questão mais difícil que eu enfrentei em seguida.

2. O Hostinger Connector em Ação

Instalar e conectar uma extensão é a parte fácil. O que realmente importa é se ela faz o trabalho real de hospedagem corretamente, então construí um pequeno aplicativo Express.js chamado PulseWatch e submeti o Connector ao mesmo caminho que um desenvolvedor seguiria após instalá-lo: inspecionar a conta, encontrar um alvo de implantação, implantar o projeto, atualizá-lo, inspecionar os resultados e se recuperar de uma falha que eu introduzi de propósito.

O PulseWatch foi deliberadamente simples: um servidor Express, uma homepage, um script de start no 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 quando o aplicativo falha na inicialização. Um endpoint ao vivo me deu uma forma independente de verificar se o processo implantado estava realmente respondendo, em vez de confiar em um selo de status.

Lendo Dados da Conta

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:

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

Minha conta na verdade tinha 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 “um plano de hospedagem ativo”. O hPanel mostrava três: Premium, Growth e Business.

Para ser justo com o Connector, quando eu contestei e apontei a discrepância, ele se corrigiu, separou claramente o que havia verificado do que havia assumido e não repetiu a afirmação errada.

Esse é um modo de falha melhor do que insistir no erro, mas significa que a primeira resposta para uma pergunta sobre a conta não deve ser aceita sem crítica.

Acesso somente de leitura funcionou, mas a primeira resposta a qualquer pergunta sobre a conta foi 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 uma prévia de um problema maior. O verdadeiro teste para saber se isso importava veio em seguida, quando pedi ao Connector para encontrar um website que ele nunca havia recebido pelo nome.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Visite Hostinger

Encontrando um Alvo de Implantação

Foi aqui que os testes revelaram mais. Pedi ao assistente para identificar um site Node.js recém-criado sem eu nomear o domínio, e sem tocar em nenhum site existente.

Selecionar o alvo é 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.

Foi o que aconteceu, na ordem:

O problema principal: os dois IDs que ele usou eram IDs de recursos de domínio, não IDs de pedido de hospedagem. Ele nunca confirmou essa distinção antes de chamar uma ferramenta viva de criação de website com eles.

Quando pedi que explicasse, o assistente acabou fornecendo um relato preciso: ele tinha uma ferramenta funcional de listagem de websites disponível o tempo todo, mas não a chamou novamente depois que criei um novo site por meio do hPanel, então preencheu a lacuna com um domínio não verificado em vez de atualizar seus dados.

Quando pedi diretamente para executar novamente essa ferramenta de listagem e verificar se havia um novo registro, ele chamou três ferramentas de busca de implantação não relacionadas e relatou “nenhum novo website apareceu”, uma conclusão que as chamadas de ferramenta que ele realmente fez não poderiam ter sustentado.

Nada disso criou um website indevido na minha conta. As chamadas falhas não deixaram nada para trás. Mas vale nomear claramente o padrão. 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 alvo 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 alvo sozinho, restou-me uma opção: construir o alvo eu mesmo e ver se isso mudava alguma coisa.

Concluindo a Configuração no hPanel

Já que o Connector não conseguiu localizar de forma confiável o novo alvo por conta própria, finalizei a configuração inicial manualmente pelo hPanel para ver o que a Hostinger prepara antes que a implantação baseada no 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 uma latência estimada de 147ms → uma escolha de três métodos de implantação.

Essa 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 pelo GitHub e upload manual de arquivos. Selecionei isso esperando que ele 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 o 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 detecção automática precisa:

• Preset de framework: Express
• Versão do Node: 22.x
• Diretório raiz: ./

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 anteriormente. Abri manualmente tanto a homepage quanto /api/health e confirmei que ambos funcionavam.

O caminho manual funcionou sem fricção assim que parei de esperar que o Connector o encontrasse. O botão “Build with Hostinger Connector” nesta tela deveria ser corrigido ou removido. Neste 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 maneira diferente agora que tinha algo sólido para encontrar.

Implantando e Atualizando o Aplicativo ao Vivo

Com um website real e confirmado em funcionamento, voltei ao Connector e pedi que ele inspecionasse exatamente aquele domínio. Desta vez funcionou de forma limpa.

Isso confirmou algo importante: as falhas anteriores eram sobre localizar e criar um novo alvo, 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 destaque: fazer uma alteração de código localmente e publicá-la sem abrir o hPanel.

Pedi ao assistente que alterasse uma linha do texto da homepage, de “Monitor Every Service. Catch Every Issue.” para “Monitor Every Service. Resolve Issues Faster.”

Todo o update levou cerca de um minuto. O assistente relatou a nova implantação como “pending” imediatamente após o envio, simplesmente porque verificou antes que a Hostinger terminasse de processar.

Quando atualizei o site ao vivo manualmente, o novo título já estava lá.

Os logs de build que ele recuperou depois foram específicos e úteis: 67 packages adicionados, 68 auditados, zero vulnerabilidades encontradas, sem erros.

Para sites já estabelecidos, este é quase o 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 resultado mais forte de todo o teste.

Uma implantação limpa só me diz que o caminho feliz funciona. Para descobrir o que o Connector realmente faz sob pressão, quebrei o aplicativo de propósito.

Testando a Recuperação de Falhas

Uma ferramenta só conquista confiança quando sobrevive ao contato com uma falha real, e 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 diagnosticar o problema.

Antes de fazer qualquer alteração, o assistente fez backup de package.json para package.json.bak, um bom hábito por si só.

Então pedi que ele alterasse o script de inicialização 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.

Os logs de build disponíveis pelo Connector mostravam a instalação bem-sucedida das dependências e nada mais. O erro de tempo de execução de módulo ausente nunca apareceu neles. Um desenvolvedor olhando 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 do backup, verificou o app localmente, reimplantou e confirmou a correção chamando o endpoint /api/health ao vivo diretamente, 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 descoberta principal. Um status concluído não é prova de um aplicativo funcionando, e os próprios logs do Connector não vão lhe dizer isso. 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 onde mais a confiança do Connector poderia ultrapassar sua capacidade real. Variáveis de ambiente foram o próximo teste.

Tentando Configurar Variáveis de Ambiente

Pedi ao assistente que adicionasse uma variável de ambiente inofensiva, confirmasse se a configuração existia como uma capacidade dedicada do Connector antes de tocar em qualquer coisa e parasse se não existisse.

Ele pesquisou as 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 mudança no código ou na implantação.

Este é o comportamento que eu queria ver em todo o resto deste teste. Diante de 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 nenhum lugar do conjunto de ferramentas, apenas que nenhuma ação desse tipo foi exposta durante este teste. 

Resumo do Teste de Falha e Recuperação

O que o Teste nos Diz Sobre a Confiabilidade

O Hostinger Connector executou bem tarefas rotineiras e determinísticas:

• Ler registros de implantação conhecidos
• Editar um arquivo específico
• Executar comandos locais
• Empacotar um projeto
• Implantar em um website conhecido
• Verificar o status do build
• Recuperar logs disponíveis
• Restaurar e reimplantar uma versão conhecida como boa

Ele foi mais fraco quando a tarefa exigia interpretação em meio a dados incompletos da conta:

• Identificar um website recém-criado
• Distinguir acessibilidade de domínio da existência do website
• Determinar se um build concluído significava que o app estava saudável

Esse padrão é útil na hora de decidir quanta autonomia dar ao assistente.

Use prompts amplos para inspeção de baixo risco. Use prompts precisos e requisitos explícitos de confirmação para ações que mudam a infraestrutura ao vivo.

Por exemplo, em vez de:

use:

O segundo prompt restringe o espaço para suposições do assistente.

Veredito Geral sobre a Facilidade de Uso

Fazer o Hostinger Connector funcionar foi fácil, sem nenhuma das fricções usuais de configuração, e os controles granulares por categoria de ferramenta me deram poder real sobre o que a IA podia tocar.

Depois que um website real existia com um domínio conhecido, ele fez bem o trabalho: uma alteração de uma linha no texto foi do editor ao vivo em cerca de um minuto, com logs de build úteis para respaldar isso.

O problema apareceu antes no processo, não depois. Diante de um novo alvo que ele não conseguia 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 aplicativo na verdade estava fora do ar, sem que o erro de tempo de execução aparecesse em seus próprios logs. Nenhum dos dois problemas torna a ferramenta pouco confiável para sites já estabelecidos, mas ambos significam que novos alvos de implantação e o status pós-implantação precisam de uma segunda verificação antes que você confie neles.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Visite Hostinger

Nível de Suporte

A Hostinger estrutura seu suporte em chat ao vivo e autoatendimento em vez de chamadas telefônicas, então foquei meus testes onde a maioria dos usuários realmente irá cair: o assistente de IA embutido no hPanel, a escalada humana por trás dele e a central de conhecimento à qual um desenvolvedor recorrerá antes de abrir um chat.

Canais de Suporte

Como o chat ao vivo é o canal que a Hostinger aponta para desenvolvedores em qualquer coisa urgente, e o que mais provavelmente será usado enquanto se depura uma implantação, testei esse caminho diretamente em vez de abrir um ticket por e-mail.

Chat ao Vivo: Kodee e a Transferência para Humano

Abri o chat ao vivo por meio de “Ask AI” no hPanel e fiz ao Kodee uma pergunta com uma resposta real para 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 do 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 depois do lançamento. Para detectar um comando de start incorreto ou outro crash em tempo de execução, verifique os logs de runtime: no hPanel vá para Websites → Dashboard → Deployments para os build logs, e então abra o stderr.log do seu app na pasta nodejs para erros de inicialização como Port already in use ou Module not found.

Essa única resposta teria resolvido exatamente a ambiguidade com a qual meu teste de recuperação de falhas esbarrou anteriormente nesta análise. O Kodee nomeou um arquivo de log real, a pasta correta e traçou a linha certa entre sucesso do build e saúde em tempo de execução.

No entanto, eu também queria ver se conseguiria acesso a um agente humano de verdade, então disse ao Kodee que queria confirmar isso diretamente com um engenheiro de suporte.

Mas conseguir uma pessoa na linha foi mais difícil do que eu esperava. Pedi diretamente por um agente ao vivo e fui redirecionado de volta ao 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 comando de start e os logs de runtime aqui mesmo, o que geralmente é a maneira mais rápida de identificar o problema.

Antes de colocar um especialista na fila. Posso resolver o problema e poupar sua espera.

Foram necessários dois pedidos diretos e explícitos antes que o 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 indisponibilidade que quer uma pessoa, é um ponto real de frustração.

O que aconteceu em seguida não foi uma transferência ao vivo no sentido que “me conecte com um humano” normalmente sugere. O Kodee explicou o modelo real de forma clara:

Compartilhei sua solicitação com um especialista da nossa equipe que revisará pessoalmente nosso chat e enviará a resposta dele, que então eu transmitirei para você aqui.

Isso é uma análise assíncrona, não uma transferência ao vivo. O Kodee continua sendo a interface; um humano revisa a transcrição em segundo plano e o Kodee retransmite a resposta quando ela chega. Essa distinção importa para leitores decidindo se devem escalar, já que “agente humano” aqui não significa que uma nova pessoa entre na janela de chat como aconteceria em sistemas de chat ao vivo mais comuns.

Continuei a mesma linha técnica enquanto esperava, pedindo ao Kodee que confirmasse o caminho exato do log e se o stderr.log está sempre preenchido. Ele deu uma boa resposta por conta própria, observando corretamente que o log pode estar vazio se o app nunca tiver iniciado totalmente ou tiver 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 do 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 nele quando o app escrever em stderr, como em exceções não capturadas ou rejeições não tratadas. Se o comando de start estiver errado e o processo sair silenciosamente, o stderr.log pode estar vazio ou ausente.

Mayas também acrescentou duas verificações alternativas que o 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 começou.

Knowledge Base

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 maneira de encontrar o artigo correto foi pesquisar “Hostinger Connector” diretamente, o que retornou cinco resultados, a maioria apenas vagamente relacionada, incluindo um guia de plugin de marketing de afiliados e um artigo geral de hospedagem Node.js.

O artigo que realmente documenta a configuração do Connector é intitulado “How to Set Up Web Hosting MCP on Local IDEs”, arquivado em Features → General Information.

Pesquisar o nome de marketing real do produto o encontrou, mas um leitor navegando por categorias ou pesquisando “MCP” sem conhecer a marca da Hostinger poderia facilmente deixar de encontrá-lo, e o descompasso entre o nome divulgado e o nome documentado vale a pena ser conhecido antes de procurar.

O artigo em si é forte depois de encontrado. Ele foi atualizado pela última vez seis dias antes de eu testá-lo, e cobre:

• A configuração recomendada com OAuth de um clique por meio da extensão
• Um caminho de configuração manual usando um token de API, para IDEs que a extensão não suporta diretamente
• Os caminhos exatos dos arquivos de configuração para Mac, Linux e Windows
• Exemplos completos de configuração em JSON
• Um prompt de verificação passo a passo para confirmar que a conexão funcionou
• Quais clientes compatíveis detectam automaticamente a conexão e quais exigem entrada manual na configuração

Esse último ponto correspondia a algo que encontrei diretamente durante o teste: Devin Desktop é detectado automaticamente, enquanto o OpenAI Codex exige o método manual. O artigo acerta essa distinção.

Veredito Geral sobre o Suporte

A primeira resposta do Kodee para uma questão técnica difícil foi precisa e específica, o que não é algo que todo assistente de suporte com IA consegue. O artigo da base de conhecimento que o sustenta é atual e detalhado quando 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 por categorias.

O ponto mais fraco é o caminho de escalada humana. O 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 retransmitida pelo mesmo chat, não uma transferência ao vivo. Depois que um humano realmente analisou, a resposta foi melhor que a do Kodee, mais precisa e com duas etapas diagnósticas extras que o Kodee não havia oferecido.

Para a maioria das perguntas, o Kodee sozinho vai lhe dar uma resposta precisa rapidamente. Se você realmente quiser que uma pessoa verifique a resposta, espere ter que pedir mais de uma vez e espere uma breve espera por uma resposta retransmitida, em vez de uma conversa ao vivo.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Visite Hostinger

Veredito Final: Vale a Pena Usar o Hostinger Connector?

Sim, para desenvolvedores que já hospedam com a Hostinger e querem implantações rotineiras feitas diretamente do editor. A configuração levou minutos, o OAuth eliminou qualquer necessidade de chaves de API, e, uma vez 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 confirmar. As respostas do próprio Kodee no suporte foram suficientemente afiadas 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 alvo que ele não conseguia 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 estava, na verdade, fora do ar, sem erro de tempo de execução em seus próprios logs. Use-o para acelerar o trabalho em sites que já existem, verifique tudo o que ele fizer em um novo alvo e confira o site ao vivo você mesmo após qualquer implantação que importe.

Hostinger

5.0

2,471 user reviews

R$ 9 /mo

Preço inicial

Visite Hostinger

Rating based on expert review

• Fácil de usar
  4.9
• Suporte
  4.9
• Recursos
  4.8
• Confiabilidade
  4.7
• Preço
  4.5