Onde hospedar sistema web: VPS, nuvem ou serverless?

O sistema ficou pronto, os testes passaram e alguém pergunta na reunião: "e onde ele vai ficar?". Um sócio sugere o plano de hospedagem que já paga para o site institucional. O fornecedor fala em AWS. Um sobrinho que programa recomenda uma VPS barata. Outra pessoa leu sobre serverless e acha que é o futuro.

Todas essas opções funcionam para algum tipo de sistema. O problema é escolher pela mensalidade ou pela moda, sem olhar duas perguntas que decidem de verdade: o que o sistema precisa para rodar bem e quem vai cuidar dele depois que entrar no ar. A hospedagem errada não falha no primeiro dia. Ela falha no fechamento do mês ou no dia em que o único técnico sai de férias.

Este texto compara as quatro opções mais comuns pelo perfil do sistema e da equipe, e mostra o trabalho de operação que cada uma esconde.

A resposta curta

Se você precisa de uma orientação antes de ler o resto:

• Hospedagem compartilhada serve para site institucional, blog e páginas simples. Não serve para sistema de gestão, portal com login de clientes ou qualquer coisa que guarde dado importante da operação.
• VPS serve para sistemas pequenos e médios, com carga previsível, desde que exista alguém com tempo e conhecimento para administrar o servidor.
• Nuvem com serviços gerenciados (banco gerenciado, armazenamento de arquivos, balanceador, backup automático) é o caminho mais equilibrado para a maioria dos sistemas de gestão e portais de empresas pequenas e médias.
• Serverless encaixa bem em partes específicas: rotinas agendadas, integrações disparadas por evento, APIs com uso muito irregular. Raramente é a melhor escolha para o sistema inteiro.

A decisão não precisa ser única. É comum o sistema principal rodar em nuvem gerenciada e algumas rotinas rodarem em serverless. O mesmo raciocínio aparece em Vercel ou AWS, e quando usar as duas.

Hospedagem não é só onde o código roda

Um sistema web em produção depende de muito mais do que um computador ligado rodando o código:

• Banco de dados, com backup que alguém já testou restaurar.
• Arquivos: XML de notas fiscais, contratos, fotos, anexos.
• Domínio, DNS e certificado HTTPS, renovados sem ninguém precisar lembrar.
• Rotinas agendadas: importação de extrato, envio de cobrança, relatório de madrugada.
• Monitoramento e alertas, para saber que o sistema caiu antes do cliente ligar.
• Atualizações de segurança do sistema operacional e das bibliotecas.

Cada opção de hospedagem entrega uma parte disso pronta e deixa o resto com você. A pergunta certa é: depois de contratar, o que ainda fica sob responsabilidade da minha equipe ou do meu fornecedor?

Hospedagem compartilhada e seus limites

Na hospedagem compartilhada, vários sites dividem o mesmo servidor, administrado pela empresa de hospedagem. Você recebe um painel, uma área de arquivos, um banco de dados e uma conta de e-mail.

Ela resolve bem site institucional e blog: servidor, atualizações e certificado ficam com o provedor.

Para um sistema de gestão ou portal de clientes, os limites aparecem rápido:

• Recursos divididos. Se outro site no mesmo servidor recebe um pico de acesso, o seu sistema fica lento.
• Pouca liberdade técnica. Versões escolhidas pelo provedor, limite de tempo que derruba relatório pesado, restrição a processos em segundo plano e a rotinas frequentes.
• Backup genérico, nem sempre com a frequência e a restauração que um sistema com dado financeiro exige.
• Isolamento fraco. Para dado pessoal de clientes e funcionários, dividir servidor com desconhecidos é difícil de justificar.

Regra prática: se o sistema tem login, guarda dado da operação e alguém perderia o dia se ele ficasse fora do ar, ele não deveria estar em hospedagem compartilhada.

VPS: controle e responsabilidade

VPS (servidor virtual privado) é uma máquina virtual só sua, com processador, memória e disco reservados. Você tem acesso total: instala o que quiser, configura do jeito que precisar.

É uma opção legítima. Um sistema de gestão com algumas dezenas de usuários e carga previsível roda muito bem numa VPS bem configurada.

O ponto é que o "privado" vem junto com "por sua conta". Na VPS, você atualiza o sistema operacional, configura firewall e acessos, instala e ajusta o banco, monta o backup com cópia fora daquela máquina, testa a restauração e percebe quando o servidor chegou ao limite.

Nada disso é difícil para quem administra servidores. O risco está em contratar a VPS achando que ela se cuida sozinha. O cenário típico: o sistema roda um ano sem problema, o disco enche de log numa sexta à noite, o banco para de gravar e ninguém recebe alerta.

A VPS também tem teto. Crescer significa trocar por uma máquina maior, com janela de manutenção. Alta disponibilidade com duas máquinas é possível, mas multiplica o trabalho de operação.

VPS faz sentido quando: a carga é previsível, o sistema é de porte pequeno ou médio e existe uma pessoa ou fornecedor com responsabilidade clara sobre o servidor, incluindo plantão.

Nuvem com serviços gerenciados

Nos grandes provedores de nuvem (AWS, Google Cloud, Azure e outros), você pode simplesmente alugar máquinas virtuais, o que na prática é parecido com uma VPS. O ganho real aparece quando o sistema usa serviços gerenciados: peças em que o provedor assume parte da operação.

O sistema fica mais resistente: se a máquina da aplicação cair, outra sobe no lugar, e o banco pode ser recuperado para um ponto no tempo, desde que esse recurso esteja ativado e a retenção configurada.

Isso não significa que a nuvem "se opera sozinha". Continua sendo preciso desenhar rede e permissões com cuidado (um erro de configuração pode expor um banco à internet), manter a aplicação atualizada e acompanhar a conta, que é cobrada por uso e cresce sem aviso se ninguém olhar. Sobre esse último ponto, vale ler como reduzir a conta de nuvem sem perder estabilidade.

Nuvem gerenciada faz sentido quando: o sistema é importante para a operação, tem usuários externos (clientes, fornecedores), precisa crescer sem trocar de servidor ou quando a empresa não quer depender de uma pessoa para cuidar de banco e backup.

Se o ponto de partida hoje é um servidor físico dentro da empresa, o caminho até a nuvem tem etapas próprias, detalhadas em como migrar o servidor local da empresa para a nuvem.

Serverless: quando encaixa

Em serverless, você não administra servidor nenhum. Você entrega pequenos trechos de código (funções), e o provedor executa cada um quando é chamado, cobrando pelo número de execuções e pelo tempo de cada uma. Sem chamada, não há servidor seu ligado nem cobrança de processamento.

Funciona muito bem para:

• Rotinas agendadas: buscar o extrato de manhã, enviar lembrete de vencimento.
• Reação a eventos: o banco avisou que o Pix foi pago, então a função baixa o título.
• Uso muito irregular: um formulário que recebe muitos acessos numa campanha e quase nada no resto do mês.

E costuma atrapalhar quando:

• O sistema tem uso constante o dia inteiro. Um sistema de gestão aberto das 8h às 18h por toda a equipe não aproveita a vantagem de "pagar só quando usa" e pode sair menos previsível do que uma estrutura convencional.
• Há processamento longo. Funções têm limite de tempo de execução. Fechamento de folha, importação grande ou relatório pesado precisam ser quebrados em partes ou ir para outro lugar.
• A equipe não domina o modelo. Depurar um fluxo espalhado em funções, filas e gatilhos exige logs, métricas e rastreamento bem montados.
• A dependência do provedor preocupa. Código serverless fica mais amarrado a um provedor do que uma aplicação em contêiner.

Na prática, serverless é uma ótima ferramenta para pedaços do sistema, ao lado de uma aplicação principal em contêiner ou VPS. A escolha entre um sistema único ou vários serviços menores é outra decisão de arquitetura, com prós e contras próprios, discutida em monólito ou microsserviços.

Quem opera: o custo escondido de cada opção

A tabela abaixo resume o que cada opção deixa sob responsabilidade de quem contrata. É ela que deveria guiar a decisão, mais do que a mensalidade.

Nenhuma coluna está vazia. A diferença é o que fica com você e com que tipo de conhecimento.

Por isso, a pergunta "quem vai operar?" vem antes de "onde vai rodar?". Três cenários comuns:

• Sem equipe técnica e sem contrato de sustentação. A VPS é a opção mais arriscada aqui, mesmo sendo a mais simples no papel. Nuvem gerenciada com um fornecedor responsável pela operação costuma ser mais segura.
• Com um técnico interno que conhece Linux. VPS pode funcionar bem, desde que backup, alerta e plantão estejam definidos por escrito.
• Com fornecedor e contrato de operação. A escolha passa a ser técnica, e a conversa deve incluir quem responde por incidente e em quanto tempo, o que se define num SLA de suporte e sustentação.

Como escolher: um roteiro de decisão

Antes de contratar qualquer coisa, responda a estas perguntas por escrito:

1. Quantas pessoas usam o sistema e em que horário? Equipe interna no horário comercial é diferente de clientes acessando a qualquer hora.
2. Quanto tempo fora do ar a operação aguenta? Uma hora parada no faturamento não é igual a uma hora parada às 3h.
3. Quanto dado a empresa aceita perder? Se a resposta é "nenhum pedido", backup diário não basta: é preciso réplica ou backup contínuo do banco. Esse cálculo faz parte de um plano de recuperação de desastres.
4. Que tipo de dado o sistema guarda? Dado pessoal pede atenção a acesso e registro. Na dúvida, valide os requisitos com o jurídico.
5. A carga tem picos ou processamentos longos? Campanha, fechamento de mês e importações grandes mudam o tamanho necessário e limitam o serverless.
6. Quem opera e quem é acionado de madrugada? Se não houver um nome, essa é a primeira coisa a resolver.
7. O sistema depende de algo dentro da empresa? Balança, impressora, rede local. Isso pode exigir VPN ou um componente local.

Com essas respostas na mesa, a escolha costuma ficar evidente. E, qualquer que seja a opção, alguns itens não são negociáveis:

• Backup automático com cópia fora do ambiente principal e restauração testada.
• Alerta de indisponibilidade que chegue a uma pessoa, não a uma caixa de e-mail esquecida.
• Acesso administrativo com autenticação forte e lista de quem tem acesso.
• Domínio e conta do provedor em nome da empresa, não do fornecedor nem de um funcionário.
• Documento curto explicando onde está cada peça e como fazer uma restauração.

Como migrar se a escolha não servir mais

Nenhuma escolha de hospedagem é para sempre. O que dá para fazer desde o início é não se prender:

• Empacote a aplicação em contêiner. Ela roda praticamente igual numa VPS, num serviço gerenciado ou em outro provedor.
• Mantenha configuração e credenciais fora do código, em variáveis de ambiente ou num cofre de segredos.
• Descreva a infraestrutura em código. Com servidores e bancos criados por scripts versionados, recriar o ambiente vira tarefa planejada, não arqueologia.
• Guarde arquivos fora do servidor da aplicação. Anexos no disco local amarram o sistema àquela máquina.
• Registre cada recurso específico do provedor que usar, sabendo o que custaria trocar.

A migração segue o roteiro de qualquer mudança de ambiente: montar o destino, copiar os dados, ensaiar, validar com as áreas e ter plano de volta. O prazo varia muito: uma aplicação pequena e bem empacotada pode mudar em poucos dias, um sistema antigo cheio de acoplamentos pode exigir semanas de preparação. Só um levantamento do ambiente dá um prazo confiável.

Perguntas frequentes

Preciso usar AWS para hospedar um sistema web?

Não. A AWS é um dos grandes provedores de nuvem, ao lado de Google Cloud, Azure e outros, e uma VPS bem administrada também atende muitos sistemas pequenos e médios. O que decide é o perfil do sistema e quem vai operá-lo. Mais importante que o nome do provedor é ter backup testado, alertas e contas em nome da empresa.

Vale a pena manter o sistema num servidor dentro da empresa?

Vale em poucos casos, como quando o sistema depende de equipamentos ou da rede local. Num servidor próprio, a empresa assume tudo o que a VPS exige e ainda o hardware, a energia e a conexão com a internet. Para a maioria dos sistemas de gestão, a nuvem gerenciada reduz esse trabalho e o risco.

Em nome de quem deve ficar a conta de hospedagem?

Em nome da empresa, sempre. A conta do provedor de hospedagem, o domínio e o acesso administrativo não devem ficar no nome do fornecedor nem de um funcionário. Se essa pessoa sai ou o contrato termina, a empresa pode perder o acesso ao próprio sistema. O fornecedor recebe acesso delegado, que pode ser revogado.

Dá para trocar de hospedagem depois que o sistema está no ar?

Dá, e fica muito mais fácil quando o sistema foi preparado para isso: aplicação em contêiner, configuração fora do código, infraestrutura descrita em scripts e arquivos fora do servidor. A migração de hospedagem segue o roteiro de montar o destino, copiar os dados, ensaiar, validar e ter plano de volta. O prazo depende do levantamento do ambiente.

Como a Pervian Tech trabalha hospedagem

Na Pervian Tech, hospedagem faz parte do trabalho de cloud e DevOps. Começamos pelo perfil do sistema e da equipe: quem usa, quanto tempo parado a operação aguenta, que dados ele guarda e quem vai cuidar dele no dia a dia. A partir disso, recomendamos a opção mais simples que atende, seja VPS, nuvem gerenciada, serverless ou uma combinação, e entregamos o ambiente com backup testado, alertas, infraestrutura descrita em código e documentação, com as contas em nome da sua empresa.

Também migramos ambientes que já existem. Outros textos sobre o tema estão em cloud e infraestrutura.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito do seu sistema e do seu ambiente atual. Se você está decidindo onde colocar um sistema novo, ou desconfia que o atual está no lugar errado, conte como ele funciona hoje.