DigitalOcean na prática: conta, doctl e IaC básico

A primeira vez que rodei o doctl (a CLI da DigitalOcean) tive a sensação estranha de já ter feito aquilo antes. Não tinha, mas quem já mexeu com aws-cli reconhece o padrão rápido: autentica, lista recursos, cria, destrói. Uso minha conta na DigitalOcean há um tempo, comecei em testes pontuais e depois usei bastante em imersões de AIOps, e o que mais me chamou atenção nunca foi um recurso específico. Foi a simplicidade e o cuidado com a interface do painel.

Resumo direto pra quem tem pressa: a DigitalOcean é uma cloud pequena, com um catálogo enxuto de compute e storage, preço fechado por droplet (o nome dela pro servidor virtual) e uma CLI simples para automatizar o que você faria no painel. Ela não compete em variedade com AWS, GCP ou Azure. Compete em simplicidade, e para quem está começando em DevOps isso é uma vantagem, não um defeito.

O que a DigitalOcean entrega (e por que funciona bem pra quem está começando)

O núcleo da DigitalOcean é pequeno de propósito: Droplets (máquinas virtuais), volumes de bloco, Spaces (object storage compatível com S3), banco de dados gerenciado, load balancer e um Kubernetes gerenciado (DOKS). Isso é tudo. Não tem 200 serviços disputando espaço no menu.

Pra quem está aprendendo, isso reduz uma fricção que a AWS tem em excesso: a quantidade de decisões que você precisa tomar antes de simplesmente começar. Quando você quer só subir uma VM e testar algo, a AWS te oferece EC2 com uma dezena de famílias de instância, tipos de storage, opções de rede e um console que parece painel de avião. Na DigitalOcean você escolhe tamanho de droplet, região e imagem, e em menos de um minuto tem uma máquina rodando. Isso não faz da DigitalOcean uma cloud “melhor”. Faz dela um lugar melhor pra errar rápido enquanto você aprende o que realmente importa: automatizar, versionar e destruir o que você cria.

DigitalOcean x AWS: um comparativo de custo simples

Comparação justa de cloud é chata de fazer porque as duas raramente vendem o mesmo pacote. Fiz o comparativo mais simples possível, olhando o menor droplet da DigitalOcean contra a instância EC2 mais próxima em RAM.

O resultado não é “DigitalOcean é sempre mais barata”, porque qualquer comparação de cloud depende de região, tráfego, reserva, desconto e arquitetura. Para esse laboratório pequeno, porém, a conta ficou bem menos empatada depois de incluir o IPv4 público da AWS. A diferença real é que a DigitalOcean embute storage, IP e uma faixa generosa de transferência no preço fechado, enquanto a AWS cobra cada parte separado. Isso importa menos pelo valor absoluto e mais pela previsibilidade: com DigitalOcean você sabe o teto da fatura antes de rodar qualquer coisa. Com AWS, precisa montar a conta inteira.

Criando a conta e gerando o token de API

Se você ainda não tem conta, dá para criar a conta na DigitalOcean antes de seguir. É o mesmo link de indicação que citei no começo do post.

Pra usar doctl ou qualquer ferramenta de IaC, o primeiro passo depois de criar a conta é gerar um token de API (Personal Access Token), em API > Tokens/Keys no painel. Guarde esse token como faria com qualquer credencial: nunca direto no código, sempre em variável de ambiente ou arquivo .env fora do versionamento via Git ou semelhantes.

Instalando e configurando o doctl

No Ubuntu/WSL2, o caminho mais simples é via snap:

sudo snap install doctl

Sem snap disponível, dá pra baixar o binário direto do repositório oficial no GitHub e colocar em ~/.local/bin.

Para outros Sistemas Operacionais é possível obter os comandos na página:

https://github.com/digitalocean/doctl

Com o token em mãos, autentica:

doctl auth init

Ele pede o token, valida e salva um contexto local. Dá pra confirmar que funcionou:

doctl account get

User Email                Team       Droplet Limit    Email Verified    Status
voce@exemplo.com          My Team    3                true              active

No dia a dia, o comando que eu mais uso, de longe, é este:

doctl compute droplet list

Simples assim: lista o que está rodando, com IP, região e status. Antes de qualquer automação mais elaborada, esse é o comando que eu rodo pra saber se o que eu acho que existe realmente existe.

Uma coisa que descobri rodando doctl compute region list ao vivo pra este post, e que vale registrar pra quem está no Brasil: a DigitalOcean não tem região na América do Sul. As mais próximas são Nova York e Toronto. Pra estudo, doctl e IaC básico isso não muda nada. Pra uma aplicação real com usuário no Brasil, a latência entra na conta.

IaC básico na DigitalOcean com Terraform

Com o token pronto, o Terraform entra pra descrever o droplet em vez de clicar no painel. A estrutura mínima:

terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

variable "do_token" {
  type      = string
  sensitive = true
}

provider "digitalocean" {
  token = var.do_token
}

resource "digitalocean_droplet" "demo" {
  name   = "devopsmind-doctl-demo"
  region = "nyc1"
  size   = "s-1vcpu-512mb-10gb"
  image  = "ubuntu-26-04-x64"
  tags   = ["devopsmind-demo"]
}

output "droplet_ip" {
  value = digitalocean_droplet.demo.ipv4_address
}

O token nunca vai direto no arquivo. Passo por variável de ambiente:

export TF_VAR_do_token="seu-token-aqui"
terraform init
terraform plan

O comando terraform plan mostra exatamente o que vai ser criado antes de qualquer coisa existir de verdade:

Depois do terraform apply, o droplet é criado em segundos:

E verificando na console da DigitalOcean:

E acessando o Droplet, temos maiores detalhes sobre ele:

E fecha o ciclo com o comando terraform destroy.

Esse passo é o que separa IaC de “cliquei e esqueci”: se você criou por código, destrua por código, e não deixa nenhum recurso órfão gerando fatura sem uso.

Revisando se ficou alguma sujeira:

Se você já usa Terraform com AWS via assume role ou pra subir cluster EKS via Blueprint, a lógica aqui é idêntica: provider, variável sensível, plan antes de apply, e nunca segredo hardcoded no .tf. Se ainda está começando pela base de containers, o caminho natural é parecido com o que mostrei em Docker no pipeline: automatizar primeiro o básico, depois subir a complexidade. Muda o provider, não muda o hábito.

Onde a DigitalOcean patina (limitações reais)

A limitação mais real que sinto na DigitalOcean é o catálogo de serviços: ela é boa no básico e para por aí. Não tem o equivalente a dezenas de serviços gerenciados que a AWS oferece, não tem a mesma cobertura de regiões (como vimos, nem América do Sul ela tem), e integrações com ferramentas enterprise são mais raras.

Se o seu caso de uso exige compliance específico, presença de região local, ou um serviço gerenciado de nicho que só a AWS, GCP ou Azure oferecem, a DigitalOcean não é a resposta. Ela também não é pensada pra quem já opera em escala com dezenas de contas e políticas de billing corporativas.

Pra estudo, side project, provas de conceito e ambientes pequenos/médios, essa limitação vira vantagem: menos opção para se perder.

Minha leitura

No começo da carreira eu achava que precisava focar em uma cloud específica, AWS, GCP ou Azure, e que escolher errado ia me atrasar. Depois de rodar doctl do mesmo jeito que rodo aws-cli, rodar Terraform e entender que um Droplet e uma EC2 são tudo a mesma coisa no final das contas, entendi que isso é balela.

O que importa no dia a dia é saber fazer o trabalho: subir infraestrutura por código, versionar, automatizar, destruir o que não usa mais. O provider muda o nome dos comandos. Não muda o raciocínio.

A DigitalOcean não vai substituir AWS no seu currículo, e não é essa a proposta. Mas como primeiro lugar pra treinar IaC, entender o racional, CLI de cloud e o hábito de nunca clicar no console quando dá pra escrever código, ela cumpre bem o papel, com uma vantagem extra: o erro custa centavos, não uma dor de cabeça com fatura de quatro dígitos.