Alternativas à DigitalOcean: preço, tráfego 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, recebe 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 apresentado 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 acima desse limite, a composição real do disco e quanto da pilha acima do sistema operativo outra entidade 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, analise 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 se comprometer.

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 provedor, 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 provedor não dá desconto, por isso o tamanho do plano não é o critério de decisão. O provedor é.

Akamai, que agora vende o que antes era a Linode, cobra $12 e $24 pelos planos partilhados de 2 GB e 4 GB, exatamente os mesmos valores da DigitalOcean. O seu plano de entrada custa $5.00. Duas empresas praticarem exatamente o mesmo preço é um sinal importante: esse nível foi definido em função de um concorrente, não do hardware, e continuará a acompanhar esse concorrente.

A diferença aparece nos provedores que constroem os seus próprios datacenters e vendem em euros. Um Hetzner CX23 fornece 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 artigos de comparação 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 clientes. A verificação correta deve ser feita numa máquina que tenha realmente alugado:

vmstat 1 10

Leia a coluna st. Ela contabiliza a percentagem de tempo em que o seu vCPU estava pronto para executar, mas o hypervisor entregou o core físico a outro cliente. Alguns pontos percentuais sob carga são normais. Um valor de dois dígitos mantido durante algum tempo significa que o host está sobrecarregado, e nenhum preço por GB compensa um core que não pode utilizar. Execute o teste no seu horário de maior atividade, porque o steal time é um problema causado por vizinhos, e os vizinhos têm horários. Para uma visão mais ampla do custo mensal real de um serviço de hosting depois de incluir armazenamento e tráfego, leia quanto custa um VPS mês a mês.

O custo efetivo do tráfego incluído

[
  {
    "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 tráfego de saída no plano de entrada e cobra o excedente por GiB, o que corresponde a cerca de $10.00 por 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 desse limite, uma diferença de uma ordem de grandeza em relação às restantes.

Três detalhes estruturais são mais importantes do que os valores principais. O tráfego de entrada é gratuito nos quatro fornecedores, por isso só é contabilizado o que enviar para fora. A DigitalOcean e a Vultr acumulam o limite entre todos os servidores da conta, por isso uma máquina ocupada consome a quota de outra máquina e uma frota de servidores pequenos partilha um único limite grande. Além disso, 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 e também de segurança.

Nada disso importa se estiver longe do limite. Um blogue, uma API com respostas JSON ou um SaaS pequeno não atingirá 1 TB num mês. Vídeo, galerias de imagens, servidores de jogos, mirrors de pacotes e destinos de backup externos atingirão. Meça antes de assumir:

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

vnstat -m apresenta o tráfego por mês, separado entre recebido e transmitido. Apenas a coluna transmitido é cobrada. A base de dados começa vazia, por isso a primeira leitura útil surge um dia depois da instalação, e o primeiro mês completo surge 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 pelo excedente ou limita a porta. A cobrança custa dinheiro. A limitação prejudica os utilizadores, precisamente no momento em que tem mais utilizadores. É importante saber qual das duas situações uma subida repentina do tráfego provoca.

NVMe ou SATA, e como confirmar o que recebeu

O painel indica NVMe. Isso é uma afirmação sobre os discos no host, mas a sua máquina virtual pode não estar alojada nesses discos. O armazenamento local coloca o 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 instantâneo, migração em tempo real e criação de snapshots no 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 qualquer dispositivo que o host declare como não rotacional. Por isso, um volume de rede suportado por NVMe apresenta exatamente o mesmo resultado que o NVMe local. O valor indica que o disco não usa pratos rotativos. Não indica onde o disco está localizado. Como confirmar um disco NVMe no Linux explica os nomes dos dispositivos e o que cada um significa.

O teste que os distingue mede a latência com profundidade de fila 1, porque uma leitura pequena e única 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 ida e volta através da rede do datacenter a cada leitura. Por isso, a sua latência mínima é superior, mesmo quando o débito com uma fila profunda 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 sentidas pelos utilizadores. A segunda execução apresenta IOPS= na linha de resumo. Execute ambos no fornecedor que utiliza e numa instância de teste 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 também o teste três vezes, em horas diferentes, porque um host pouco ocupado e um host muito ocupado produzem resultados diferentes no mesmo plano. Como fazer corretamente o benchmark de uma VPS explica o método, e o que significa realmente uma VPS 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 um utilizador sente é o tempo de ida e volta entre a sua rede e o servidor, e isso depende da rota que os pacotes percorrem, 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, numa rota sem congestionamento.

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 a partir de uma máquina na rede utilizada pelos seus utilizadores. As rotas entre centros de dados são as melhores rotas da Internet e favorecem igualmente todos os fornecedores.

Um ponto estrutural mantém-se, 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 correspondente. Conte as regiões para as quais faria efetivamente failover, não as regiões apresentadas na página.

Snapshots e backups têm custos separados

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, além de uma opção baseada na utilização, cobrada por GiB. Ambos os modelos são defensáveis, mas 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 mais do que deveria. Um preço por GiB acompanha os seus dados, por isso um servidor pequeno associado a um volume grande paga mais do que deveria.

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 inacessível, uma falha de pagamento ou uma conta suspensa afeta o servidor e os respetivos backups no mesmo momento. Os backups do restic para armazenamento que controla custam alguns dólares de object storage, podem ser restaurados em qualquer fornecedor e tornam uma migração reversível em vez de definitiva.

Quanto da pilha você quer executar

Os provedores estão distribuídos ao longo de uma linha. Em uma ponta, você aluga uma máquina e executa tudo nela por conta própria. Na outra, você envia uma branch do git e nunca vê um servidor. Comparar o preço por GB de RAM só faz sentido na primeira ponta, porque, na segunda, você está comprando trabalho, e o trabalho não tem um preço por GB.

Seja honesto sobre em qual ponta você está antes de comparar qualquer coisa. Um banco de dados gerenciado a $15.15 por mês parece caro perto de um servidor de $6, até você calcular as horas envolvidas: replicação, failover, restauração para um ponto no tempo, atualizações de versão secundária e o alerta que acorda alguém às 03:00. Se esse trabalho faz parte da sua função, execute-o por conta própria e fique com a diferença. Se a sua função é cuidar da aplicação, comprar esse serviço de volta sai barato. A divisão entre serviços gerenciados e não gerenciados determina qual coluna da tabela de preços você deveria consultar. Se a resposta honesta é que você quer a máquina inteira e os discos somente para você, então a questão é VPS versus servidor dedicado, e não uma questão sobre o provedor.

Onde o DigitalOcean é a escolha certa

O DigitalOcean é uma opção mais forte quando se está a pagar pela plataforma, e não pela máquina virtual.

• Bases de dados geridas. PostgreSQL e MySQL geridos começam nos $15.15 por mês para 1 GiB de RAM e 10 GiB de armazenamento. O armazenamento adicional é cobrado por GiB e os nós standby são cobrados por nó. Criar a mesma fiabilidade internamente exige Patroni ou repmgr, um repositório de consenso, um proxy de ligações e um teste de failover que tenha sido efetivamente ensaiado. Uma equipa de duas pessoas não consegue manter isso e continuar a entregar funcionalidades.
• App Platform. Envie um branch, obtenha uma compilação, um certificado e um serviço em execução, sem um sistema operativo para atualizar. A versão VPS barata deste produto é o próprio administrador, num sábado.
• Armazenamento de objetos e load balancers abrangidos por um provider Terraform maduro. Uma infraestrutura que pode ser destruída e recriada 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 responderá 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 e com tráfego de saída real. Esse é precisamente o caso que uma alternativa resolve e corresponde à maior parte do que um developer de self-hosting compra.

Migrar para um novo provedor sem indisponibilidade

A indisponibilidade durante uma migração resulta de uma única causa: o tráfego chega ao IP antigo depois de os dados terem sido transferidos para o novo. Cada passo abaixo existe para tornar esse intervalo curto e previsível.

Comece pelo DNS, pelo menos 48 horas antes da mudança. Os resolvers colocam o seu registo A em cache durante o TTL (time to live), por isso um registo com TTL de 24 horas continua a enviar os 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, associado ao prazo de expiração antigo. Reduza-o primeiro, aguarde que o valor antigo expire e só depois faça a migração.

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

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

Depois, siga esta ordem.

1. Provisione o novo servidor e aplique o hardening antes de instalar qualquer outra coisa. Os primeiros dez minutos num novo VPS aborda a parte que muitas pessoas ignoram quando têm 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 ordenação.
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 remova a linha depois. Nenhum utilizador é afetado por este teste.
5. Avalie o tamanho da base de dados. Para alguns GB, um dump e um restore cabem dentro do bloqueio de escrita. 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 as alterações, para que o bloqueio cubra apenas a promoção.
6. Bloqueie as escritas. Coloque a aplicação em modo de manutenção ou apenas de leitura. Esta é a única parte que os utilizadores podem ver e deve durar apenas alguns minutos.
7. Transfira o delta final: execute novamente o mesmo rsync e depois faça 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 acompanha 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 tardios escreverão na base de dados errada. Nesse caso, aponte o host antigo para a nova base de dados ou apresente uma página de manutenção nesse host.
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 após uma semana, não na mesma noite.

A cópia consiste em 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 as hard links, -AX mantém as ACLs e os atributos estendidos e --numeric-ids impede que o rsync remapeie os IDs de utilizador através de nomes diferentes entre as duas máquinas. Execute-o com vários dias de antecedência e depois novamente durante o bloqueio, quando apenas serão transferidas as alterações.

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, por isso 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 bloqueio de escrita começa mais cedo do que planeou e deixa de ser você a escolher quando isso acontece.

Há duas coisas que falham fora dos seus servidores. Um novo endereço IP não tem reputação de email, por isso as mensagens enviadas diretamente a partir do novo host são 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 a firewall de um cliente, deve ser atualizado antes da mudança. Caso contrário, essas chamadas começam a falhar assim que o tráfego é transferido.

O que verificar antes de contratar

• 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 é 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 próximo mês, por isso 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, em dinheiro e em minutos.
• Se o excesso de utilização é cobrado ou limitado.
• Se o IPv6 é encaminhado corretamente ou se é apenas um endereço isolado adicionado à configuração.
• 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, em vez de para uma questão comercial.

Escolha o 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 decide. Se for o tráfego de saída, decide a transferência incluída. Se for o seu próprio tempo, a plataforma gerida decide, 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 preço 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. O Hetzner vende servidores e rede, por isso uma base de dados gerida ou uma plataforma de implementação automática tem de ser fornecida por si ou por terceiros, e essas horas têm um custo. O 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 o motivo pelo qual usa o DigitalOcean. Os fornecedores europeus de baixo custo geralmente não vendem esse serviço. Isso significa gerir PostgreSQL ou MySQL por conta própria, incluindo a replicação e um failover testado. Esse trabalho é significativo. Compare o 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 movo um site ativo para um novo fornecedor sem indisponibilidade?

Reduza o TTL do DNS para 300 segundos pelo menos 48 horas antes da migração, 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 um override /etc/hosts na sua própria máquina para que mais ninguém o 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 é local ao host ou se está num cluster de armazenamento de rede, algo que o painel raramente indica. O lsblk -o NAME,ROTA apresenta 0 para ambos, porque os dois não têm discos rotativos. Em vez disso, faça medições: execute fio com --iodepth=1 --bs=4k --direct=1 e leia a latência de conclusão no percentil 99. Um volume de rede acrescenta uma ida e volta à 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 consideram suspeitas as mensagens provenientes dele, que podem ser colocadas em spam ou rejeitadas diretamente. Os registos SPF e DKIM também continuam a apontar 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 migração, não depois.