Duas aplicações podem usar menos de 20% da CPU e exigir infraestruturas bem diferentes. Pense num relatório interno que pode aguardar algumas horas até o servidor voltar. Num checkout durante uma campanha, a mesma interrupção pode deixar pagamentos sem confirmação na aplicação. Você vê um gráfico semelhante nas duas VPS, mas precisa combinar prazos de recuperação diferentes para cada serviço.

Na comparação entre provedores, eu considero a importância da aplicação e a manutenção que você consegue assumir. A configuração da máquina precisa comportar o uso previsto, mas também deve permitir recuperar o serviço dentro do prazo combinado.

Um catálogo amplo pode oferecer um banco gerenciado para você separar o PostgreSQL da aplicação. Num sistema pequeno, o console de recuperação permite acessar a VPS quando a conexão SSH falha. A utilidade de cada recurso depende do que você precisa administrar naquele ambiente.

Direto ao ponto

Uma VPS única pode atender quando você consegue restaurar a aplicação dentro do prazo combinado. O Docker Swarm instalado em uma só máquina publica os containers conforme o arquivo da stack, porém todos continuam sujeitos à falha desse host. Num cluster, outra réplica pode receber a requisição se o encaminhamento permanecer disponível e ela conseguir acessar o banco e os arquivos após a saída de uma máquina.

Para começar com uma VPS, eu prefiro a HostGator pelo suporte próximo e pela comunidade local. Hetzner e DigitalOcean entram na comparação quando você precisa de rede privada entre hosts ou quer provisioná-los por API. Oracle Cloud e AWS podem fazer sentido quando a arquitetura também depende de serviços gerenciados desses fornecedores. Compare a configuração disponível na região escolhida e o trabalho necessário para manter sua aplicação nesse ambiente.

A mesma VPS pode servir ao relatório e falhar no checkout

No exemplo do relatório, a consulta pode aguardar a restauração porque existe um intervalo até o próximo uso. No checkout, o cliente espera a confirmação da compra e pode procurar atendimento ao ver uma cobrança sem acesso liberado. Você precisa explicar quanto tempo o serviço pode ficar indisponível e como a aplicação reconhecerá os pagamentos recebidos durante esse intervalo.

Você consegue testar a recuperação restaurando uma cópia fora do servidor principal e procurando a última venda gravada. O horário desse registro mostra quanto histórico o backup preservou. O tempo gasto até conseguir concluir uma nova compra mostra a duração da restauração, que pode terminar mesmo com vendas recentes ausentes do banco recuperado.

Um webhook que não chegou à aplicação também não está automaticamente na fila. No ambiente de teste, confira se o fornecedor tenta enviar a confirmação novamente ou oferece uma consulta para recuperar o pagamento. A aplicação precisa reconhecer uma confirmação repetida para evitar a duplicação da venda. Sem esse mecanismo, o retorno da VPS pode exigir conferência manual dos pagamentos recebidos durante a interrupção.

Uma stack organizada ainda pode parar numa só máquina

Uma aplicação pode concentrar o proxy, o banco e os serviços de processamento numa única VPS. O proxy encaminha a requisição ao container da aplicação, que consulta o PostgreSQL e envia o trabalho demorado à fila. Separar esses processos facilita a atualização de cada serviço, mas a indisponibilidade do host interrompe todos eles. Duas réplicas dentro dessa VPS continuam usando a mesma máquina.

No Swarm solo, o mesmo host administra o cluster e executa os serviços. O arquivo da stack descreve como publicar os containers e pode continuar útil quando outras máquinas forem adicionadas. Você consegue observar o limite dessa configuração ao desligar a VPS de laboratório: não existe outro host disponível para assumir o serviço.

Manter acesso administrativo faz parte da recuperação. O guia da Promovaweb para corrigir o OpenSSH no Debian explica o cuidado de preservar a sessão atual e conferir uma segunda conexão durante a manutenção. Para acompanhar comandos demorados, o artigo sobre tmux no terminal mostra como retomar uma sessão quando a conexão do notebook cai. O servidor precisa continuar funcionando para essa sessão permanecer disponível.

O cluster precisa provar a saída de um host

Três máquinas podem distribuir réplicas, mas você precisa conferir quais delas administram o Swarm. Com três managers, dois precisam continuar se comunicando para o cluster reorganizar os serviços após uma falha. Se o único manager ficar indisponível, os containers nos workers podem continuar executando, porém o Swarm não consegue realocar as tarefas. A documentação de administração do Docker Swarm explica essa exigência de maioria entre managers.

O teste de continuidade precisa acompanhar uma requisição após a retirada de um host de laboratório. Uma réplica acessível ainda pode falhar ao consultar um PostgreSQL que estava na máquina retirada. Os arquivos enviados pelos clientes também precisam continuar disponíveis no armazenamento usado pela aplicação. Você confere a recuperação ao concluir a jornada, incluindo a leitura do registro e do anexo.

Cada host acrescenta um sistema operacional para atualizar e novos logs para consultar. A restauração precisa de um procedimento compreendido por você, inclusive se a falha atingir o banco. Agentes instalados no servidor também executam comandos com as permissões disponíveis, tema desenvolvido no artigo sobre memória, skills e ferramentas do Hermes Agent.

O provedor muda quando a manutenção muda

No primeiro servidor, confira como acessar o console quando o SSH estiver indisponível. Uma reinstalação documentada ajuda você a reconstruir a máquina, mas o backup ainda precisa preservar o histórico da aplicação. A rede privada entra na comparação quando banco e aplicação ficam em hosts diferentes. Com um serviço gerenciado, parte da manutenção fica com o fornecedor conforme o contrato daquele serviço.

Os componentes podem mudar de provedor em momentos diferentes. O código pode permanecer na VPS e consultar um PostgreSQL gerenciado, com os uploads armazenados num serviço externo. Você precisará acompanhar a conexão entre esses serviços e o efeito de uma interrupção em cada fornecedor. A análise de Laravel em projetos de Vibe Coding examina as convenções de banco e filas usadas para organizar a aplicação no repositório.

O procedimento de restauração mostra quais recursos você precisa procurar no provedor. Para revisar a arquitetura e acompanhar as alterações do ambiente ao longo do projeto, o Conselheiro de Tecnologia da Dev Side Studio oferece acompanhamento técnico recorrente.

A Formação DevOps da Promovaweb desenvolve a prática de servidores e manutenção usada nessa comparação. No vídeo sobre provedores de VPS, eu apresento as opções guiadas e as plataformas para arquiteturas distribuídas. Assista com o prazo de recuperação e o procedimento de restauração da sua aplicação ao lado para comparar os fornecedores a partir do serviço que você precisa manter.