Alternativas à DigitalOcean: preço, rede e backups

O que as alternativas à DigitalOcean realmente mudam

A maioria das alternativas à DigitalOcean muda a fatura, não a máquina. Em qualquer uma delas, obtém uma máquina virtual Linux com um IP público, um disco virtio e acesso root, e o kernel não se importa com o logótipo que aparece no painel de controlo. As diferenças que determinam a escolha são o preço por GB de RAM, o volume de transferência incluído e o custo de cada byte excedente, a composição real do disco e a parte da stack acima do sistema operativo que outro fornecedor irá gerir por si.

Este guia compara esses aspetos, porque um programador pode verificar cada um deles a partir de um terminal ou numa tabela de preços publicada. Também identifica os casos em que a DigitalOcean é a escolha certa, porque uma comparação que não reconhece nenhuma vantagem não passa de publicidade.

Todos os preços abaixo são preços de tabela publicados, verificados em 5 August 2026. Os preços mudam, e mais de um fornecedor aqui apresentado alterou os seus preços durante 2026. A estrutura de preços muda muito mais lentamente. Por isso, leia primeiro os rácios e o modelo de faturação e confirme depois o valor atual na página do próprio fornecedor antes de contratar.

O preço por GB de RAM é o valor a comparar

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

Dentro do mesmo fornecedor, o preço por GB de RAM quase não varia. A DigitalOcean cobra $6.00 por GB no plano de 1 GB e os mesmos $6.00 por GB no plano de 4 GB, que custa $24.00 por mês. Escolher um plano maior no mesmo fornecedor não dá acesso a um desconto, por isso o tamanho do plano não é o fator de decisão. O fornecedor é.

Akamai, que agora comercializa o que antes era a Linode, pratica $12 e $24 nos planos partilhados de 2 GB e 4 GB, exatamente os mesmos preços da DigitalOcean. O seu plano de entrada é mais barato, a $5.00. Duas empresas com preços exatamente iguais dão um sinal importante: esse nível de preços é definido com base num concorrente, não no hardware, e continuará a acompanhar esse concorrente.

A diferença surge com fornecedores que constroem os seus próprios datacenters e vendem em euros. Um Hetzner CX23 oferece 4 GB de RAM por cerca de $6.49 por mês, ou $1.62 por GB, perto de um quarto do preço da DigitalOcean. Esse valor em dólares é convertido a partir de um preço de tabela em euros, por isso varia com a taxa de câmbio. A Hetzner também aumentou os preços da cloud durante 2026, por isso os artigos de comparação mais antigos apresentam valores que já não existem.

O preço por GB de RAM não diz nada sobre o CPU disponibilizado. Um vCPU partilhado significa que o hypervisor agenda o seu core juntamente com os de outros utilizadores, e a verificação correta deve ser feita numa máquina que tenha realmente alugado:

vmstat 1 10

Leia a coluna st. Ela indica a percentagem de tempo durante a qual o seu vCPU estava pronto para executar, mas o hypervisor entregou o core físico a outro utilizador. Alguns pontos percentuais sob carga são normais. Um valor de dois dígitos mantido durante algum tempo significa que o host está sobrelotado, e nenhum preço por GB compensa um core que não pode utilizar. Execute o teste na hora de maior utilização, porque o steal time é um problema causado pelos vizinhos e os vizinhos têm horários. Para uma visão mais abrangente do custo real de um mês de alojamento, depois de acrescentar o armazenamento e o tráfego, leia quanto custa um VPS por mês.

O custo real da transferência incluída

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

A DigitalOcean inclui 1 TB de transferência de saída no plano de entrada e cobra o excedente por GiB, o que corresponde a cerca de $10.00 por cada TB adicional. A Akamai inclui os mesmos TB e cobra aproximadamente metade desse valor, cerca de $5.00 por TB. A Vultr inclui 2 TB, com uma taxa de excedente semelhante. A Hetzner inclui 20 TB e cobra cerca de $1.20 por TB depois disso, uma diferença de uma ordem de grandeza em relação aos restantes fornecedores.

Três detalhes estruturais são mais importantes do que os valores apresentados. O tráfego de entrada é gratuito nos quatro fornecedores, portanto só é contabilizado o que enviar para fora. A DigitalOcean e a Vultr partilham o limite entre todos os servidores da conta. Assim, uma máquina ocupada consome a quota de outra, e uma frota de servidores pequenos partilha um único limite grande. O tráfego entre servidores através de uma rede privada ou VPC normalmente não é contabilizado. Por isso, colocar a base de dados na interface privada é uma decisão de faturação, além de ser uma decisão de segurança.

Nada disto importa se estiver longe do limite. Um blog, uma API com respostas JSON ou um SaaS pequeno não atingem 1 TB num mês. Vídeo, galerias de imagens, servidores de jogos, mirrors de pacotes e destinos de cópias de segurança externas atingem. Meça antes de assumir:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m mostra a transferência por mês, separada entre recebida e transmitida. Apenas a coluna transmitida é faturada. A base de dados começa vazia, portanto a primeira leitura útil fica disponível um dia depois da instalação, e o primeiro mês completo fica disponível um mês mais tarde. Até lá, o gráfico de largura de banda do próprio fornecedor é o único registo disponível.

Faça mais uma pergunta que nenhuma lista de preços responde: quando ultrapassa o limite, o fornecedor cobra ou limita a porta. A cobrança custa dinheiro. A limitação prejudica os utilizadores, exatamente no momento em que tem mais utilizadores. É importante saber qual das duas opções uma subida repentina do tráfego provoca.

NVMe ou SATA, e como confirmar o que realmente recebeu

O painel indica NVMe. Isso é uma afirmação sobre os discos do host, mas a sua máquina virtual pode não estar alojada nesses discos. O armazenamento local coloca o seu disco virtual em unidades dentro da mesma máquina física. O armazenamento de rede coloca-o num cluster de armazenamento separado, acedido através da rede do datacenter. É isso que permite redimensionamento imediato, migração em tempo real e snapshots no próprio local.

Dentro do guest, ambos parecem idênticos:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA e rotational reportam 0 para tudo o que o host declara como não rotacional. Por isso, um volume de rede suportado por NVMe apresenta exatamente o mesmo resultado que um NVMe local. O valor indica que o disco não usa pratos magnéticos giratórios. Não indica onde o disco está localizado. Confirmar um disco NVMe no Linux explica os nomes dos dispositivos e o que cada um implica.

O teste que os distingue mede a latência com profundidade de fila 1, porque uma leitura pequena e isolada não tem outras operações atrás das quais se possa ocultar. O NVMe local responde a partir do mesmo chassis. Um volume de rede acrescenta uma viagem de ida e volta pela rede do datacenter a cada leitura. Por isso, a sua latência mínima é maior, mesmo quando o débito com uma profundidade de fila elevada parece semelhante.

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

A primeira execução apresenta um bloco clat, que mostra a latência de conclusão. Leia a linha do percentil 99 em vez da média, porque a média oculta as paragens que os utilizadores sentem. A segunda execução apresenta IOPS= na linha de resumo. Execute ambos no fornecedor que já utiliza e numa instância de avaliação do fornecedor que está a considerar, no mesmo dia, e compare os seus próprios dois valores. Um valor publicado por qualquer fornecedor foi medido numa máquina que não pode observar. Execute os testes três vezes, também em horários diferentes, porque um host pouco ocupado e um host congestionado produzem resultados diferentes no mesmo plano. Avaliar corretamente um VPS explica o método, e o que significa realmente um VPS com SSD explica os termos de marketing subjacentes.

Regiões: meça a latência, não leia o mapa

Uma lista de regiões é marketing até ser medida. O que o utilizador sente é o tempo de ida e volta entre a sua rede e o servidor. Isso depende da rota seguida pelos pacotes, não da distância no mapa. Um servidor a 300 km, atrás de uma ligação de trânsito congestionada, perde para outro a 1,500 km por um caminho livre.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr mostra cada salto com a respetiva perda e latência. Assim, um aumento de 60 ms entre dois saltos identifica a ligação que está a causar o problema, em vez de culpar o destino. Execute-o numa máquina da rede onde estão os seus utilizadores. As rotas entre centros de dados são as melhores rotas da Internet e favorecem igualmente todos os fornecedores.

Há um ponto estrutural que se mantém independentemente das alterações de preço. Um fornecedor com uma única região no seu continente significa que o seu plano de recuperação de desastre consiste em mudar de continente, com a latência daí resultante. Conte as regiões para as quais faria efetivamente failover, não as regiões apresentadas na página.

Snapshots e backups são cobrados à parte

Os complementos de armazenamento são onde um plano barato fica caro. A DigitalOcean cobra $0.06 por GiB por mês pelos snapshots e define o preço dos backups automáticos como uma percentagem do servidor: 20% do preço do plano para backups semanais e 30% para backups diários, com uma opção baseada no uso, cobrada por GiB. Ambos os modelos são defensáveis e falham em sentidos opostos. Um preço percentual acompanha o tamanho do servidor, por isso um servidor grande com um conjunto de dados pequeno paga demasiado. Um preço por GiB acompanha os dados, por isso um servidor pequeno ligado a um volume grande paga demasiado.

Pergunte quanto custa uma restauração e quanto tempo demora, porque o preço de manter um backup é apenas metade menos interessante da questão. Pergunte se destruir o servidor também destrói os respetivos snapshots.

Depois, mantenha uma cópia que o fornecedor não controle. Os snapshots do fornecedor ficam dentro da conta do fornecedor, por isso uma conta perdida, uma falha no pagamento ou uma conta suspensa afeta o servidor e os respetivos backups no mesmo momento. Os backups do restic num armazenamento que controla custam alguns dólares de object storage, podem ser restaurados em qualquer fornecedor e são o que torna uma migração reversível em vez de definitiva.

Quanto da pilha você quer executar

Os provedores estão distribuídos ao longo de um espectro. Num extremo, você aluga uma máquina e executa tudo por conta própria. No outro, você envia um branch do git e nunca vê um servidor. Comparar o preço por GB de RAM só é adequado no primeiro extremo, porque no segundo você está a comprar trabalho, não memória, e o trabalho não tem um preço por GB.

Seja honesto sobre em que extremo está antes de comparar opções. Uma base de dados gerida a $15.15 por mês parece cara ao lado de um servidor de $6, até calcular o custo das horas envolvidas: replicação, failover, restauro para um ponto no tempo, atualizações de versões menores e o alerta que acorda alguém às 03:00. Se esse trabalho é sua responsabilidade, execute-o por conta própria e fique com a diferença. Se sua responsabilidade é a aplicação, comprar esse trabalho de volta é barato. A divisão entre serviços geridos e não geridos determina qual coluna da tabela de preços você deveria sequer consultar. Se a resposta honesta é que você quer a máquina inteira e os respetivos discos só para você, essa é uma questão de VPS versus servidor dedicado, não uma questão sobre o provedor. A mesma questão aparece no restante da fatura mensal de um developer, em que comparar os planos do Claude e do ChatGPT depende de quanto trabalho você quer delegar, e não do preço anunciado.

Onde o DigitalOcean é a escolha certa

O DigitalOcean é vantajoso quando está a comprar a plataforma, e não a máquina virtual.

• Bases de dados geridas. PostgreSQL e MySQL geridos começam nos $15.15 por mês, com 1 GiB de RAM e 10 GiB de armazenamento. O armazenamento adicional é faturado por GiB e os nós standby são cobrados por nó. Criar a mesma fiabilidade por conta própria exige Patroni ou repmgr, um sistema de consenso, um proxy de ligações e um teste de failover que tenha sido realmente ensaiado. Uma equipa de duas pessoas não consegue manter tudo isso e continuar a lançar funcionalidades.
• App Platform. Envie uma branch, obtenha uma compilação, um certificado e um serviço em execução, sem sistema operativo para corrigir. A versão VPS barata deste produto é você, num sábado.
• Armazenamento de objetos e balanceadores de carga abrangidos por um provider Terraform maduro. Uma infraestrutura que pode destruir e reconstruir a partir de código vale mais do que um preço unitário inferior.
• A empresa por trás do produto. Níveis de suporte publicados, uma página de estado com histórico e uma organização que responde ao questionário de segurança de um cliente. Se revende alojamento, isso vale mais do que alguns dólares por GB.

O DigitalOcean fica caro quando se trata de uma máquina virtual simples, em quantidade, com tráfego de saída real. Esse é precisamente o caso que uma alternativa resolve, e representa a maior parte do que um developer de self-hosting compra.

Migrar para um novo provedor sem indisponibilidade

A indisponibilidade durante uma migração ocorre por um único motivo: o tráfego chega ao IP antigo depois de os dados terem sido transferidos para o novo. Cada etapa abaixo existe para tornar essa janela curta e previsível.

Comece pelo DNS, pelo menos 48 horas antes da mudança. Os resolvers armazenam o seu registo A em cache durante o TTL (time to live) definido. Por isso, um registo com TTL de 24 horas pode continuar a enviar utilizadores para o servidor antigo durante até um dia depois de o alterar. Reduzir o TTL no momento da mudança não ajuda, porque os resolvers já têm o valor antigo armazenado com o prazo de expiração antigo. Reduza-o primeiro, aguarde a expiração do valor antigo e só depois faça a migração.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

O primeiro comando mostra o TTL atual na segunda coluna da resposta. Defina-o como 300 no seu provedor de DNS e aguarde mais tempo do que o valor que acabou de substituir.

Depois, siga esta ordem.

1. Provisione o novo servidor e aplique o hardening antes de colocar qualquer outra coisa nele. Os primeiros dez minutos num novo VPS explica a parte que muitas pessoas ignoram quando estão com pressa.
2. Instale a stack da aplicação e faça uma primeira cópia dos dados com rsync enquanto o servidor antigo continua a servir normalmente.
3. Emita já o certificado TLS no novo host, usando um desafio DNS-01, porque um desafio HTTP-01 valida contra o IP para o qual o DNS aponta atualmente, que ainda é o servidor antigo. Um desafio DNS-01 elimina completamente esse problema de ordem.
4. Teste o novo host antes de qualquer alteração pública, substituindo o DNS no seu próprio portátil. Adicione 203.0.113.20 example.com a /etc/hosts, aceda ao site real e depois remova a linha. Nenhum utilizador é afetado por este teste.
5. Avalie o tamanho da base de dados. Para volumes inferiores a alguns GB, um dump e um restore cabem no período de congelamento das escritas. Acima disso, configure a replicação da base de dados antiga para a nova com vários dias de antecedência e deixe-a acompanhar, para que o congelamento cubra apenas a promoção.
6. Congele as escritas. Coloque a aplicação em modo de manutenção ou somente leitura. Esta é a única parte visível para os utilizadores e deve durar apenas alguns minutos.
7. Faça a diferença final: execute novamente o mesmo rsync e depois a sincronização final da base de dados.
8. Altere os registos A e AAAA para o novo IP. Com um TTL de 300 segundos, a maioria dos resolvers seguirá a alteração em cerca de cinco minutos.
9. Mantenha o servidor antigo em execução e acessível durante pelo menos um dia, porque alguns resolvers ignoram TTLs curtos. Se a aplicação antiga ainda aceitar escritas, os pedidos que chegarem atrasados gravarão dados na base de dados errada. Por isso, aponte o host antigo para a nova base de dados ou devolva uma página de manutenção a partir dele.
10. Monitorize a taxa de erros do novo servidor durante um dia, volte a aumentar o TTL para o valor normal e destrua o servidor antigo depois de uma semana, não na mesma noite.

A cópia propriamente dita é feita com dois comandos, executados duas vezes cada. A sincronização dos ficheiros:

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a preserva o proprietário, as permissões e os timestamps, -H mantém os hard links, -AX mantém as ACLs e os atributos estendidos, e --numeric-ids impede o rsync de remapear IDs de utilizador através de nomes que diferem entre duas máquinas. Execute-o com vários dias de antecedência e depois novamente durante o congelamento. Na segunda execução, apenas os dados alterados serão transferidos.

Para PostgreSQL com um tamanho suficientemente pequeno para usar um dump:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

Para MySQL ou MariaDB:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction cria o dump dentro de uma única transação nas tabelas InnoDB, pelo que o resultado é consistente e a aplicação continua a aceitar escritas durante a execução. Sem essa flag, mysqldump bloqueia as tabelas. Isso significa que o congelamento das escritas começa mais cedo do que o planeado e deixa de ser uma decisão sua.

Há duas coisas que podem falhar fora dos seus servidores. Um novo endereço IP não tem reputação de email, pelo que as mensagens enviadas diretamente a partir do novo servidor podem ser filtradas como spam. Envie-as através de um relay que já tenha reputação. Além disso, qualquer parceiro que tenha o seu IP de saída numa allowlist, como um gateway de pagamentos ou uma firewall de cliente, tem de ser atualizado antes da mudança. Caso contrário, essas chamadas começarão a falhar assim que o tráfego for transferido.

O que verificar antes de avançar

• Se o preço é promocional e qual será o preço na renovação. Um desconto no primeiro período que duplica na renovação representa um custo real, apenas adiado.
• Se o período é pré-pago. Os planos pré-pagos de vários anos, que é o modelo usado pela SSD Nodes, permitem obter um preço muito mais baixo por GB de RAM mediante pagamento antecipado. A contrapartida é não poder cancelar no mês seguinte. Escolha o período de acordo com o seu grau de certeza.
• Quanto custa um snapshot por mês e quanto custa uma restauração, tanto em dinheiro como em minutos.
• Se o excesso de utilização é faturado ou limitado.
• Se o IPv6 é encaminhado corretamente ou se consiste apenas num endereço adicionado sem integração adequada.
• Se existe uma API com um provider Terraform mantido, caso pretenda reconstruir a infraestrutura a partir de código em vez de o fazer manualmente.
• Como contactar o suporte e qual é o prazo de resposta publicado para um servidor indisponível, e não para uma questão comercial.

Escolha com base no critério que mais pesa na sua própria fatura. Se esse critério for a memória, o preço por GB de RAM é decisivo. Se for o tráfego de saída, é o volume de transferência incluído. Se for o seu próprio tempo, a plataforma gerida é decisiva, e a da DigitalOcean é a mais forte das quatro comparadas aqui.

FAQ

O Hetzner é sempre mais barato do que o DigitalOcean?

Para uma máquina virtual simples, o custo por GB de RAM é muito mais baixo: cerca de $1.62 contra $6.00 nos planos partilhados de entrada em 5 August 2026. A comparação muda quando entram serviços geridos. A Hetzner vende servidores e rede, por isso uma base de dados gerida ou uma plataforma push-to-deploy tem de ser fornecida por si ou por terceiros, e essas horas têm um custo. A Hetzner também aumentou os preços da cloud durante 2026, por isso confirme o valor atual em euros em vez de confiar num artigo antigo.

Que alternativa ao DigitalOcean devo escolher se precisar de uma base de dados gerida?

A Vultr e a Akamai vendem bases de dados geridas, por isso são os substitutos mais próximos se a base de dados gerida for a razão principal para usar o DigitalOcean. Os hosts europeus de baixo custo geralmente não vendem esse serviço, o que significa executar PostgreSQL ou MySQL por sua conta, incluindo a replicação e um failover testado. Isso exige trabalho real. Compare esse custo com os $15.15 por mês de uma instância gerida de 1 GiB antes de concluir que o servidor mais barato lhe permitiu poupar.

Como posso mover um site ativo para um novo fornecedor sem indisponibilidade?

Reduza o TTL do DNS para 300 segundos pelo menos 48 horas antes da mudança, porque os resolvers continuam a fornecer o IP antigo durante o período indicado pelo TTL anterior. Prepare e teste o novo host enquanto o antigo continua a servir tráfego, usando uma substituição /etc/hosts na sua própria máquina para que mais ninguém a veja. Depois, bloqueie as escritas durante alguns minutos, execute o delta final do rsync e a sincronização final da base de dados, altere os registos A e AAAA e mantenha o servidor antigo em execução durante uma semana, caso algum resolver ignore o TTL reduzido.

Um VPS mais barato significa discos mais lentos?

Não necessariamente. O que importa é saber se o disco virtual está local no host ou num cluster de armazenamento de rede, e o painel raramente informa isso. lsblk -o NAME,ROTA apresenta 0 para ambos, porque os dois não têm componentes rotativos. Em vez disso, faça uma medição: execute fio com --iodepth=1 --bs=4k --direct=1 e leia a latência de conclusão do percentil 99. Um volume de rede acrescenta uma ida e volta pela rede do datacenter a cada leitura, por isso o limite inferior da latência é superior ao de um NVMe local, mesmo quando o débito com filas profundas parece semelhante.

O meu email continuará a ser entregue a partir do novo servidor?

Muitas vezes, não no início. Um endereço IP novo não tem histórico de envio, por isso os destinatários tratam as mensagens provenientes dele como suspeitas, e elas acabam na pasta de spam ou são rejeitadas imediatamente. Os registos SPF e DKIM também apontam para o host antigo até serem atualizados. Envie o email da aplicação através de um relay ou de um serviço de email que já tenha reputação, e atualize os registos DNS do email antes da mudança, não depois.