Como escolher uma hospedagem (checklist sem marketing)

Escolher hospedagem costuma virar uma comparação de preço de entrada, e é daí que saem as surpresas: o plano barato que não aceita o seu back-end, o domínio cobrado à parte, a renovação que dobra de valor. O caminho mais seguro é inverter a ordem: primeiro o que o projeto precisa, depois o provedor.

O checklist abaixo vale para qualquer fornecedor e não aponta um vencedor universal, porque um blog estático e uma API com banco de dados pedem coisas diferentes.

O que o seu projeto precisa rodar?#

Essa pergunta elimina metade das opções. Há três cenários comuns:

• Site estático: arquivos prontos, sem código rodando no servidor. Veja o que é um site estático. É o caso mais simples e barato de hospedar.
• Aplicação com servidor: Next.js com renderização no servidor, uma API em Node.js ou Python, um painel administrativo. Precisa de um processo sempre ligado e de RAM.
• Aplicação com banco de dados: além do servidor, precisa de um banco (PostgreSQL, MySQL, MongoDB, Redis) acessível, de preferência perto da aplicação.

Se a diferença entre esses cenários ainda não está clara, leia o que é hospedagem de site antes de continuar.

Quais critérios importam de verdade?#

Use esta lista como filtro. Se o provedor falha em dois ou mais itens que importam para você, descarte.

1. Compatibilidade com a sua stack. A linguagem e a versão que você usa (Node, Python, PHP, Java) são suportadas? Hospedagem compartilhada tradicional costuma ser forte em PHP e fraca no resto.
2. RAM e CPU. É o limite que mais derruba site em produção. Descubra se o valor é por aplicação ou um total dividido entre todas, e se o provedor deixa claro o que acontece quando você passa dele.
3. HTTPS incluído. Hoje é requisito básico. Certificados são emitidos sem custo por autoridades como o Let's Encrypt, uma "autoridade certificadora gratuita, automatizada e aberta" nas palavras do próprio projeto. Cobrar caro por um certificado básico é sinal de alerta. Veja o que é SSL/TLS.
4. Domínio próprio. Confira se o plano aceita seu domínio e se o domínio é vendido junto ou à parte. Domínio e hospedagem são serviços diferentes. Registrar o domínio em seu nome, e não no do provedor, facilita trocar de hospedagem depois.
5. Logs e métricas. Sem logs, quem avisa que o site caiu é o cliente. Procure logs em tempo real e um painel de CPU e RAM.
6. Cópias e recuperação. Veja se existe cópia automática, por quanto tempo ela fica guardada e se você consegue restaurar sozinho. Teste a restauração pelo menos uma vez: cópia que nunca foi restaurada é só uma suposição.
7. Uptime e suporte. Entenda o que o número promete. Com 99,9% ao mês, o site pode ficar cerca de 43 minutos fora do ar (30 dias × 24 h × 60 min × 0,1%). Veja também o que significa 99,9% de uptime. Pergunte como o suporte responde e em que idioma.
8. Saída fácil. Dá para exportar o código, o banco e os arquivos? Há fidelidade ou multa de cancelamento? Prefira provedores em que sair é só mudar o DNS.

Quanto custa de verdade?#

O preço anunciado raramente é o total. Some:

• hospedagem (mensal ou anual);
• domínio (cobrado por ano, e a renovação pode custar mais que o primeiro ano);
• banco de dados, se não estiver incluído;
• excedente de tráfego, armazenamento ou tempo de build;
• cópias de segurança, e-mail profissional e CDN, quando cobrados à parte.

Faça a conta para 12 meses e compare o total, não a mensalidade. Para números por tipo de solução, veja quanto custa hospedar um site e quanto custa um domínio.

Compartilhada, VPS ou plataforma: qual tipo escolher?#

Não existe o melhor tipo, existe o que combina com o seu tempo e o seu conhecimento. Uma VPS barata sai cara se você gasta suas noites aplicando patches. A comparação completa está em VPS, cloud ou plataforma.

Que sinais de alerta evitar?#

• Promessas de "tráfego ilimitado" ou "recursos ilimitados" sem política de uso justo escrita.
• Preço de entrada só para o primeiro período, sem o valor da renovação visível.
• Nenhuma menção a limites de RAM ou CPU.
• Sem acesso a logs ou sem como exportar seus dados.
• Cobrança extra para ativar HTTPS.
• Comparativos que são, na verdade, links de afiliado sem aviso.

Qual escolher em cada cenário?#

• Portfólio ou blog estático: hospedagem estática ou plataforma de sites. O custo pode ser baixo e o HTTPS costuma vir pronto.
• Site institucional com formulário: estático com um serviço de formulário, ou uma aplicação pequena com back-end.
• Loja ou aplicação com banco de dados: plano com RAM folgada, banco próximo da aplicação, cópias automáticas e logs.
• API ou bot: processo sempre ligado, reinício automático e logs. Evite planos que suspendem a aplicação por inatividade.
• Projeto que vai crescer: priorize saída fácil e a possibilidade de aumentar a RAM sem migrar.

Como fazer isso na Square Cloud#

A Square Cloud é uma hospedagem self-service: você faz o deploy e controla a aplicação. Comparada ao checklist acima, ela cobre estes pontos (segundo as páginas oficiais):

• Stack: diversos runtimes, entre eles Node.js, Python, PHP, Go, Java e sites estáticos (no estático, o nginx fica sempre no ar servindo os arquivos). Veja os runtimes disponíveis hoje em Runtimes.
• RAM: o plano define um pool compartilhado entre suas aplicações, com mínimo de 512 MB por aplicação web. Todos os planos são pagos, e o Hobby começa em R$ 12,49 por mês.
• HTTPS e domínio: toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS. Domínio personalizado está disponível a partir do plano Standard, e continua registrado em seu nome no seu registrador.
• Banco de dados: hospedagem de MongoDB, PostgreSQL, MySQL e Redis a partir do Standard. O Hobby não inclui banco.
• Logs e métricas: logs em tempo real e analytics web sem cookies em todos os planos.
• Sem suspensão: os containers ficam sempre ligados, e o reinício automático (ligado por padrão no deploy pelo painel) traz de volta a aplicação que encerra com erro.
• Saída: sem fidelidade.

Veja as opções para sites na página de sites da Square Cloud.