A Hostinger construiu Web Apps Hosting em torno de uma proposta simples: enviar seu código do GitHub, de um arquivo ZIP ou do seu agente de codificação de IA e obter um app ao vivo, pronto para produção, em cerca de um minuto, sem precisar gerenciar um servidor. Eu queria saber quanto disso realmente se sustenta quando é você quem clica em implantar, então aqui está o que encontrei.

Deploy Web Apps Faster with Hostinger

Implante web apps modernas na Hostinger com builds automatizados, infraestrutura gerenciada, CDN global, SSL, ferramentas de segurança e garantia de reembolso de 30 dias.

Visite Hostinger

Prós e Contras

Distribuição da Avaliação

Para pontuar a Web Apps Hosting da Hostinger, apliquei a metodologia de avaliação da HostAdvice, a mesma abordagem padronizada usada em todas as avaliações do site, para que as notas permaneçam baseadas em testes reais em vez de linguagem de marketing. Veja como ela se saiu em cada parâmetro.

Host Your Web Apps Without the DevOps Hassle

Implante aplicativos web modernos em hospedagem totalmente gerenciada com implantações automatizadas, SSL gerenciado, CDN global e segurança integrada.

Visite Hostinger

Planos e Preços

A Hostinger vende a Web Apps Hosting em dois níveis, Business e Cloud Startup, ambos criados especificamente para implantar apps Node.js e JavaScript modernos, em vez de um construtor de sites tradicional.

Cloud Startup, o plano que testei, dobra a quantidade de apps permitidos e os núcleos de CPU em relação ao Business, e ambos os planos incluem um domínio grátis, e-mail empresarial grátis e SSL gerenciado durante o primeiro ano, tudo diretamente no checkout.

Algumas coisas para saber antes de fazer o pedido:

• Garantia de reembolso: a Web Apps Hosting se enquadra nas condições padrão de reembolso da Hostinger, uma janela simples de 30 dias a partir da data da compra. Isso é muito mais simples do que o que se aplica aos planos VPS da Hostinger, que têm um cooldown adicional de 180 dias entre pedidos de reembolso. Nenhum cooldown desse tipo se aplica aqui.
• Teste grátis: não encontrei um teste grátis dedicado. A garantia de reembolso de 30 dias é sua janela de avaliação.
• Métodos de pagamento: o checkout exibiu pagamento por cartão como método padrão, com logos de Visa, Mastercard, Amex e Discover, além de uma opção para adicionar outro método de pagamento durante o checkout.
• O que vem incluso: um domínio grátis por um ano, caixas de correio grátis por um ano e SSL gerenciado estão todos incluídos sem custo adicional além do preço do plano, então o preço de tabela está bem próximo do custo real para colocar uma implantação totalmente funcional e segura no ar.
• O único upsell: Hostinger Reach, um complemento de marketing por e-mail, aparece no carrinho como sua própria caixa destacada com um preço mensal separado. É fácil ignorá-lo e ele não vem incluído nem pré-selecionado por padrão.

Se você cancelar um plano de Web Apps Hosting dentro de 30 dias, a política de reembolso da Hostinger confirma que ele se enquadra nos termos padrão, e não na lista de exclusões, então um cancelamento simples dentro dessa janela deve dar direito a reembolso sem as condições extras aplicadas a VPS ou compras de domínio.

Recursos

• Detecção automática de framework e versão do Node
• Ferramentas gerenciadas de criação de banco de dados MySQL
• CDN global ativada por padrão
• WAF e proteção DDoS incluídos
• Backups diários e sob demanda
• Scanner de malware e verificação de vulnerabilidades
• Integração com GitHub com auto-deploy
• Domínio, e-mail e SSL grátis
• Acesso SSH para usuários avançados

From Code to Live App with Hostinger

Conecte seu repositório GitHub ou envie seu projeto e coloque-o online com infraestrutura gerenciada, implantações automáticas e backups diários.

Visite Hostinger

Desempenho

Como a Web Apps Hosting é totalmente gerenciada, você nunca recebe acesso shell a um servidor, então não há CPU, RAM ou disco para benchmarkear diretamente, como faríamos em uma avaliação de VPS.

O que você pode medir é quão rápido o app implantado carrega e responde, a partir de locais reais em todo o mundo. Eu testei isso de quatro ângulos diferentes: GTmetrix a partir de dois continentes, uma verificação global com mais de 50 pontos e a própria ferramenta de velocidade integrada da Hostinger para desktop e mobile.

O app em teste é a implantação Next.js coberta na seção de Facilidade de uso abaixo, ativa em ivory-llama-856835.hostingersite.com, rodando no plano Cloud Startup (4 núcleos de CPU, 4096 MB RAM, 100 GB NVMe storage), com CDN ativada por padrão.

1. GTmetrix, testado a partir de dois continentes

Executei o GTmetrix duas vezes a partir de diferentes partes do mundo para ver se o resultado se mantinha consistente ou se parecia bom só de um ponto de vista sortudo.

As duas execuções alcançaram 100% perfeitos tanto em Performance quanto em Structure, com zero deslocamento de layout e zero tempo de bloqueio em ambas as localidades, o que significa que nada na página competiu pela atenção do navegador ou pulou de lugar enquanto carregava.

O detalhe realmente interessante é que Frankfurt superou Chicago em todas as métricas de tempo, mesmo eu tendo escolhido deliberadamente uma localização de servidor nos EUA para este app. Esse resultado só faz sentido à luz da CDN.

Quando uma CDN está ativa, como estava aqui por padrão, o visitante não está necessariamente acessando o servidor de origem diretamente.

Ele está acessando o nó de borda em cache mais próximo, então um ponto de teste europeu pode acabar sendo mais rápido do que um dos EUA, mesmo quando o servidor real fica nos EUA. Essa é uma confirmação real e prática de que a CDN ativada por padrão da Hostinger está fazendo o trabalho dela, em vez de ficar lá como uma checkbox inútil de marketing.

2. Consistência Global (Check-Host)

Executei uma verificação HTTP no URL ao vivo a partir de todos os checkpoints oferecidos pelo Check-Host, 54 locais distribuídos por seis continentes. O panorama completo:

Todas as verificações bem-sucedidas retornaram um 200 OK limpo, sem erros, sem falhas parciais, sem redirecionamentos inesperados.

Os tempos de resposta contaram uma história clara sobre como o cache da CDN se comporta em distâncias do mundo real:

Os checkpoints europeus consistentemente retornaram os tempos mais rápidos, vários abaixo de 50 milissegundos, enquanto os checkpoints fisicamente mais distantes de qualquer nó de borda, Tokyo, Singapore, Ho Chi Minh City, ainda retornaram respostas 200 válidas, só que mais lentas, na faixa de 0.3 a 0.8 segundo.

Esse é o formato esperado para uma implantação apoiada por CDN: rápida perto das bordas, mas ainda totalmente funcional longe delas.

Os quatro timeouts, Kazakhstan, Romania e dois dos quatro checkpoints russos, não são algo que eu interpretaria como um problema na infraestrutura da Hostinger.

Outros checkpoints nos mesmos países tiveram sucesso (Saint Petersburg voltou limpo em 0.063s enquanto dois checkpoints de Moscow expiraram), o que aponta para filtragem regional de rede no lado do checkpoint, e não para algo errado com o app implantado.

3. A própria ferramenta de velocidade da Hostinger, desktop e mobile

A Hostinger executa seu próprio teste Page Speed diretamente no painel do app, então comparei os números com os resultados independentes do GTmetrix em vez de aceitar qualquer um deles isoladamente.

Ambos os tipos de dispositivo obtiveram pontuação perfeita de 100, e os números de desktop se alinham de perto com o que o GTmetrix mediu de forma independente, que é o verdadeiro ponto de rodar ambos. Duas ferramentas diferentes, duas metodologias diferentes, e elas concordam entre si.

O mobile foi mais lento em todas as métricas de tempo, como esperado em uma conexão simulada mais lenta e em um processador mais fraco, mas ainda rápido o suficiente para que uma pontuação 100 reflita um desempenho mobile realmente forte no mundo real, não apenas uma escala de avaliação indulgente.

Uma inconsistência na própria ferramenta. Embora a pontuação seja um 100 limpo em ambos os dispositivos, o painel Diagnostics abaixo ainda sinaliza alguns itens com pontuação literal 0, network dependency tree, document request latency e avoiding multiple redirects, além de dois itens com pontuação 50, unused JavaScript e legacy JavaScript.

Nenhuma dessas pontuações baixas em subitens derrubou a nota principal, então trate-as como oportunidades de otimização realmente presentes e pequenas, e não como algo errado com a implantação.

Além disso, os “helpful links” que a Hostinger mostra ao lado desses diagnósticos são todos escritos para WordPress, “Speed up WordPress in 9 easy steps”, “How to optimize images for your WordPress site”, apesar de este ser um app Node.js sem WordPress em qualquer parte da stack. Isso é um resquício de um modelo de diagnóstico compartilhado, e não conteúdo feito para este produto.

Veredito geral sobre Desempenho

Managed Web App Hosting by Hostinger

Concentre-se em construir seu app enquanto a Hostinger cuida da implantação, infraestrutura, segurança, SSL, backups e entrega global.

Visite Hostinger

Facilidade de Uso

Testei a Web Apps Hosting da Hostinger desde a landing page até o checkout e, depois, de uma conta nova até uma implantação Node.js totalmente ao vivo e funcionando.

Isso incluiu escolher um plano, pagar, decidir como construir, conectar o GitHub e assistir ao build ser concluído em tempo real. Veja como foi esse processo na prática.

1. Registro

Comecei na landing page de Web Apps Hosting, que traz uma única chamada para ação: Start deploying.

Clicar nele não abre um formulário de cadastro. Ele rola direto para a seção de preços, então a primeira decisão real que você toma é qual plano comprar, não quais dados da conta preencher.

Dois planos apareciam lado a lado:

Escolhi Cloud Startup pelo dobro da quantidade de apps permitidos e da margem de CPU em relação ao plano inicial. Uma pequena inconsistência a apontar aqui: a página de preços chama-o de “Cloud Startup”, mas, quando ele entra no carrinho, o mesmo plano é rotulado como “Startup plan”. Não é um problema funcional, apenas uma divergência de nome entre duas telas no mesmo fluxo de checkout.

O carrinho em si estava limpo. Ele listava o prazo de 48 meses, a economia, um domínio grátis por um ano e caixas de e-mail grátis, e então oferecia um upsell, o Hostinger Reach email marketing, em sua própria caixa destacada, em vez de pré-selecionado.

Pulei-o e cliquei em Continue sem atrito.

Se você for um novo cliente em vez de um cliente existente, o checkout insere uma etapa de criação de conta aqui antes de você chegar à página de endereço de cobrança e pagamento.

Em seguida, você adiciona um endereço de cobrança, escolhe um método de pagamento, cartão, PayPal ou uma das outras opções, e envia. Recebi um e-mail de confirmação de compra poucos momentos depois de clicar em Submit payment e, em seguida, fui direto para o hPanel com o plano já provisionado.

O que achei: o checkout é curto e o upsell é fácil de recusar sem precisar procurar um link escondido para pular. A divergência no nome do plano entre a página de preços e o carrinho é algo pequeno, mas é o tipo de detalhe que faz um comprador de primeira viagem parar e conferir duas vezes se escolheu o nível certo.

2. Painel

Assim que o pagamento é aprovado, você entra no hPanel, o painel próprio da Hostinger, criado internamente para gerenciar todos os produtos que ela vende, não uma página construída especificamente para o seu novo Web App.

A página em que você aterrissa primeiro é a Home, e ela é estruturada em torno de uma barra de prompt de IA no topo: “Hi, [your name]! How can I help you today?” com um campo de texto abaixo e seis botões de atalho: Get domain, Create website, Get email, Migrate site, Get VPS e Try email marketing.

Rolando para baixo, você encontrará:

• Tiles de promoção de recursos para o AI Builder, a ferramenta de loja online, oferecendo um e-mail comercial grátis, agentes de IA, um aplicativo de automação e reivindicando um domínio grátis
• Uma lista de tarefas empurrando você para etapas de configuração, concluir a configuração do Reach, reivindicar seu e-mail grátis, reivindicar seu domínio grátis
• Your business, uma lista contínua de todos os sites, apps e instâncias VPS vinculados à sua conta, cada um com seu próprio botão Manage site
• VPS, uma tabela separada mais abaixo listando quaisquer instâncias VPS por endereço IP, status e data de expiração

Um painel Agent também fica permanentemente no canto superior direito de todas as páginas do hPanel, não apenas na Home. É o mesmo assistente Kodee usado para suporte, mas posicionado aqui como uma ferramenta de ação geral com prompts prontos como “Deploy my Node.js app” ou “Harden VPS updates”, que você pode acionar sem precisar digitar uma pergunta completa.

A Home é realmente útil depois que seu app já existe, tudo em Your business leva diretamente até ele. Mas não é nela que você vai criar um novo Web App ou encontrar o botão Setup. Para isso, você precisa seguir outro caminho pela barra lateral:

1. Clique em Websites na barra lateral esquerda
2. Um submenu se expande abaixo dele: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Clique em Web Apps

Esse clique leva você a uma tela completamente diferente da Home, organizada em torno dos seus planos de hospedagem reais, e não de uma barra de prompt.

Aqui, cada plano que você possui ganha seu próprio cartão. Na minha conta, isso significava três cartões empilhados verticalmente:

O cartão Business também já tinha um app ativo listado abaixo dele de um teste anterior, orange-walrus-700988.hostingersite.com, com seus próprios botões Tools e Dashboard.

Isso por si só já é algo útil de notar. Depois que um Web App existe, o cartão dele ganha uma linha como esta mostrando o site ao vivo diretamente, que é exatamente como o cartão do seu Cloud Startup ficará depois que você concluir a configuração.

Como o Cloud Startup era o plano que eu havia acabado de comprar e ainda não tinha configurado, o cartão dele mostrava apenas um botão Setup. Esse é o botão que realmente inicia o assistente de criação do Web App, e ele só aparece aqui, em Websites → Web Apps, não na tela Home em que você aterrissa por padrão.

O que achei: o hPanel é claro depois que você encontra a tela certa, mas a Web Apps Hosting não tem uma porta de entrada óbvia. Cair na Home leva você a uma barra de prompt e atalhos, não a um caminho para criar um app; você precisa saber que deve clicar em Websites e depois em Web Apps antes que o Setup apareça. São alguns cliques a mais para um produto vendido como “ao vivo em um minuto”. Ainda assim, uma vez lá, os cartões de plano são limpos e honestos sobre o status, e um plano com um app já em execução mostra isso diretamente no cartão.

3. Implantando o app

Clicar em Setup no cartão do plano abriu um fluxo curto de onboarding: Where would you like to start? com três opções, Create a new site, Migrate an existing site, ou I hired someone to build my site. Escolhi Create a new site.

Isso levou a How do you want to build your website?, dividido em duas opções voltadas para iniciantes no topo, Hostinger AI Builder e WordPress + AI, e duas opções sob um título separado de “for advanced users” abaixo: Node.js web app e PHP/HTML website. Selecionar Node.js web app é o que realmente leva você ao próprio produto Web Apps Hosting.

Esse é um detalhe estrutural real para qualquer pessoa comparando produtos: a Web Apps Hosting não tem seu próprio fluxo de cadastro dedicado.

Ela é apenas um ramo dentro do mesmo assistente geral de criação de site usado para AI Builder e WordPress.

Cliquei no círculo ao lado de Node.js web app e depois em Next.

A partir daí:

• Tela de domínio: escolhi Use temporary domain em vez de comprometer um domínio real, já que esta era uma implantação de teste.

• Tela de localização do servidor: a Hostinger pré-selecionou France, a região mais próxima do meu país de cobrança, e exibiu 167ms de latência. Ao rolar até a opção United States, ela mostrava 364ms, mais que o dobro.

Mesmo assim, escolhi United States, Massachusetts, e essa é exatamente a lição que o seletor de localização ensina em todos os produtos da Hostinger: escolha com base em onde seus visitantes reais estão, não no número mais baixo da lista.

O público pretendido para o meu app de teste é baseado nos EUA, então um servidor nos EUA realmente atenderá essas pessoas mais rápido do que um servidor na France jamais atenderia, independentemente do que o seletor me mostrou a partir da minha própria localização. O número na tela informa o quão rápido o servidor responde ao teste da Hostinger, não quão rápido ele responderá às pessoas que realmente usarão seu site.

• Tela de método de implantação: duas opções principais, Import Git repository (marcada como Recommended) ou Upload your files, além de um destaque abaixo para implantar diretamente do Claude Code, Cursor ou VS Code por meio do Hostinger Connector. Escolhi Import Git repository e cliquei em Connect with GitHub.

Isso abriu uma janela real de login do GitHub se você ainda não estivesse conectado, depois uma tela de permissões intitulada Install & Authorize Hostinger, pedindo que você escolhesse entre:

• Instalar em todos os repositórios que você possui, inclusive os futuros, com acesso somente leitura a repositórios públicos
• Instalar em apenas repositórios selecionados que você escolher individualmente e listando as permissões exatas concedidas: acesso de leitura a actions, metadata e repository hooks, e acesso de leitura e gravação a administration, code e pull requests. Depois que você clica em Install & Authorize, o GitHub redireciona você automaticamente de volta ao hPanel.

Você chega em Select Git repository to import, uma lista rolável de todos os repositórios vinculados à sua conta do GitHub, cada um com seu próprio botão Deploy ao lado. Encontrei o repositório de teste que havia enviado anteriormente, hostadvice-webapps-test, e cliquei em Deploy ao lado dele.

Desde o clique nesse botão, levou quase 30 segundos, sem indicador de progresso na tela, até que a próxima página carregasse, tempo suficiente para você pensar que o clique talvez não tivesse sido registrado.

A página que finalmente carrega tem o título Review build settings, e ela informa exatamente onde seu app vai ficar antes de você confirmar qualquer coisa: “Deploys to ivory-llama-856835.hostingersite.com.” Abaixo disso, sem você tocar em nenhum campo, ele já havia detectado automaticamente:

Cada uma dessas cinco linhas tem seu próprio botão Change ou Add ao lado, então nada aqui fica travado se a detecção errar alguma coisa.

Cliquei em Add ao lado de Environment variables e defini um par chave-valor para confirmar que ele realmente chegaria ao app em execução depois, então cliquei em Finish naquele diálogo e, em seguida, cliquei no botão principal Deploy na parte inferior da página.

Acompanhando o build

A tela muda para uma visualização Deploying… com uma barra de progresso rotulada, “Deployment from GitHub”, avançando em etapas reais; observei ela passar por 28%, depois 51%, a caminho da conclusão. Abaixo da barra de progresso há um painel recolhível Build logs, e expandi-lo mostra saída de terminal real em tempo real, não um spinner de placeholder:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

Implantação concluída

Quando o build termina, você chega a uma tela Deployment completed! com uma prévia em miniatura ao vivo do seu app real renderizada ali mesmo no cartão, ao lado de um resumo mostrando o nome do repositório e a URL ao vivo atribuída.

Dessa página, você pode clicar direto em Go to dashboard, que é onde você gerencia o app daqui para frente.

O que achei: a detecção automática é o grande destaque aqui. Framework, branch e versão do Node vieram corretos sem um único campo manual, e o log de build ao vivo faz a espera parecer transparente em vez de opaca. O único ponto fraco é a pausa de 30 segundos antes mesmo de você chegar à tela de configurações, tempo suficiente para fazer você pensar que algo travou antes de o processo começar de fato a aparecer.

4. Confirmando a Implantação ao Vivo

Antes de explorar qualquer ferramenta de gerenciamento, eu queria confirmar que o app realmente havia sido implantado e estava funcionando, e não apenas marcado como “Completed” na tela.

A partir da página Deployment completed, cliquei direto na URL ao vivo, ivory-llama-856835.hostingersite.com, em vez de confiar apenas na miniatura de pré-visualização do painel.

A página ao vivo carregou e mostrou exatamente o que o app foi programado para exibir:

• Server build time, um carimbo de data/hora ao vivo confirmando que a página foi recém-construída, e não servida de um cache antigo
• Environment variable check, mostrando a variável personalizada que defini durante a tela de implantação, confirmada corretamente no site ao vivo de verdade, e não apenas na pré-visualização do painel

Depois cliquei no botão Ping the API route do app, que chama um endpoint backend ao vivo e não apenas renderiza conteúdo estático. Ele retornou uma resposta JSON limpa:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

Essa resposta é mais importante do que parece. Uma página carregando corretamente só prova que os arquivos estáticos foram enviados.

Uma chamada de API funcionando prova que o servidor Node.js real está rodando por baixo e respondendo a requisições de verdade, a parte da hospedagem de “Node.js web app” que é fácil de falsificar com um arquivo estático e difícil de falsificar com um timestamp de servidor ao vivo gerado exatamente no momento em que você clica em um botão.

O que achei: essa é a verificação que eu recomendaria a você antes de confiar em qualquer implantação nessa plataforma, ou em qualquer outra similar. Um status verde “Completed” e uma miniatura de prévia dizem que o build terminou. Clicar na URL ao vivo e acionar algo dinâmico, uma chamada de API, uma leitura de banco de dados, qualquer coisa que não possa ser falsificada por uma página estática em cache, diz que o servidor realmente está vivo e fazendo o que você construiu ele para fazer.

5. Gerenciamento do Web App

Com o app ao vivo confirmado funcionando, voltei ao hPanel e explorei o painel de gerenciamento do próprio app de ponta a ponta, a camada real de gerenciamento do servidor deste produto, separada da tela geral Home do hPanel coberta acima.

Visão geral do dashboard. No momento em que você chega aqui, quatro badges de status mostram o estado de tudo de relance:

Todos os quatro vieram verdes por padrão, sem que eu precisasse ativar nada manualmente. Abaixo disso há um cartão Last deployment confirmando estado, repositório, autor, commit, horário de implantação, stack detectada e versão do Node, tudo o que você gostaria de verificar de relance sem vasculhar logs.

Um Page Speed test automático já havia sido executado no site ao vivo por conta própria e retornado uma pontuação de 99/100 no Desktop sem eu acioná-lo manualmente, ao lado de um painel Essentials com links rápidos para conexão de banco de dados, backups, file manager, logs de runtime e cache.

Deployments, environment variables e logs. Três páginas separadas cobrem esse terreno:

• Deployments manteve um registro completo do push, autor, branch, hash do commit e status de conclusão, um histórico real em vez de apenas o mais recente
• Environment variables listou corretamente a que eu havia definido durante a implantação, confirmando que ela foi armazenada e aplicada, e não apenas exibida uma vez durante a configuração e esquecida
• Runtime logs transmitiu a saída ao vivo do servidor conforme acontecia, linhas de inicialização do Next.js, timestamps de prontidão e uma contagem contínua de issues e errors, que permaneceu em zero e zero o tempo todo em que observei

Segurança. O Malware Scanner retornou um resultado limpo, “Your website is safe”, com uma ressalva declarada de forma clara e não escondida em letras miúdas: ele verifica apenas os arquivos do site, não o conteúdo do banco de dados, e existe uma opção paga de limpeza caso você queira uma verificação mais profunda que inclua o banco de dados. A verificação de Vulnerabilities também voltou limpa.

Bancos de dados. É aqui que o marketing do próprio produto cria uma lacuna real que você deve entender antes de comprar. O plano anuncia MySQL gerenciado como um recurso principal, mas nada é provisionado automaticamente para você.

A seção Databases abre em um formulário manual Create a New MySQL Database And Database User, o que significa que você nomeia e cria o banco de dados por conta própria antes que seu app possa usá-lo. Confirmei isso diretamente com o Kodee, abordado na seção de Suporte abaixo, e a resposta foi direta: gerenciado significa que a Hostinger executa a infraestrutura do banco de dados nos bastidores, não que um banco de dados seja criado para você no momento em que seu app entra no ar.

Acesso avançado. O acesso SSH existe em Advanced, completo com IP, porta e username, mas fica Inactive por padrão e precisa de um clique manual em Enable antes que você possa usá-lo. O File Manager oferece uma escolha entre navegar apenas pelos arquivos deste app ou por todos os arquivos de todo o plano de hospedagem.

O que achei: o dashboard do dia a dia é completo e bem organizado. Segurança e histórico de implantação, em particular, são fáceis de encontrar e realmente informativos, e o log de runtime sem erros, junto com um scanner de malware limpo, me deu confiança real de que o app estava saudável, e não apenas online.

O único lugar em que a interface exagera é a seção de banco de dados, onde “managed MySQL” soa na página do plano como algo que já vem pronto assim que seu app entra no ar, mas na prática significa um formulário de criação manual, simples de usar, mas uma etapa que você precisa fazer por conta própria.

Veredito geral sobre Facilidade de Uso

Build, Deploy, and Scale with Hostinger

Hospede web apps modernos com integração GitHub, MySQL gerenciado, CDN global, largura de banda ilimitada e ferramentas de segurança integradas.

Visite Hostinger

Nível de Suporte

Testei o suporte da Hostinger para Web Apps Hosting por meio do Kodee, o assistente de IA integrado ao hPanel, e depois passei pela base de conhecimento para ver o quanto ela cobre sem precisar perguntar a ninguém. O Kodee aparece em dois lugares que vale distinguir: como Ask AI no site público de marketing e como painel Agent disponível em qualquer página dentro do hPanel, inclusive diretamente no próprio dashboard do Web App.

1. Suporte por IA (Kodee)

Fiz duas perguntas baseadas em lacunas reais que encontrei durante os testes, e não em pesquisas genéricas que o Kodee poderia responder colando documentação.

Pergunta 1 testou comportamento de falha de implantação e o momento das variáveis de ambiente, ambos preocupações reais de produção para qualquer pessoa lançando algo nessa plataforma:

Se o build do meu app falhar no meio de uma implantação via GitHub, o app volta automaticamente para a última versão bem-sucedida ou fica fora do ar até eu corrigir e redeployar? E posso definir variáveis de ambiente personalizadas antes da primeira implantação ou só depois?

O Kodee respondeu de forma direta e correta nos dois pontos. Um build com falha não substitui um app já em execução; se uma implantação anterior foi bem-sucedida, o app continua servindo aquela última versão funcional. Se for a primeira implantação e não houver nada para servir de fallback, o app fica fora do ar até o build ser corrigido e redeployado, uma resposta clara e honesta, e não um aceno vago de tranquilização.

Sobre variáveis de ambiente, ele confirmou que você pode defini-las antes da primeira implantação nas configurações de deploy e, para um app já em execução, descreveu os três passos exatos: abrir Settings e Redeploy, adicionar ou editar variáveis em Environment variables, salvar e redeployar.

Pergunta 2 apertou os dois pontos que eu mesmo havia encontrado ao explorar o dashboard: a formulação de “managed MySQL” versus o formulário de criação manual e o SSH ficando inativo por padrão:

Este plano anuncia MySQL gerenciado, mas o dashboard mostra um formulário manual ‘Create a New MySQL Database’ em vez de um banco de dados provisionado automaticamente. Um banco de dados é criado para cada Web App por padrão ou apenas se eu criar um? Além disso, o acesso SSH é listado como disponível, mas aparece como Inactive por padrão. Se eu nunca o ativar, isso muda alguma coisa em como meu app realmente funciona, ou o SSH é apenas um extra opcional para usuários avançados?

A resposta do Kodee confirmou exatamente o que eu havia encontrado na interface, e não uma versão suavizada disso. Um banco de dados não é criado automaticamente para cada Web App; “managed” se refere à Hostinger executar o serviço e a infraestrutura do banco de dados, enquanto criar e configurar um banco de dados real fica por sua conta, por meio da mesma tela Create a New MySQL Database que eu já havia visto, seguida de adicionar seus detalhes de conexão às variáveis de ambiente do seu app por conta própria.

Sobre o SSH, ele confirmou que deixá-lo inativo não muda nada na forma como o app funciona, faz deploy ou se conecta a um banco de dados. Ele é posicionado puramente como uma ferramenta opcional para comandos CLI, migrações ou depuração direta de arquivos, e não como algo de que a plataforma dependa silenciosamente nos bastidores.

O que achei: ambas as respostas combinaram com o que eu já havia verificado manualmente no dashboard, em vez de contradizê-lo ou suavizá-lo, o que é sinal de uma ferramenta de suporte que realmente consulta o estado real do produto em vez de repetir um script. Nenhuma das perguntas poderia ser respondida colando algo de uma FAQ genérica, e o Kodee lidou com ambas com respostas específicas, estruturadas e em duas partes em cerca de um minuto cada.

2. Base de Conhecimento

A base de conhecimento da Hostinger abre em uma grade de categorias, 20 categorias no total, cada uma mostrando uma contagem de artigos. Algumas das maiores: AI Builder tem 330 artigos, VPS tem 276, Email tem 127 e Website tem 103.

A Web Apps Hosting não ganha sua própria categoria dedicada. Seu conteúdo fica espalhado entre Getting Started, hPanel e Website, o que é um achado real para quem esperava uma base central específica, como VPS ou Email recebem.

Pesquisar “Web Apps” diretamente retornou 71 resultados em 8 páginas. Os principais resultados eram uma mistura de conteúdo diretamente relevante e conteúdo apenas vagamente relacionado:

• How to deploy apps built with Codex on Hostinger, diretamente relevante
• Hostinger AI Builder: How to create a web app in agentic mode, adjacente, mas de um produto diferente
• How to add a Node.js Web App in Hostinger, diretamente relevante
• How to install Flutter Web on a VPS at Hostinger, um produto diferente
• Vários artigos de pagamento do Website Builder (PayPal, WeChat Pay, BLIK), sem relação além de compartilharem as palavras “web” e “app” em algum lugar do texto

Abri um dos principais resultados, How to deploy apps built with Codex on Hostinger, para verificar sua profundidade. Ele acabou sendo um guia bem estruturado e completo, com frameworks suportados listados logo no início, screenshots passo a passo para os caminhos de importação via GitHub e upload via ZIP, uma seção sobre configurar as build settings com comandos de exemplo, uma análise da estrutura de arquivos após a implantação, um passo a passo do assistente de conexão de banco de dados, uma seção sobre monitoramento de vulnerabilidades e um bloco final de FAQ.

Embora seja enquadrado especificamente em torno do Codex, a plataforma subjacente é a mesma por trás do produto geral Node.js Web App, então a maior parte dele se aplica diretamente.

O que achei: a contagem de artigos na pesquisa parece forte no papel, 71 resultados para um termo, mas uma parte significativa desse volume é ruído de produtos não relacionados que compartilham uma redação semelhante. O artigo que abri por completo se manteve muito bem em qualidade depois que entrei nele, passos claros, screenshots reais e uma seção genuína de FAQ, mas encontrá-lo exigiu rolar por resultados que não tinham nada a ver com o que eu estava tentando implantar.

Veredito geral sobre Atendimento ao Cliente

Simple Hosting for Modern Web Apps

Implante React, Next.js, Vue, Node.js e outros aplicativos modernos sem gerenciar servidores ou infraestrutura complexa.

Visite Hostinger

Recomendamos a Hostinger Web Apps Hosting?

Sim. O processo de implantação é a parte mais forte deste produto: detecção correta da stack, branch e versão do Node, um log de build real e contínuo em vez de um spinner, e um app ao vivo que passou em todos os testes de desempenho que eu lhe impus, pontuações perfeitas no GTmetrix de dois continentes diferentes, uma verificação global limpa de 54 pontos e pontuações 100/100 correspondentes na própria ferramenta da Hostinger tanto no desktop quanto no mobile. O Kodee reforçou isso com respostas precisas e específicas a perguntas técnicas reais, em vez de respostas genéricas de script.

As arestas ásperas são pequenas, mas vale a pena conhecê-las antes da compra. “Managed MySQL” soa na página do plano como algo pronto no momento em que seu app entra no ar, e na prática significa um formulário de criação manual. O dashboard também não dá à Web Apps Hosting uma entrada dedicada a partir da tela Home principal; você precisa saber que deve entrar em Websites primeiro.

Para um desenvolvedor que quer uma implantação rápida e agnóstica de framework em infraestrutura que pontua tão bem, esta é uma recomendação fácil. Para alguém que espera que cada recurso anunciado esteja ativado no momento em que o checkout termina, reserve alguns minutos extras para configurar o banco de dados por conta própria.

Hostinger

5.0

2,471 user reviews

€ 1,37 /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