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 colocar um aplicativo ao vivo, em produção, rodando em cerca de um minuto, sem um servidor para você gerenciar. Quis descobrir quanto disso realmente se sustenta quando é você quem clica em implantar, então foi isso que encontrei.

Implante Web Apps Mais Rápido com a Hostinger

Implante aplicativos web modernos na Hostinger com builds automatizadas, infraestrutura gerenciada, CDN global, SSL, ferramentas de segurança e garantia de reembolso de 30 dias.

Visite Hostinger

Prós e Contras

Resumo da Avaliação

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

Hospede seus Web Apps Sem a Complicação de DevOps

Implante aplicativos web modernos em hospedagem totalmente gerenciada com deploys automatizados, SSL gerenciado, CDN global e segurança integrada.

Visite Hostinger

Planos e Preços

A Hostinger vende Web Apps Hosting em dois níveis, Business e Cloud Startup, ambos criados especificamente para implantar apps modernos em Node.js e JavaScript, e não para construtores de sites tradicionais.

Cloud Startup, o nível 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 gratuito, e-mail comercial gratuito e SSL gerenciado durante o primeiro ano, diretamente no checkout.

Algumas coisas para saber antes de pedir:

• Garantia de reembolso: Web Apps Hosting se enquadra nos termos padrão de reembolso da Hostinger, uma janela simples de 30 dias a partir da data da compra. Isso é bem 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 gratuito: Não encontrei um teste gratuito dedicado. A garantia de reembolso de 30 dias é a sua janela de avaliação.
• Métodos de pagamento: O checkout mostrou pagamento por cartão como método padrão, com os logotipos Visa, Mastercard, Amex e Discover exibidos, além da opção de adicionar um método de pagamento diferente durante o checkout.
• O que vem incluído: Um domínio gratuito por um ano, caixas de correio gratuitas por um ano e SSL gerenciado estão todos incluídos sem custo extra além do preço do plano, então o preço exibido está muito próximo do custo real para colocar um deploy totalmente funcional e seguro no ar.
• O único upsell: Hostinger Reach, um complemento de marketing por e-mail, aparece no carrinho como uma caixa destacada separada com preço mensal próprio. É fácil ignorá-lo e ele não vem incluído nem pré-selecionado por padrão.

Se você cancelar um plano 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 desse prazo 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 ativa por padrão
• Proteção WAF e DDoS incluída
• Backups diários e sob demanda
• Scanner de malware e varredura de vulnerabilidades
• Integração com GitHub com auto-deploy
• Domínio, e-mail e SSL gratuitos
• Acesso SSH para usuários avançados

Do Código ao App ao Vivo com a Hostinger

Conecte seu repositório GitHub ou envie seu projeto e coloque-o online com infraestrutura gerenciada, deploys automáticos e backups diários.

Visite Hostinger

Desempenho

Como o Web Apps Hosting é totalmente gerenciado, você nunca obtém acesso shell a um servidor, então não há CPU, RAM ou disco para benchmark direto, como faria em uma análise de VPS.

O que você pode medir é a rapidez com que o aplicativo implantado carrega e responde, a partir de locais reais ao redor do mundo. Testei isso de quatro ângulos diferentes: GTmetrix a partir de dois continentes, uma verificação global com mais de 50 pontos e a ferramenta de velocidade integrada da Hostinger tanto para desktop quanto para mobile.

O app sob teste é o deploy em Next.js coberto na seção de Facilidade de uso abaixo, disponível em ivory-llama-856835.hostingersite.com, rodando no plano Cloud Startup (4 núcleos de CPU, 4096 MB de RAM, 100 GB de armazenamento NVMe), com CDN ativa 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 apenas de um ponto de vista privilegiado.

Ambas as execuções chegaram a 100% perfeitos tanto em Performance quanto em Structure, com zero layout shift e zero tempo de bloqueio em ambas as localidades, o que significa que nada na página competiu pela atenção do navegador nem pulou de lugar durante o carregamento.

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 esse app. Esse resultado só faz sentido à luz da CDN.

Assim que uma CDN está ativa, como estava aqui por padrão, seu visitante não está necessariamente chegando diretamente ao servidor de origem.

Ele está chegando ao nó de borda em cache mais próximo, então um ponto de teste europeu pode acabar sendo mais rápido que um dos EUA, mesmo quando o servidor real fica nos EUA. Isso é uma confirmação real e prática de que a CDN ativada por padrão da Hostinger está realmente fazendo seu trabalho, em vez de ficar ali como uma caixa de seleção de marketing sem uso.

2. Consistência Global (Check-Host)

Executei uma verificação HTTP no URL ao vivo a partir de todos os pontos de checagem que o Check-Host oferece, 54 locais espalhados 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 pontos de checagem europeus consistentemente retornaram os tempos mais rápidos, vários abaixo de 50 milissegundos, enquanto os pontos de checagem fisicamente mais distantes de qualquer nó de borda, Tóquio, Singapura, 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 comportamento esperado para um deploy com CDN: rápido perto das bordas, mas ainda totalmente funcional longe delas.

Os quatro timeouts, Cazaquistão, Romênia e dois dos quatro pontos de checagem russos, não são algo que eu interpretaria como um problema na infraestrutura da Hostinger.

Outros pontos de checagem nos mesmos países tiveram sucesso (São Petersburgo respondeu limpo em 0.063s, enquanto dois pontos de Moscou expiraram), o que aponta para filtragem de rede regional no lado do ponto de checagem, 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 de Page Speed diretamente no painel do app, então comparei os números dele com os resultados independentes do GTmetrix em vez de aceitar qualquer um dos dois pelo valor de face.

Ambos os tipos de dispositivo pontuaram 100 perfeitos, e os números de desktop coincidem de perto com o que o GTmetrix mediu de forma independente, que é o ponto real de executar os dois. 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 real de mobile realmente forte, e não apenas uma escala de avaliação leniente.

Uma inconsistência na própria ferramenta. Mesmo com a pontuação limpa de 100 nos dois 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 derrubou a pontuação principal, então trate-as como oportunidades de otimização pequenas e realmente existentes, e não como algo errado no deploy.

Separadamente, os “links úteis” que a Hostinger mostra ao lado desses diagnostics 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 parte nenhuma da stack. Isso é um resto de um modelo compartilhado de diagnostics, e não conteúdo feito para este produto.

Veredito Geral sobre o Desempenho

Hospedagem Gerenciada de Web App pela Hostinger

Concentre-se em construir seu aplicativo enquanto a Hostinger cuida do deploy, da infraestrutura, da segurança, do SSL, dos backups e da entrega global.

Visite Hostinger

Facilidade de Uso

Testei a Hostinger Web Apps Hosting desde a página de destino até o checkout, e depois de uma conta nova até um deploy Node.js totalmente ao vivo e funcional.

Isso incluiu escolher um plano, pagar, decidir como construir, conectar o GitHub e acompanhar o build ser concluído em tempo real. Foi isso que o processo realmente pareceu.

1. Registro

Comecei na página de destino da Web Apps Hosting, que abre com uma única chamada para ação: Start deploying.

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

Dois planos apareciam lado a lado:

Escolhi o Cloud Startup por oferecer o dobro da quantidade de apps e mais folga de CPU em relação ao nível inicial. Um pequeno detalhe inconsistente para apontar aqui: a página de preços o chama de “Cloud Startup”, mas, quando chega ao carrinho, o mesmo plano é rotulado como “Startup plan”. Não é um problema funcional, apenas uma discrepância de nome entre duas telas do mesmo fluxo de checkout.

O carrinho em si estava limpo. Ele listava o prazo de 48 meses, a economia, um domínio gratuito por um ano e e-mails gratuitos, e então oferecia um único upsell, Hostinger Reach email marketing, em sua própria caixa destacada, e não pré-selecionado.

Ignorei isso e cliquei em Continuar sem dificuldade.

Se você for um novo cliente e não um já 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.

Depois, 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 da compra em poucos momentos após clicar em Enviar pagamento, e então fui direto para o hPanel com o plano já provisionado.

O que eu achei: O checkout é curto e o upsell é fácil de recusar sem precisar procurar um link oculto para pular. A discrepância de nome 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 selecionou o nível certo.

2. Dashboard

Assim que o pagamento é aprovado, você cai no hPanel, o painel de controle interno da Hostinger, criado para gerenciar todos os produtos que ela vende, e não uma página feita especificamente para o seu novo Web App.

A primeira página em que você entra é a Home, e ela é organizada 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.

Role para baixo e você encontrará:

• Blocos de promoção de recursos para AI Builder, a ferramenta de loja online, claiming a free business email, AI agents, a automation app, e claiming a free domain
• Uma lista de tarefas incentivando você a concluir etapas de configuração, finalizar a configuração do Reach, reivindicar seu e-mail gratuito, reivindicar seu domínio gratuito
• 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 da Home. É o mesmo assistente Kodee usado para suporte, mas posicionado aqui como uma ferramenta geral de ação com prompts prontos como “Deploy my Node.js app” ou “Harden VPS updates” que você pode acionar sem 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 é ali que você vai para criar um novo Web App ou acessar 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 do Business também já tinha um app ativo listado abaixo dele de testes anteriores, orange-walrus-700988.hostingersite.com, com seus próprios botões Tools e Dashboard.

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

Como o Cloud Startup era o plano que eu tinha acabado de comprar e ainda não havia 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, e não na tela Home para a qual você é direcionado por padrão.

O que eu achei: O hPanel é claro depois que você encontra a tela certa, mas o Web Apps Hosting não tem uma porta de entrada óbvia. Cair na Home mostra uma barra de prompt e atalhos, não um caminho para criar um app; você precisa saber clicar em Websites e depois em Web Apps antes que o Setup apareça. Isso 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 para iniciantes no topo, Hostinger AI Builder e WordPress + AI, e duas opções abaixo de um cabeçalho separado “for advanced users”: Node.js web app e PHP/HTML website. Selecionar Node.js web app é o que realmente coloca você no produto Web Apps Hosting.

Este é um ponto estrutural real para quem estiver comparando produtos: o Web Apps Hosting não tem seu próprio fluxo de cadastro dedicado.

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

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

A partir daí:

• Tela de domínio: escolhi Use temporary domain em vez de comprometer um domínio real, já que este era um deploy de teste.

• Tela de localização do servidor: a Hostinger pré-selecionou a França, a região mais próxima do meu país de cobrança, e mostrou 167ms de latência. Ao rolar até a opção dos Estados Unidos, apareceram 364ms, mais que o dobro.

Escolhi os Estados Unidos, Massachusetts mesmo assim, e essa é a lição exata que o seletor de localização ensina em todo produto da Hostinger: escolha com base em onde seus visitantes reais estão, e não no número mais baixo da lista.

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

• Tela de método de deploy: duas opções principais, Import Git repository (marcada como Recommended) ou Upload your files, além de um destaque abaixo para deploy direto 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, incluindo os futuros, com acesso somente leitura aos repositórios públicos
• Instalar em apenas repositórios selecionados que você escolher individualmente e listar exatamente as permissões concedidas: acesso de leitura a actions, metadata e repository hooks, e acesso de leitura e gravação a administration, code e pull requests. Assim que você clica em Install & Authorize, o GitHub o redireciona automaticamente de volta para o hPanel.

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

Desde clicar nesse botão até a próxima página carregar, levou perto de 30 segundos sem nenhum indicador de progresso na tela, 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 ficará hospedado antes de você confirmar qualquer coisa: “Deploys to ivory-llama-856835.hostingersite.com.” Abaixo disso, sem você tocar em um único campo, ela 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 de chave-valor para confirmar se ele realmente chegaria ao app em execução depois, depois cliquei em Finish naquela caixa de diálogo e então 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 estágios reais; vi ela passar por 28% e depois 51%, rumo à conclusão. Abaixo da barra de progresso há um painel recolhível Build logs, e ao expandi-lo você vê saída real de terminal ao vivo, e não um spinner de espaço reservado:

> 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 …

Deploy concluído

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

A partir dessa página, você pode clicar direto em Go to dashboard, que é onde você passa a gerenciar o app.

O que eu achei: A detecção automática é o ponto alto aqui. Framework, branch e versão do Node vieram todos corretos sem um único campo manual, e o log de build ao vivo torna a espera transparente em vez de opaca. O único ponto fraco é essa pausa de 30 segundos antes mesmo de você chegar à tela de configurações, tempo suficiente para achar que algo travou antes de o processo começar de forma visível.

4. Confirmando o Deploy ao Vivo

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

Na página Deployment completed, cliquei direto no URL ao vivo, ivory-llama-856835.hostingersite.com, em vez de confiar apenas na miniatura de prévia do dashboard.

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 construída recentemente, e não servida de um cache antigo
• Verificação da variável de ambiente, mostrando a variável personalizada que defini durante a tela de deploy, confirmada corretamente no site ao vivo de verdade, e não apenas na prévia do dashboard

Então cliquei no botão próprio do app, Ping the API route, 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 importa mais do que parece. Uma página carregar 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 trás e respondendo a solicitações reais, a parte de “Node.js web app” da hospedagem que é fácil de falsificar com um arquivo estático e difícil de falsificar com um carimbo de data/hora do servidor ao vivo gerado exatamente no momento em que você clica em um botão.

O que eu achei: Essa é a verificação que eu recomendaria antes de confiar em qualquer deploy nessa plataforma, ou em qualquer outra parecida. Um status verde “Completed” e uma miniatura de prévia dizem que o build terminou. Clicar no 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, mostra que o servidor está realmente vivo e fazendo o que você construiu para ele fazer.

5. Gerenciamento do Web App

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

Visão geral do dashboard. Assim que você chega aqui, quatro badges de status mostram o estado das coisas de relance:

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

Um teste automático de Page Speed 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, gerenciador de arquivos, logs de runtime e cache.

Deployments, variáveis de ambiente e logs. Três páginas separadas cobrem esse assunto:

• Deployments manteve um histórico 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 defini durante o deploy, confirmando que ela foi armazenada e aplicada, e não apenas mostrada uma vez durante a configuração e depois esquecida
• Runtime logs transmitiu a saída do servidor ao vivo conforme acontecia, linhas de inicialização do Next.js, timestamps de readiness e uma contagem em andamento 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 claramente declarada em vez de escondida nas letras miúdas: ele verifica apenas 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 varredura de Vulnerabilities também voltou limpa.

Bancos de dados. Aqui é onde o próprio marketing do produto cria uma lacuna real que você precisa entender antes de comprar. O plano anuncia MySQL gerenciado como 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 de seu app poder usá-lo. Confirmei isso diretamente com o Kodee, coberto 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, e não que um banco de dados é criado para você assim que seu app entra no ar.

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

O que eu achei: O dashboard do dia a dia é completo e bem organizado. Segurança e histórico de deploy, em particular, são fáceis de encontrar e realmente informativos, e o log de runtime sem issues, junto com uma varredura de malware limpa, me deram confiança real de que o app estava saudável, e não apenas online.

O único ponto em que a interface exagera é a seção de banco de dados, onde “MySQL gerenciado” parece, na página do plano, algo pronto para você assim que o app entra no ar, mas na prática significa um formulário de criação que você mesmo precisa preencher.

Veredito Geral sobre Facilidade de Uso

Construa, Implante e Escale com a Hostinger

Hospede aplicativos web 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 dashboard do próprio Web App.

1. Suporte por IA (Kodee)

Fiz duas perguntas baseadas em lacunas reais que encontrei durante os testes, e não buscas genéricas que o Kodee pudesse responder copiando a documentação.

Pergunta 1 testou comportamento de falha no deploy e o momento das variáveis de ambiente, ambas preocupações de produção reais para quem estiver publicando nessa plataforma:

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

O Kodee respondeu diretamente e corretamente em ambos os pontos. Um build com falha não substitui um app que já está em execução; se um deploy anterior tiver sido bem-sucedido, o app continua servindo a última versão funcional. Se for o primeiro deploy e não houver nada para voltar, o app fica fora do ar até que o build seja corrigido e implantado novamente, uma resposta clara e honesta em vez de uma garantia vaga.

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

Pergunta 2 apertou os dois pontos que eu mesmo tinha encontrado ao explorar o dashboard, a frase “MySQL gerenciado” em contraste com o formulário manual de criação, e o SSH aparecendo como 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 todo 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 sobre como meu app realmente executa, 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; “gerenciado” 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á tinha visto, seguida de adicionar os detalhes de conexão às variáveis de ambiente do seu app por conta própria.

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

O que eu achei: Ambas as respostas corresponderam ao 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 verifica o estado real do produto em vez de recitar um script. Nenhuma das perguntas poderia ser respondida simplesmente copiando uma FAQ genérica, e o Kodee lidou com as duas 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.

Web Apps Hosting não recebe sua própria categoria dedicada. O conteúdo dele fica espalhado entre Getting Started, hPanel e Website, o que é uma descoberta real para quem esperava uma casa própria dedicada, 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 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 por completo
• Vários artigos de métodos 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. Acabou sendo um guia completo e bem estruturado, com frameworks suportados listados logo no início, capturas de tela passo a passo para os caminhos de importação via GitHub e upload de ZIP, uma seção sobre configuração de build settings com comandos de exemplo, uma explicação da estrutura de arquivos após o deploy, um passo a passo do assistente de conexão com banco de dados, uma seção sobre monitoramento de vulnerabilidades e um bloco final de FAQ.

Mesmo sendo apresentado 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 eu achei: A contagem de artigos na busca parece forte no papel, 71 resultados para um termo, mas uma parte significativa desse volume é ruído de produtos não relacionados que compartilham palavras parecidas. O artigo que abri por completo se manteve muito bom em qualidade, com passos claros, capturas reais e uma seção de FAQ de verdade, mas encontrá-lo exigiu passar por resultados que não tinham nada a ver com o que eu estava tentando implantar.

Veredito Geral sobre o Suporte ao Cliente

Hospedagem Simples para Web Apps Modernos

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 deploy é a parte mais forte deste produto: detecção automática correta do meu stack, branch e versão do Node, um log de build real em streaming em vez de um spinner, e um app ao vivo que passou em todos os testes de desempenho que eu lancei nele, pontuações perfeitas no GTmetrix a partir de dois continentes diferentes, uma verificação global limpa de 54 pontos e pontuações 100/100 correspondentes da própria ferramenta da Hostinger tanto no desktop quanto no mobile. O Kodee reforçou isso com respostas precisas e específicas para perguntas técnicas reais, em vez de respostas genéricas de script.

Os pontos fracos são pequenos, mas vale conhecê-los antes de comprar. “MySQL gerenciado” soa na página do plano como algo pronto assim que seu app entra no ar, e na prática significa um formulário manual de criação. O dashboard também não dá ao Web Apps Hosting uma entrada dedicada pela tela principal Home; você precisa saber entrar em Websites primeiro.

Para um desenvolvedor que quer um deploy rápido e agnóstico de framework sobre uma infraestrutura com esses benchmarks, 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,473 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