# Onde hospedar sistema web: VPS, nuvem ou serverless?

> Onde hospedar sistema web: compare hospedagem compartilhada, VPS, nuvem gerenciada e serverless pelo perfil do sistema e veja o trabalho que cada opção esconde.

Fonte: https://pervian.tech/blog/onde-hospedar-sistema-web · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/banco-de-dados-gerenciado-ou-proprio), 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](https://pervian.tech/blog/vercel-ou-aws).

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

Um [sistema web](https://pervian.tech/blog/site-sistema-web-ou-plataforma) 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.

| Peça do sistema | Na VPS | Com serviço gerenciado |
|---|---|---|
| Banco de dados | Você instala, atualiza e faz backup | Provedor cuida de atualização e backup automático; réplica é opcional |
| Arquivos e anexos | Ficam no disco do servidor | Armazenamento de objetos, durável e separado da aplicação |
| Aplicação | Roda direto no servidor | Contêineres ou plataforma de aplicação que reinicia sozinha |
| Certificado e balanceamento | Configuração manual | Balanceador com certificado renovado automaticamente |
| Crescimento | Trocar por máquina maior | Mais instâncias quando a carga sobe |
| Monitoramento | Ferramenta instalada à parte | Métricas e alertas nativos da plataforma |

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](https://pervian.tech/blog/como-reduzir-custos-de-nuvem).

**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](https://pervian.tech/blog/migrar-servidor-local-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](https://pervian.tech/blog/observabilidade-logs-metricas-e-traces) 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](https://pervian.tech/blog/monolito-ou-microsservicos).

## 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.

| O que precisa ser feito | Compartilhada | VPS | Nuvem gerenciada | Serverless |
|---|---|---|---|---|
| Atualizar sistema operacional | Provedor | Você | Provedor (nos gerenciados) | Provedor |
| Backup do banco e teste de restauração | Parcial, genérico | Você, do zero | Configurar e testar | Configurar e testar |
| Escalar quando a carga sobe | Não escala | Trocar de máquina | Configurar regras | Automático, com limites |
| Segurança de rede e acessos | Provedor, pouco controle | Você, tudo | Você, com ferramentas prontas | Você, nas permissões |
| Monitoramento e alertas | Quase nenhum | Montar | Nativo, precisa configurar | Nativo, precisa configurar |
| Controle da conta | Simples, fixa | Simples, fixa | Exige acompanhamento | Exige acompanhamento |
| Conhecimento exigido da equipe | Baixo | Administração de servidor | Arquitetura de nuvem | Arquitetura orientada a eventos |

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](https://pervian.tech/blog/sla-de-suporte-e-sustentacao-de-software).

## 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](https://pervian.tech/blog/plano-de-recuperacao-de-desastres-para-sistemas).
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](https://pervian.tech/blog/docker-e-containers-para-gestores).** 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](https://pervian.tech/servicos/cloud-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](https://pervian.tech/blog/categoria/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](https://pervian.tech/#contato).