Docker Compose em produção em 2026: um framework de decisão para CTOs

Você não precisa de Kubernetes. Ainda não. Se o seu produto é pré–Série B, seu tráfego é medido em dezenas de milhões de requisições por mês (não bilhões) e seu time tem menos de uma dúzia de engenheiros, Docker Compose em produção pode ser a escolha certa — desde que você o trate como produção, não como um ambiente de dev estendido.

O debate reacendeu neste mês após mais uma leva de posts perguntando “Devo rodar Docker Compose puro em produção em 2026?” e uma semana de manchetes de segurança: um bypass de autenticação no cPanel ativamente explorado, ambientes Ubuntu sendo martelados por DDoS, e divulgações de kernel sem aviso prévio às distribuições. Tradução: sua superfície de operações será testada, você rode k8s ou Compose. A questão é qual complexidade você quer pagar hoje.

A decisão que você realmente precisa tomar

Você não está escolhendo entre “Compose de brinquedo” e “Kubernetes de verdade”. Você está escolhendo entre:

• Um a poucos hosts, rede simples, workloads previsíveis, SLO de 99,9% — Compose + um host Linux endurecido + um reverse proxy + deploys disciplinados.
• Muitos hosts, workloads voláteis ou especializados (GPU/ML/batch), isolamento multi-tenant, 99,99%+ — um scheduler (Kubernetes, ECS ou Nomad) com tooling e maturidade de time compatíveis.

Todo o resto é detalhe. Aqui está o framework que usamos com startups e scale-ups nos EUA (e que nossos times de SRE baseados no Brazil operam diariamente).

A matriz de 8 eixos de um CTO para a viabilidade do Compose

1) Tamanho do time e maturidade de on-call

• Favorável a Compose: 2–6 engenheiros, 1–2 SREs ou generalistas fortes, uma única escala de on-call e um critério claro de “uma pessoa consegue entender toda a stack”.
• Território de scheduler: 3+ squads, time de plataforma separado, >30 serviços ou um mandato para infraestrutura self-service por times de feature.

2) Formato do workload

• Favorável a Compose: Principalmente APIs web de longa duração, um par de workers, jobs tipo cron, um banco de dados, um cache.
• Território de scheduler: Jobs em batch com picos, GPU/aceleradores, sandboxes por tenant ou centenas de tasks efêmeras/dia.

3) SLOs e orçamento de downtime

• Favorável a Compose: 99,9% de disponibilidade (≈43 minutos/mês). Blue/green ou reinícios escalonados mantêm dentro do orçamento.
• Território de scheduler: 99,99% (≈4,3 minutos/mês) ou mais, HA multi-AZ, reescalonamento automatizado entre nós.

4) Cadência de releases e rollback

• Favorável a Compose: Releases diárias com blue/green ou canário por header no proxy de borda; rollback fácil trocando o nome do projeto do Compose.
• Território de scheduler: Múltiplos deploys/hora em dezenas de serviços com canário automático e controle de tráfego.

5) Networking e discovery de serviços

• Favorável a Compose: Poucas redes internas, Traefik/Caddy na borda, discovery baseado em DNS entre 1–3 hosts.
• Território de scheduler: Malha complexa, políticas de rede, mTLS entre serviços, redes virtuais por tenant.

6) Workloads com estado

• Favorável a Compose: Um ou dois serviços stateful (Postgres, Redis) em VMs dedicadas com backups gerenciados e PITR.
• Território de scheduler: Dezenas de stateful sets, volumes dinâmicos entre nós ou HA estrita multi-AZ para bancos.

7) Compliance e isolamento

• Favorável a Compose: SOC2 com infra single-tenant por ambiente, tratamento de segredos direto, auditoria a partir do host.
• Território de scheduler: HIPAA/PCI com políticas de rede, níveis de segurança em pods e restrições de runtime granulares.

8) Custo e foco

• Favorável a Compose: Você quer entregar features, não operar uma plataforma. Espere 2–4 horas de engenharia/mês de manutenção de infra.
• Território de scheduler: Você já paga por um time de plataforma ou vendor; infra é uma vantagem competitiva.

Um blueprint de Compose para produção (2026)

Se suas respostas tendem a “favorável a Compose”, rode como para valer. Aqui está um blueprint que blindamos para times rodando 10–150 rps em média (picos 5–10x) com SLO de 99,9%.

Hosts e SO

• Comece com duas VMs de produção (otimizadas para computação, por exemplo, c7a.large ou equivalente) atrás de um balanceador de carga gerenciado. Coloque o Postgres em sua própria VM. Isso traz isolamento, recuperação simples e evita noisy neighbors.
• Ative atualizações de segurança automáticas e agende uma janela semanal de patch. Com vulnerabilidades de kernel sendo publicadas sem aviso prévio, assuma que você vai precisar reiniciar ao menos mensalmente. Projete reinícios em rolling (veja abaixo).
• Endureça o Docker: user namespaces, seccomp default, no-new-privileges, drop NET_RAW, defina limites de memória/CPU para cada contêiner. Considere Docker rootless ou Podman se seu time estiver confortável com os trade-offs.

Networking e ingress

• Rode Traefik (ou Caddy) como proxy de borda. TLS automático via Let’s Encrypt, sessões sticky se precisar e canário por serviço via header ou cookie.
• Use redes do Compose para isolar grupos de serviços. Apenas o proxy é publicado na internet. Todo o resto é apenas interno.

Deploys e zero-downtime

• Blue/green por nome de projeto: rode duas stacks na mesma rede do host (ex.: projeto “blue” e “green”). No deploy, inicie a nova stack, passe nos health checks, depois aponte o Traefik para os novos labels e pare a antiga. Rollback é um flip de label.
• Health checks importam: use start_period e interval/timeout/retries para codificar readiness. Não finja que liveness é readiness.
• Automatize os deploys com um job de CI que faça: build → push → ssh → docker compose pull → subir a nova cor → rodar smoke tests → flip de labels.

Segredos e config

• Prefira um secret store gerenciado (AWS SSM, GCP Secret Manager, 1Password Connect). No deploy, renderize arquivos env e monte-os como read-only nos contêineres.
• Se você precisar manter arquivos .env no host, armazene-os criptografados em repouso com sops e decripte apenas em memória durante o deploy.

Observabilidade

• Métricas: node_exporter + cAdvisor → Prometheus → dashboards no Grafana. Alerta sobre saturação (CPU steal, pressão de memória), taxas de erro e latência p95.
• Logs: Docker → Loki via Promtail ou para o serviço de logs do seu provedor de nuvem. Mantenha 14–30 dias quentes; arquive o restante em object storage.
• Tracing: OpenTelemetry para um backend gerenciado (Tempo, Honeycomb ou Datadog). Amostre a 5–10% para manter os custos sob controle.

Backups e disaster recovery

• Postgres: pgBackRest ou um Postgres gerenciado com PITR. Mire em RPO ≤ 5 minutos (WAL shipping) e RTO ≤ 60 minutos.
• Assets/estado: Prefira object storage (S3/compatível). Para volumes pequenos, faça backup com restic diariamente. Teste restores mensalmente.
• Faça snapshot das VMs diariamente. Mantenha 14 dias de snapshots; automatize um rebuild para novos hosts.

Postura de segurança

• Firewall: deny por padrão; apenas o balanceador de carga e SSH abertos. Considere Cloudflare ou Fastly na frente para absorção de DDoS. O DDoS no Ubuntu deste mês é mais um lembrete de que você não quer sua origem exposta.
• SBOM e varredura de imagens: construa imagens mínimas (distroless ou slim), faça scan no CI, fixe digests no compose e rotacione imagens base quinzenalmente.
• Runtime: habilite root filesystem read-only onde possível; monte volumes com o mínimo de permissões necessárias; retire capabilities do Linux.

Onde Compose começa a quebrar (e o que fazer em vez disso)

Seja explícito sobre o envelope. Se qualquer um destes aparecer no seu roadmap, comece a planejar a mudança:

• Agendamento multi-host e auto-recuperação: Se você quer que contêineres sejam reescalonados automaticamente na falha de um nó sem orquestrar blue/green por conta própria, olhe para ECS on Fargate (menos ops) ou Kubernetes (mais controle).
• Autoscaling horizontal: Você pode scriptar scale-up/down no Compose, mas se o tráfego for muito volátil ou sensível a custo, HPA nativo/auto scaling de ECS Service vencem.
• Políticas de rede e mTLS por padrão: Dá para simular com iptables e sidecars, mas é frágil. Se você precisa de isolamento de rede fino, migre.
• Dúzias de times e serviços: Infra self-service precisa de guardrails, cotas e recursos modelados. Isso é um problema de plataforma, não de compose.yaml.
• Agendamento pesado de GPU/ML ou orquestração de batch jobs: Use um scheduler desenhado para aceleradores e jobs efêmeros.

Custos: a parte que a maioria subprecifica

Em pequena escala, o imposto do Kubernetes é principalmente tempo de pessoas. Mesmo com control planes gerenciados, espere:

• Baseline de k8s gerenciado: taxas do control plane ($70–$150/mês), NAT gateways ($30–$70/mês cada), além da sobrecarga de node groups. Na prática, a maioria dos times que vemos gasta $800–$2.000/mês antes da carga do app.
• Tempo de engenheiro: 8–20 horas/mês em higiene do cluster, upgrades e a classe de problemas “sempre é DNS”. Se sua taxa de engenheiro com custo total é $150/hora, isso dá $1.200–$3.000/mês.
• Baseline de Compose: duas VMs médias a $80–$120 cada, um banco gerenciado $150–$400, um balanceador de carga $20–$30. Chame de $350–$700/mês de infra e 2–4 horas/mês de cuidado se você mantiver a stack pequena e disciplinada.

Isso não é teórico. Rodamos Compose em produção para startups processando 10–30M requisições/mês com SLO de 99,9% por 20–40% menos custo de infra e 50–70% menos tempo de ops do que seu “k8s inicial” anterior. A troca é planejamento de capacidade e modos de falha mais simples que você precisa codificar por conta própria.

Padrão de deploy concreto (que realmente funciona)

1. Layout do repositório: código do app + infra/compose com overrides por ambiente (compose.prod.yaml, compose.staging.yaml). Mantenha as imagens versionadas e fixadas por digest.
2. Build: Dockerfiles multi-stage, bases distroless/slim, geração de SBOM. Push para um registry privado.
3. Release candidate: job de CI marca a imagem com o SHA do git e escreve um manifesto de release com os digests das imagens.
4. Deploy: o CI conecta via SSH ao(s) host(s) alvo, puxa o manifesto de release, inicia a nova cor com docker compose up -d, espera por saúde, vira os labels do Traefik.
5. Smoke test: rode uma suíte e2e curta na rota canário (baseada em header); se passar, promova a 100%.
6. Pós-deploy: verifique dashboards, orçamentos de erro e faça rollback virando labels se necessário.

Ignore “watchtower auto-updates.” Isso troca repetibilidade por surpresa. Você quer deploys intencionais, mesmo no Compose.

Prática operacional: patching e resposta a incidentes

As últimas semanas foram um lembrete: atacantes adoram a cauda longa. O bypass de autenticação do cPanel e o DDoS no Ubuntu não se importaram se os times rodavam k8s ou Compose; puniram patching lento e origens expostas. Trate a aplicação de patches como um fluxo de primeira classe:

• Janela semanal de patch: agende e anuncie. Em modo blue/green, aplique patch na cor ociosa, vire, depois aplique na outra.
• Realidades do kernel: com CVEs de kernel “sem aviso prévio”, assuma reboots. Projete para isso. Seu processo blue/green deve tornar um reboot um não-evento.
• Coloque um CDN na frente: absorva DDoS volumétrico e faça rate limit de atores maliciosos. Termine TLS na borda e mantenha origens privadas.

Quando planejar a migração (antes de doer)

Não espere a dor forçar você a um rewrite de plataforma em 90 dias. Comece um radar de migração quando qualquer um destes for verdadeiro:

• Dois ou mais times pedem ambientes self-service.
• Você precisa de autoscaling mais rápido do que seu CI/CD consegue virar uma nova cor.
• Segurança pede políticas de rede que você não consegue aplicar confortavelmente no host.
• Seu número de serviços passa de ~30 e seus arquivos do compose parecem uma máquina de Rube Goldberg.

Nesse ponto, escolha um scheduler com base na sua nuvem e no seu pool de talentos: ECS on Fargate para o mínimo de ops (especialmente em stacks centradas em AWS), Kubernetes se você precisa de portabilidade ou de recursos profundos de ecossistema, ou Nomad se você valoriza simplicidade e pode viver sem a onipresença de k8s. Faça o orçamento da migração como uma feature: 6–10 semanas para um time experiente, mais se você também estiver redesenhando networking e CI.

Um exemplo realista

Um SaaS com cara de fintech Série A: 6 microsserviços (Go + Node), um worker, um job agendado, Postgres, Redis, 10M requisições/mês (média 4 rps, pico 50–100 rps), 2–3 engenheiros de on-call. Metas: SLO de 99,9%, SOC2, clientes nos EUA/UE.

• Infra: duas VMs c7a.large de app + Postgres gerenciado + Redis em uma VM pequena. Traefik em cada VM de app; o balanceador de carga da nuvem distribui para ambas.
• Deploys: blue/green por host, virada de label via Traefik, 1–2 deploys/dia.
• Segurança: SBOM no CI, fixação por digest de imagens, segredos do SSM, roots read-only, no-new-privileges, NET_RAW removido. CDN na frente, origens privadas.
• Ops: 2 horas/semana: patching, checagens de dashboard, teste mensal de restore. Observabilidade para Grafana + Loki + Tempo.
• Resultados: 99,93% de disponibilidade em um trimestre; um incidente (15 minutos) rastreado a uma fila de worker sem limite, corrigido definindo limites de memória no Compose e backpressure.

Onde nearshore entra

Se você escolhe Compose, está escolhendo uma superfície de ops menor — ótimo. Mas janelas de patch e incidentes de madrugada ainda acontecem. Uma equipe de SRE no Brazil com 6–8 horas de sobreposição com os EUA pode rodar o ciclo semanal de patch, gerenciar viradas blue/green e lidar com incidentes fora de horário enquanto seu time central dorme. Na nossa experiência, um engajamento de SRE nearshore de 0,5–1,0 FTE é suficiente para manter uma stack de Compose de produção em conformidade, atualizada e entediante — exatamente o que você quer.

Resumo

Docker Compose em produção não é um segredo culposo; é uma troca deliberada. Se você está abaixo de 30 serviços, com SLO de 99,9% e não precisa de isolamento por tenant ou reescalonamento multi-AZ, você pode ir mais rápido e gastar menos com Compose — desde que você endureça o host, automatize blue/green, coloque um CDN na frente e trate patching como trabalho de produto. Quando o seu roadmap exigir um scheduler, você vai saber. Até lá, mantenha sua stack simples e seus orçamentos de erro no verde.

Principais aprendizados

• Compose é viável em produção em 2026 para times pequenos, workloads previsíveis e SLOs de 99,9% — se você rodar como produção.
• Use um host Linux endurecido, Traefik/Caddy, blue/green por nome de projeto, imagens fixadas por digest e health checks de verdade.
• Espere 20–40% menos custo de infra e 50–70% menos tempo de ops do que “k8s inicial” em pequena escala; gaste o tempo recuperado em features.
• Segurança é o básico: firewall default-deny, CDN na frente, roots read-only, capabilities removidas, janelas semanais de patch e backups testados.
• Planeje uma migração quando você precisar de autoscaling, políticas de rede granulares, isolamento multi-tenant ou cruzar ~30 serviços.
• SRE nearshore (Brazil) cobre patching e incidentes com 6–8 horas de sobreposição, mantendo sua stack de Compose entediante e em conformidade.