Boas práticas para executar aplicações em produção na DigitalOcean com segurança, disponibilidade, observabilidade e controle de custos.

Uma aplicação começa pequena: um Droplet, um deploy manual, um domínio apontando para o IP público e a sensação boa de “está no ar”. Algumas semanas depois, entram usuários reais, alguém muda uma configuração direto no servidor, o disco começa a encher, uma chave SSH antiga continua válida e ninguém sabe se o backup cobre os dados importantes.

Esse é o ponto em que produção na DigitalOcean com Droplets deixa de ser apenas “criar uma máquina” e passa a ser operação contínua. Colocar um Droplet no ar é apenas o começo: acessos, exposição de rede, atualização, recuperação, monitoramento e custos precisam virar rotina.

Este guia é para quem já consegue criar um Droplet, mas quer revisar uma infraestrutura existente com mais segurança, previsibilidade e controle. O foco está em aplicações hospedadas em Droplets. Não vamos aprofundar DigitalOcean Kubernetes, multi-cloud, migração entre provedores ou configuração completa de frameworks específicos.

Também vale alinhar uma expectativa importante: um único Droplet pode ser bem protegido, monitorado e recuperável. No entanto, ele continua sendo um ponto único de falha. Backup ajuda a recuperar; firewall reduz exposição; monitoramento antecipa problemas. Alta disponibilidade exige decisões arquiteturais adicionais.

TL;DR

• Criar um Droplet é simples; operar produção exige rotina.
• A simplicidade da DigitalOcean é uma vantagem importante, mas não deve ser confundida com ausência de responsabilidade.
• A DigitalOcean cuida da infraestrutura física e dos serviços contratados; sistema operacional, acessos, rede, dados, atualizações e aplicação continuam sob responsabilidade da equipe.
• Comece pelo básico que reduz risco: chaves SSH individuais, usuário não-root, menor privilégio, firewall restritivo, backups testados e monitoramento.
• Backups e snapshots têm finalidades diferentes: backup é parte da recuperação recorrente; snapshot é uma captura pontual de estado.
• Monitore CPU, memória, disco e rede, mas complemente isso com logs e métricas da aplicação.
• Organize recursos com nomes, tags e projetos para evitar custos esquecidos e dependências invisíveis.
• Automatize gradualmente: scripts simples, versionados e revisáveis já são melhores do que depender da memória de uma pessoa.
• Use o checklist no final como ponto de partida, não como certificado de maturidade.

Produção na DigitalOcean com Droplets: o que muda depois do primeiro deploy

Imagine uma aplicação interna em um único Droplet: backend, banco local, arquivos enviados por usuários e deploy manual via SSH. No início, isso pode ser suficiente para validar a ideia. Porém, quando a aplicação vira parte da rotina de outras pessoas, alguns riscos deixam de ser “detalhes técnicos” e passam a afetar o serviço.

A principal mudança é mental: produção não é um estado, é uma prática contínua.

A DigitalOcean simplifica a criação de infraestrutura, mas isso não elimina o modelo de responsabilidade compartilhada. Em termos práticos:

• A DigitalOcean opera a infraestrutura física e os serviços contratados.
• A equipe usuária continua responsável por sistema operacional, acessos, regras de rede, atualizações, dados, monitoramento e configuração da aplicação.

A documentação da DigitalOcean sobre configuração recomendada de Droplets reforça práticas iniciais como acesso seguro, firewall e usuários não-root. Use essa documentação como referência operacional, não apenas como checklist de criação.

O erro comum é assumir que um Droplet recém-criado já está “pronto para produção”. Ele está pronto para receber configuração. A diferença parece pequena, mas é como comprar um apartamento e achar que ele já vem com fechadura reforçada, seguro, cópia de chave controlada e plano de evacuação. Talvez venha com paredes. O resto é com você.

Há um trade-off importante: um único servidor é simples de operar, barato de entender e fácil de depurar. Por outro lado, oferece menor tolerância a falhas. Se o Droplet ficar indisponível, se o disco corromper ou se uma atualização quebrar o serviço, a aplicação inteira pode parar.

Portanto, proteja bem esse Droplet, mas não confunda proteção com alta disponibilidade.

Reduzindo a superfície de ataque: SSH, usuários e atualizações

Acesso administrativo é uma das áreas onde pequenas negligências acumulam risco rapidamente. Se qualquer pessoa usa a mesma chave, se o login por senha está aberto ou se usuários antigos permanecem ativos, a equipe perde rastreabilidade e aumenta a chance de acesso indevido.

Uma revisão prática pode seguir esta ordem:

1. Revisar quem acessa.
2. Remover chaves antigas.
3. Garantir usuários nominais.
4. Evitar login direto como root.
5. Desativar login por senha depois de testar chaves.
6. Definir uma rotina de atualização.

1. Use chaves SSH individuais

Risco: autenticação por senha em SSH amplia a exposição a tentativas automatizadas de login. Senhas compartilhadas ou reutilizadas também tornam difícil saber quem acessou o servidor.

Recomendação: priorize chaves SSH individuais, protegidas localmente, e avalie desativar autenticação por senha. Sempre que possível, evite login direto como root; use usuários nominais com sudo.

Por que importa: chaves individuais permitem revogar o acesso de uma pessoa sem impactar toda a equipe. Usuários nominais melhoram rastreabilidade e reduzem a dependência de credenciais compartilhadas.

Um exemplo mínimo para criar um usuário administrativo nominal:

sudo adduser ana
sudo usermod -aG sudo ana

Depois, adicione a chave pública da pessoa ao arquivo authorized_keys:

sudo mkdir -p /home/ana/.ssh
sudo nano /home/ana/.ssh/authorized_keys
sudo chown -R ana:ana /home/ana/.ssh
sudo chmod 700 /home/ana/.ssh
sudo chmod 600 /home/ana/.ssh/authorized_keys

O nano acima é apenas uma forma simples de editar o arquivo. Em ambientes mais maduros, esse passo deveria ser automatizado e versionado para evitar alterações manuais sem revisão.

2. Desative senha e login direto como root com cuidado

Depois de validar que o usuário consegue acessar e usar sudo, revise a configuração do SSH em /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

Em seguida, reinicie o serviço SSH:

sudo systemctl restart ssh

Antes de fechar a sessão atual, abra uma nova conexão e confirme que o acesso funciona. Essa checagem evita uma situação clássica: configurar segurança tão bem que nem você consegue mais entrar. Segurança estilo “cofre jogado no mar” raramente ajuda.

3. Revise contas e privilégios

Risco: usuários antigos, chaves esquecidas e permissões amplas criam portas laterais. Mesmo que ninguém tenha má intenção, credenciais abandonadas podem vazar ou ser reutilizadas.

Recomendação: remova usuários e chaves que não são mais necessários. Aplique o princípio do menor privilégio: acesso administrativo apenas para quem realmente precisa.

Liste usuários do sistema:

cut -d: -f1 /etc/passwd

Esse comando não decide por você quem deve permanecer. A análise precisa considerar contas de serviço, usuários do sistema operacional e usuários humanos.

Revise também arquivos de chaves autorizadas:

sudo find /home -name authorized_keys -print

Uma rotina simples ajuda: a cada ciclo de manutenção, confirme quem ainda precisa de acesso, quais chaves continuam válidas e quem tem privilégio administrativo.

4. Defina uma cadência de atualizações

Em distribuições baseadas em Debian/Ubuntu, uma atualização manual básica costuma começar com:

sudo apt update
sudo apt upgrade

O trade-off é real:

• Atualizações automáticas reduzem a janela de exposição a vulnerabilidades conhecidas.
• Atualizações planejadas oferecem mais controle e permitem testar antes.
• Adiar indefinidamente atualizações transforma “estabilidade” em dívida operacional.

Para equipes pequenas, uma abordagem intermediária costuma funcionar bem: atualizações de segurança frequentes, janela de manutenção definida e um procedimento de rollback quando possível.

Rede e firewall: permitir apenas o tráfego necessário

Firewall não deve ser tratado como enfeite de painel. Ele é uma regra explícita de exposição: quem pode acessar o quê, por qual porta e a partir de qual origem.

Em produção, a pergunta padrão não deveria ser “por que bloquear?”, mas “por que liberar?”.

1. Revise portas públicas

Risco: portas abertas desnecessariamente expõem serviços internos, painéis administrativos, bancos de dados, filas e interfaces de debug. Muitas vezes isso acontece durante um teste rápido: alguém libera “temporariamente” e esquece.

Recomendação: mantenha públicas apenas as portas necessárias. Para aplicações web, geralmente HTTP e HTTPS precisam estar acessíveis ao público. SSH deve ser restrito a IPs conhecidos, VPN ou bastion host quando a realidade da equipe permitir.

Uma aplicação web simples poderia ter:

• 80/tcp e 443/tcp abertos ao público.
• 22/tcp restrito a IPs administrativos ou a uma rede confiável.
• Banco de dados aceitando conexões apenas da rede privada.
• Painéis administrativos atrás de autenticação adicional ou rede restrita.

A documentação da DigitalOcean sobre configuração recomendada de Droplets também aborda a importância de firewall no setup inicial. Se sua infraestrutura cresceu organicamente, vale comparar o estado atual com essas recomendações.

Se você usa doctl, comece inventariando Droplets e firewalls existentes:

doctl compute droplet list --format ID,Name,PublicIPv4,PrivateIPv4,Tags
doctl compute firewall list

Para inspecionar um firewall específico:

doctl compute firewall get <firewall-id>

Use esses comandos como leitura inicial. A mudança de regras deve ser feita com cuidado, principalmente se você estiver conectado via SSH ao próprio servidor que será restringido.

Um risco comum: liberar todas as portas para “testar rapidinho” e esquecer. O teste passa, a aplicação sobe, o deploy é comemorado, e o firewall vira uma peneira bem documentada — só que por acidente.

2. Use VPC para tráfego interno quando fizer sentido

Risco: componentes internos se comunicando pelo IP público aumentam exposição e dificultam regras de firewall. Bancos, filas e serviços auxiliares podem acabar aceitando tráfego de origens que não deveriam.

Recomendação: use VPC para comunicação entre recursos que não precisam ser acessíveis publicamente, como Droplets, bancos e serviços internos na mesma região quando apropriado.

Valide:

1. Quais recursos precisam conversar entre si.
2. Em qual região eles estão.
3. A qual VPC pertencem.
4. Se a aplicação usa IP privado quando faz sentido.
5. Se as regras de firewall permitem apenas as origens necessárias.

A documentação sobre boas práticas de VPC na DigitalOcean é uma boa referência para revisar esse desenho.

O trade-off: uma rede privada melhora isolamento, mas não substitui autenticação, criptografia adequada ou regras de acesso na aplicação e no banco. VPC não é permissão universal; é apenas um caminho de rede mais controlado.

Recuperabilidade e disponibilidade: backups, restauração e limites de um único Droplet

Quando tudo funciona, backup parece custo. Quando algo falha, backup vira a diferença entre incidente administrável e reconstrução no improviso.

Mas há uma confusão frequente: backup e snapshot não são a mesma coisa.

1. Liste o que precisa ser recuperado

Risco: acreditar que o repositório Git é backup suficiente. Ele protege código, mas não protege banco de dados local, arquivos enviados por usuários, segredos, configurações manuais ou estado do servidor.

Antes de escolher ferramenta, liste:

• Dados persistentes da aplicação.
• Configurações de infraestrutura e deploy.
• Arquivos enviados por usuários.
• Dados de bancos executados no próprio Droplet.
• Segredos e variáveis necessárias para restaurar o serviço, armazenados de forma segura.
• Dependências externas necessárias para a aplicação voltar a funcionar.

Essa lista evita uma armadilha comum: ter backup do servidor, mas esquecer que uma parte crítica dos dados estava em um volume, diretório, bucket, banco local ou configuração manual.

2. Separe backup de snapshot

Recomendação: tenha uma estratégia explícita para recuperar dados persistentes, configuração e aplicação. Use backups gerenciados quando fizer sentido e entenda a finalidade de snapshots.

Backups gerenciados ajudam a reduzir risco de perda após falhas ou erro humano, mas você precisa entender cobertura, retenção e comportamento. Consulte a documentação da DigitalOcean sobre recursos e comportamento de backups antes de depender deles em produção.

Snapshots costumam ser úteis como uma imagem pontual de um estado do Droplet. Por exemplo, antes de uma mudança grande, você pode criar um snapshot para ter uma referência daquele momento. Porém, isso não substitui uma rotina de backup com retenção adequada, especialmente para dados que mudam com frequência.

Uma forma prática de pensar:

• Backup: proteção recorrente para recuperação.
• Snapshot: captura pontual para mudança, migração ou referência de estado.

Ambos podem fazer parte da estratégia, mas atendem a necessidades diferentes.

3. Teste a restauração antes do incidente

Risco: ter backup, mas nunca ter restaurado. Isso cria uma falsa sensação de segurança. Na hora do incidente, a equipe descobre que falta configuração, que o backup não incluía certos arquivos ou que o tempo de recuperação é maior do que o aceitável.

Faça um exercício simples:

1. Escolha um backup recente.
2. Restaure em um ambiente separado.
3. Suba a aplicação sem afetar produção.
4. Verifique se dados, arquivos e configurações essenciais estão presentes.
5. Registre o tempo gasto.
6. Anote passos manuais que deveriam ser automatizados ou documentados.

Duas perguntas ajudam a transformar backup em expectativa de negócio:

• RPO: quantos dados a equipe aceita perder?
• RTO: quanto tempo a equipe aceita ficar fora do ar?

Não precisa transformar isso em uma dissertação acadêmica. Para uma aplicação administrativa interna, talvez perder alguns minutos de dados seja aceitável; para um sistema crítico, talvez não seja. O importante é discutir antes.

O trade-off é direto: backups mais frequentes e retenção maior aumentam a capacidade de recuperação, mas também impactam custos. Por outro lado, economizar eliminando backup pode sair caro exatamente quando a equipe menos tem tempo para improvisar.

E vale repetir: backup melhora recuperação, mas não impede indisponibilidade durante a falha de um único Droplet. Se esse Droplet parar, a aplicação para junto até que algo seja restaurado, substituído ou redirecionado.

Observabilidade operacional: saber que há um problema antes do usuário

Monitoramento não serve apenas para saber se o servidor está “ligado”. Um Droplet pode responder ping e, ainda assim, a aplicação estar lenta, sem espaço em disco ou incapaz de processar tarefas.

Observabilidade prática começa com sinais simples e acionáveis.

1. Monitore sinais úteis

Risco: perceber problemas apenas quando usuários reclamam. Isso aumenta o tempo de resposta e costuma levar a diagnósticos apressados.

Recomendação: monitore CPU, memória, disco e tráfego de rede. Além disso, complemente métricas de infraestrutura com logs e métricas da aplicação.

Um painel mínimo pode acompanhar:

• Uso de CPU.
• Memória disponível.
• Espaço em disco.
• Tráfego de rede.
• Status dos processos principais.
• Logs de aplicação e servidor web.
• Métricas específicas da aplicação, quando existirem.

Um exemplo: disco em crescimento contínuo pode indicar retenção excessiva de logs, falha em rotação ou acúmulo de arquivos temporários. Se ninguém monitora disco, a equipe só descobre quando o banco para de escrever ou o deploy falha.

Comandos locais ajudam em investigações pontuais:

df -h
free -m
top

Eles não substituem monitoramento contínuo, mas ajudam a confirmar hipóteses durante um incidente.

2. Configure alertas acionáveis

Risco: alertas demais viram ruído. Alertas de menos avisam tarde demais. Em ambos os casos, o time se acostuma a operar no escuro.

Recomendação: configure alertas com limiares coerentes, canais acompanhados e uma ação inicial associada.

Para cada alerta, registre:

• O que disparou?
• Quem recebe?
• Qual é a primeira verificação?
• Quando escalar?
• Quando silenciar ou ajustar o limiar?

A documentação da DigitalOcean sobre gerenciamento de alertas de monitoramento pode orientar a configuração de alertas dentro da plataforma.

Exemplos de alerta acionável:

• Disco acima de um limite definido → verificar logs, arquivos temporários e crescimento de uploads.
• CPU alta por período sustentado → identificar processo, revisar tráfego, avaliar regressão recente.
• Memória baixa → investigar processo com consumo anormal, vazamento ou necessidade de ajuste de capacidade.
• Tráfego inesperado → verificar pico real, abuso, crawler agressivo ou configuração incorreta.

O trade-off está nos limiares:

• Limiares muito sensíveis detectam cedo, mas geram ruído.
• Limiares permissivos reduzem ruído, mas podem avisar tarde.
• Limiares sem responsável não são alertas; são mensagens perdidas em um canal.

Para incidentes recorrentes, escreva procedimentos curtos. Um documento de meia página explicando “o que fazer quando o disco enche” já reduz bastante o improviso.

Organização, automação e custos: operar sem depender da memória da equipe

Produção fica frágil quando a infraestrutura só existe na cabeça de uma pessoa. Isso vale para nomes de recursos, portas abertas, scripts de deploy, backups, domínios e custos.

A meta não é burocratizar tudo. É tornar decisões visíveis.

1. Padronize recursos

Risco: Droplets sem nomes claros, tags inconsistentes e projetos misturados dificultam revisão, resposta a incidentes e controle de custos.

Recomendação: adote nomes, tags, projetos e ambientes consistentes. Diferencie produção, homologação e desenvolvimento.

Um padrão simples poderia ser:

• Nome do Droplet: prod-api-agendamentos-01
• Tags: env:prod, system:agendamentos, owner:plataforma
• Projeto: aplicação ou área responsável
• Documentação: domínio, portas abertas, estratégia de backup, responsáveis e procedimento de recuperação

O objetivo é responder rapidamente:

• Este Droplet é de quem?
• Está em produção?
• Pode ser desligado?
• Tem backup?
• Qual sistema depende dele?
• Quem deve ser avisado em caso de incidente?

Tags para ambiente, sistema e centro de custo ajudam a revisar recursos que deveriam ter sido desligados ou removidos. O benefício aparece principalmente em dois momentos: quando chega a cobrança e quando algo quebra.

Além disso, se sua equipe está amadurecendo práticas de engenharia e quer complementar a parte operacional com estudo estruturado, pode valer conhecer o material da Arandu em português como leitura complementar. Use esse tipo de recurso para apoiar formação contínua, não como substituto de revisão prática da sua própria infraestrutura.

2. Automatize o que precisa ser repetível

Risco: deploy, firewall, criação de usuário e configuração de serviço feitos manualmente tendem a variar. Em um incidente, essa variação dificulta reconstruir o ambiente.

Recomendação: versionar infraestrutura e configuração sempre que possível. Comece pequeno: scripts revisáveis e documentados já reduzem bastante o risco.

Identifique tarefas recorrentes:

• Criação de recursos.
• Configuração de firewall.
• Provisionamento inicial.
• Instalação de dependências.
• Deploy.
• Rollback.
• Rotina de backup e restauração.

Você não precisa começar com uma plataforma complexa. Um script curto, versionado e revisado, pode ser o primeiro passo:

#!/usr/bin/env bash
set -euo pipefail

sudo apt update
sudo apt upgrade -y
sudo systemctl restart nginx

Esse exemplo é propositalmente simples. Em produção, você precisaria avaliar janela de manutenção, impacto do restart, testes pós-deploy e rollback. O ponto é: até um script pequeno já deixa explícito o que antes estava espalhado em comandos digitados de memória.

O trade-off também é claro:

• Automatizar exige investimento inicial e manutenção.
• Fazer tudo manualmente parece mais rápido no primeiro dia.
• Porém, quando for necessário reproduzir ou recuperar o ambiente, o manual “na cabeça de alguém” tende a falhar.

Alta disponibilidade, automação mais robusta e serviços gerenciados podem fazer sentido conforme criticidade, custo, RPO, RTO e capacidade operacional da equipe. Eles não precisam ser tratados como obrigação para qualquer projeto, mas também não deveriam ser descartados por inércia.

3. Revise custos com contexto

Risco: custos crescem por recursos esquecidos, capacidade superdimensionada, snapshots antigos, discos anexados e ambientes temporários que viraram permanentes.

Recomendação: revise custos periodicamente como parte da operação, não apenas quando a cobrança assusta.

Uma rotina simples pode verificar:

• Recursos sem uso.
• Ambientes temporários ativos.
• Capacidade superdimensionada.
• Backups mantidos além da necessidade.
• Snapshots antigos.
• Volumes não utilizados.
• Recursos sem tags ou responsável.

Evite cortes que reduzem recuperabilidade ou segurança sem análise de risco. Desligar backup para economizar pode ser uma decisão tecnicamente ruim se a aplicação armazena dados importantes. Da mesma forma, remover monitoramento porque “quase nunca dispara” pode apenas esconder problemas.

Boa revisão de custos não é caça cega a centavos. É entender quais recursos sustentam valor, segurança e recuperação — e quais só estão ali porque ninguém lembrou de remover.

Checklist de revisão para uma infraestrutura existente em Droplets

Use este checklist como ponto de partida para priorização. Ele não é certificado de maturidade, selo de senioridade nem garantia de disponibilidade. É uma forma prática de encontrar fragilidades e decidir próximos passos.

Acesso e sistema operacional

• [ ] Cada pessoa usa sua própria chave SSH; não há chaves compartilhadas sem responsável.
• [ ] O login direto como root foi revisado.
• [ ] O acesso administrativo segue o princípio do menor privilégio.
• [ ] Usuários, chaves e permissões antigas foram removidos.
• [ ] Existe uma rotina definida para atualizações de segurança.
• [ ] A equipe sabe como revogar acesso quando alguém muda de projeto ou sai da organização.
• [ ] Mudanças administrativas relevantes são registradas ou automatizadas.

Rede e exposição

• [ ] O firewall permite somente portas e origens necessárias.
• [ ] SSH não está aberto irrestritamente sem uma justificativa explícita.
• [ ] Serviços internos não estão expostos publicamente sem necessidade.
• [ ] Bancos, filas e painéis administrativos têm regras de acesso restritas.
• [ ] Recursos que se comunicam internamente usam VPC quando apropriado.
• [ ] A equipe validou região e VPC dos recursos que precisam conversar entre si.

Recuperação e continuidade

• [ ] Backups estão habilitados e sua cobertura foi validada.
• [ ] A equipe sabe quais dados são persistentes e onde estão armazenados.
• [ ] Backups e snapshots são usados com finalidades diferentes e compreendidas.
• [ ] A restauração já foi testada ou possui um teste agendado.
• [ ] O tempo e a perda de dados aceitáveis foram discutidos para a aplicação.
• [ ] Configurações necessárias para restauração estão documentadas ou versionadas.
• [ ] A equipe reconhece que um único Droplet continua sendo um ponto único de falha.

Monitoramento e operação

• [ ] CPU, memória, disco e rede são monitorados.
• [ ] Alertas relevantes chegam a um canal acompanhado.
• [ ] Alertas possuem uma ação inicial documentada.
• [ ] Logs e métricas da aplicação complementam o monitoramento da infraestrutura.
• [ ] Existem procedimentos curtos para incidentes recorrentes.
• [ ] A equipe revisa alertas ruidosos ou inúteis em vez de apenas ignorá-los.

Organização, automação e custos

• [ ] Droplets, projetos e tags identificam ambiente, sistema e responsável.
• [ ] Configurações críticas podem ser reproduzidas sem depender da memória de uma pessoa.
• [ ] Scripts e automações importantes estão versionados.
• [ ] Recursos e cobranças são revisados periodicamente.
• [ ] Ambientes temporários, snapshots e recursos não utilizados são removidos quando não são mais necessários.
• [ ] Cortes de custo são avaliados considerando impacto em segurança e recuperação.

Próximos passos

Se você está revisando uma infraestrutura existente, não tente resolver tudo no mesmo dia. Comece pelo que reduz mais risco com menor ambiguidade:

1. Revise acessos SSH e usuários. Remova chaves antigas, evite compartilhamento e reduza privilégios.
2. Feche exposição desnecessária. Ajuste firewall e restrinja serviços internos.
3. Valide backups. Confirme o que está coberto e teste uma restauração.
4. Configure alertas úteis. Comece por disco, CPU, memória e disponibilidade percebida pela aplicação.
5. Documente decisões essenciais. Responsáveis, portas, domínios, backup, restore e deploy.
6. Automatize o repetível. Primeiro scripts simples; depois ferramentas mais robustas, se fizer sentido.
7. Revise custos com contexto. Remova desperdícios sem sacrificar segurança ou recuperação.

Produção confiável nasce de melhorias incrementais. Um Droplet único pode ser uma boa etapa inicial, desde que a equipe saiba seus limites e trate operação como parte do produto.

Para trocar experiências sobre operação de software em produção, participe da comunidade SCCB.