[{"data":1,"prerenderedAt":1014},["ShallowReactive",2],{"blog-\u002Fblog\u002Fdeploy-docker-producao-do-compose-ao-cluster":3,"blog-surround-\u002Fblog\u002Fdeploy-docker-producao-do-compose-ao-cluster":998,"blog-en-alt-\u002Fblog\u002Fdeploy-docker-producao-do-compose-ao-cluster":1012},{"id":4,"title":5,"author":6,"body":7,"category":979,"cover":980,"date":981,"description":982,"draft":983,"extension":984,"lastReviewed":980,"meta":985,"navigation":986,"path":987,"readingTime":988,"seo":989,"sitemap":990,"stem":991,"tags":992,"__hash__":997},"blog_pt\u002Fblog\u002Fdeploy-docker-producao-do-compose-ao-cluster.md","Deploy de Docker em produção: do compose ao cluster com alta disponibilidade","Equipe HeroCtl",{"type":8,"value":9,"toc":965},"minimark",[10,23,26,29,34,37,40,59,62,79,82,88,92,102,108,137,142,145,150,171,176,179,184,279,282,286,289,294,311,316,319,324,331,336,339,343,346,350,353,357,389,393,396,401,404,407,411,414,419,422,426,429,433,450,454,457,462,465,470,473,477,480,484,672,675,679,682,688,694,700,706,710,713,722,728,734,738,741,758,768,782,788,798,802,805,831,838,842,854,860,866,872,893,899,909,913,916,919,941,944,958,961],[11,12,13,14,18,19,22],"p",{},"O fluxo é familiar pra qualquer dev que cresceu nos últimos cinco anos. Você escreve um ",[15,16,17],"code",{},"docker-compose.yml"," com três serviços, roda ",[15,20,21],{},"docker compose up"," na sua máquina, funciona. Sobe num VPS de staging, funciona. Move pra produção apontando o DNS, e funciona — até a primeira sexta-feira às cinco da tarde em que para de funcionar.",[11,24,25],{},"O ponto exato em que \"funciona em produção\" deixa de ser verdade depende muito menos de qual ferramenta você escolheu, e muito mais de qual estágio de maturidade o seu produto atingiu. Esse post mapeia os quatro estágios pelos quais quase todo time passa, mostra os sinais práticos de que você precisa subir o degrau, e deixa explícito quando você ainda não precisa.",[11,27,28],{},"Não é um post anti-compose, nem um post pró-cluster. É um post sobre quando cada coisa cabe.",[30,31,33],"h2",{"id":32},"por-que-o-docker-compose-foi-tao-bem-em-desenvolvimento","Por que o Docker Compose foi tão bem em desenvolvimento",[11,35,36],{},"Antes de falar sobre os estágios, vale entender o que o Compose foi desenhado pra ser. Ele resolve um problema muito específico e resolve bem: orquestrar múltiplos contêineres na mesma máquina, declarando dependências, redes, volumes e variáveis de ambiente num único arquivo legível.",[11,38,39],{},"As premissas embutidas nesse desenho são as premissas de quem está desenvolvendo:",[41,42,43,47,50,53,56],"ul",{},[44,45,46],"li",{},"Uma máquina só. A sua.",[44,48,49],{},"Um usuário só. Você.",[44,51,52],{},"Restart manual. Quando dá problema, você abre o terminal e digita.",[44,54,55],{},"Dados efêmeros. Se o banco zerar, você roda o seed de novo.",[44,57,58],{},"Ninguém depende disso ficar de pé. Se cair às três da manhã, o mundo continua.",[11,60,61],{},"Em produção, todas as cinco premissas se invertem:",[41,63,64,67,70,73,76],{},[44,65,66],{},"N máquinas. Você não está mais sozinho.",[44,68,69],{},"N usuários. Eles não te conhecem.",[44,71,72],{},"Restart automático é exigência mínima. Ninguém vai acordar você às quatro da manhã. Idealmente, ninguém vai acordar ninguém.",[44,74,75],{},"Os dados importam. Perder o banco vira incidente reportável.",[44,77,78],{},"Alguém dorme com isso ativo. Possivelmente um cliente, possivelmente um contrato com multa.",[11,80,81],{},"O Docker Compose continua funcionando fora das premissas originais. Ele faz funcionar — só faz mal. Os atalhos que parecem inocentes em desenvolvimento (rede compartilhada entre serviços, volume montado direto no host, log saindo no terminal) viram pegadinhas quando o ambiente muda de \"uma máquina onde eu sei tudo o que está rodando\" pra \"três máquinas onde algo precisa estar rodando vinte e quatro horas por dia\".",[11,83,84,85,87],{},"Os quatro estágios a seguir mostram a curva natural de quem leva o mesmo ",[15,86,17],{}," desde o hobby até o SaaS com SLA contratual.",[30,89,91],{"id":90},"estagio-1-compose-em-um-unico-vps","Estágio 1: Compose em um único VPS",[11,93,94,95,97,98,101],{},"O ponto de entrada mais honesto do Docker em produção. Um VPS barato, um arquivo ",[15,96,17],{},", e ",[15,99,100],{},"docker compose up -d"," resolvendo a vida.",[11,103,104],{},[105,106,107],"strong",{},"Setup mínimo viável:",[41,109,110,113,116,123,130],{},[44,111,112],{},"1 VPS com 1–2 vCPUs e 2 GB de RAM (custa cerca de R$30 por mês em provedor brasileiro decente).",[44,114,115],{},"Docker e Docker Compose instalados via script oficial.",[44,117,118,119,122],{},"Todos os serviços com ",[15,120,121],{},"restart: always"," no compose.",[44,124,125,126,129],{},"Volumes nomeados pra dados (não bind mounts apontando pra ",[15,127,128],{},"\u002Fopt\u002Fapp\u002Fdata",").",[44,131,132,133,136],{},"Um cron diário rodando ",[15,134,135],{},"pg_dump"," e mandando pro S3 ou pra um Backblaze B2.",[11,138,139],{},[105,140,141],{},"Pra quem isso funciona:",[11,143,144],{},"Hobby projects, MVPs validando product-market fit, ferramentas internas pro time, painéis administrativos privados, blogs pessoais. Qualquer aplicação onde a frase \"se ficar fora cinco minutos, ninguém morre\" é literalmente verdadeira.",[11,146,147],{},[105,148,149],{},"Riscos que você está aceitando explicitamente:",[41,151,152,155,158,168],{},[44,153,154],{},"O VPS cai (manutenção do provedor, pico de noisy neighbor, hardware) e o seu serviço cai junto. Não tem fail-over.",[44,156,157],{},"O disco morre, e se você não estiver fazendo backup, perdeu os dados. Os SSDs de provedor cloud falham menos do que os do data center antigo, mas falham. Acontece.",[44,159,160,161,164,165,167],{},"Cada deploy tem uma janela de cerca de 30 segundos entre ",[15,162,163],{},"docker compose down"," e ",[15,166,21],{}," em que o serviço fica fora.",[44,169,170],{},"Você é o sysadmin. Patch de kernel, atualização de Docker, rotação de log, monitoramento de disco — tudo na sua mão.",[11,172,173],{},[105,174,175],{},"Limites práticos:",[11,177,178],{},"Aguenta confortavelmente 1 a 3 aplicações pequenas, tráfego na casa de 100 requisições por segundo, e tolerância de 5 a 30 minutos de downtime mensal. Se algum desses números for forçado pra cima, você está abusando do estágio.",[11,180,181],{},[105,182,183],{},"O backup que ninguém faz e devia fazer:",[185,186,191],"pre",{"className":187,"code":188,"language":189,"meta":190,"style":190},"language-bash shiki shiki-themes github-dark-default","# \u002Fetc\u002Fcron.daily\u002Fdb-backup\ndocker exec postgres pg_dump -U app app \\\n  | gzip \\\n  | aws s3 cp - s3:\u002F\u002Fmeu-bucket\u002Fbackups\u002F$(date +%F).sql.gz\n","bash","",[15,192,193,202,232,243],{"__ignoreMap":190},[194,195,198],"span",{"class":196,"line":197},"line",1,[194,199,201],{"class":200},"sH3jZ","# \u002Fetc\u002Fcron.daily\u002Fdb-backup\n",[194,203,205,209,213,216,219,223,226,228],{"class":196,"line":204},2,[194,206,208],{"class":207},"sQhOw","docker",[194,210,212],{"class":211},"s9uIt"," exec",[194,214,215],{"class":211}," postgres",[194,217,218],{"class":211}," pg_dump",[194,220,222],{"class":221},"sFSAA"," -U",[194,224,225],{"class":211}," app",[194,227,225],{"class":211},[194,229,231],{"class":230},"suJrU"," \\\n",[194,233,235,238,241],{"class":196,"line":234},3,[194,236,237],{"class":230},"  |",[194,239,240],{"class":207}," gzip",[194,242,231],{"class":230},[194,244,246,248,251,254,257,260,263,267,270,273,276],{"class":196,"line":245},4,[194,247,237],{"class":230},[194,249,250],{"class":207}," aws",[194,252,253],{"class":211}," s3",[194,255,256],{"class":211}," cp",[194,258,259],{"class":211}," -",[194,261,262],{"class":211}," s3:\u002F\u002Fmeu-bucket\u002Fbackups\u002F",[194,264,266],{"class":265},"sZEs4","$(",[194,268,269],{"class":207},"date",[194,271,272],{"class":211}," +%F",[194,274,275],{"class":265},")",[194,277,278],{"class":211},".sql.gz\n",[11,280,281],{},"Sem isso, você não está em produção. Está em \"desenvolvimento exposto na internet\". A diferença entre um e outro é exatamente este cron.",[30,283,285],{"id":284},"estagio-2-compose-com-auto-update-e-roteador-na-frente","Estágio 2: Compose com auto-update e roteador na frente",[11,287,288],{},"A primeira evolução natural. Você ainda tem um VPS, mas agora ele tem dois andares: um roteador que termina TLS e distribui as requisições, e os contêineres da aplicação atrás dele.",[11,290,291],{},[105,292,293],{},"Setup:",[41,295,296,299,302,305,308],{},[44,297,298],{},"1 VPS um pouco mais robusto (2–4 vCPUs, 4–8 GB), girando em torno de R$50 a R$80 por mês.",[44,300,301],{},"Mesma stack do estágio anterior, mais um reverse proxy (Caddy ou um Traefik standalone) terminando TLS automaticamente via Let's Encrypt.",[44,303,304],{},"Watchtower (ou equivalente) puxando imagens novas do registro periodicamente.",[44,306,307],{},"Pipeline simples no GitHub Actions ou GitLab CI que builda a imagem, manda pro registro, e deixa o Watchtower descobrir.",[44,309,310],{},"Backup automatizado igual ao estágio 1, agora com retenção mais longa.",[11,312,313],{},[105,314,315],{},"Pra quem funciona:",[11,317,318],{},"Indie hackers com 2 a 5 aplicações pequenas, primeiro cliente pago num produto SaaS lateral, agência hospedando sites para clientes sem SLA contratual, ferramentas internas que cresceram além da fase \"três pessoas usam\".",[11,320,321],{},[105,322,323],{},"O que melhorou em relação ao estágio 1:",[11,325,326,327,330],{},"Deploy ficou seamless do ponto de vista do desenvolvedor. Você dá ",[15,328,329],{},"git push",", o CI builda e publica, e dois minutos depois a versão nova está no ar sem você ter feito SSH em servidor nenhum. TLS automático resolve uma dor que costumava consumir uma tarde por trimestre. Múltiplas aplicações compartilham o mesmo certificado wildcard via roteador.",[11,332,333],{},[105,334,335],{},"O que ainda dói:",[11,337,338],{},"Watchtower puxa qualquer imagem nova sem pensar duas vezes. Não há rolling deploy — durante o swap, a aplicação fica indisponível por algo entre 10 e 30 segundos. Não há health check de verdade antes de promover a versão nova; se você publicou uma imagem quebrada, o serviço fica fora até você notar e revertir manualmente. E o ponto único de falha continua: o VPS que cai derruba tudo.",[11,340,341],{},[105,342,175],{},[11,344,345],{},"5 a 10 aplicações no mesmo servidor, tráfego de até 500 requisições por segundo (depende muito do tipo de carga), tolerância de 5 a 15 minutos de downtime mensal. Se você começou a perder noite de sono porque o Watchtower atualizou algo às três da manhã e quebrou, você passou do estágio.",[30,347,349],{"id":348},"estagio-3-multi-server-com-docker-swarm","Estágio 3: Multi-server com Docker Swarm",[11,351,352],{},"Aqui a conversa muda. Você sai de \"uma máquina robusta\" pra \"três máquinas se virando juntas\". O Docker Swarm é o degrau natural pra quem já está confortável com Compose: o arquivo é praticamente o mesmo, o vocabulário é o mesmo, e o salto conceitual é menor do que pular direto pro Kubernetes.",[11,354,355],{},[105,356,293],{},[41,358,359,362,372,383,386],{},[44,360,361],{},"3 ou mais VPS de tamanho médio. Três é o mínimo prático pra que o cluster sobreviva à perda de uma máquina.",[44,363,364,367,368,371],{},[15,365,366],{},"docker swarm init"," no primeiro nó, ",[15,369,370],{},"docker swarm join"," nos outros dois.",[44,373,374,375,378,379,382],{},"Stack file (",[15,376,377],{},"docker stack deploy -c stack.yml meuapp",") em vez de ",[15,380,381],{},"docker-compose up",".",[44,384,385],{},"Roteador integrado ao cluster (o Traefik tem modo Swarm nativo) escutando os eventos do daemon e rebalanceando automaticamente.",[44,387,388],{},"Logs e métricas centralizados? Você monta por fora. Não vem na caixa.",[11,390,391],{},[105,392,315],{},[11,394,395],{},"SaaS B2B com primeiro contrato exigindo \"best-effort 99%\", time já tem um dev confortável com terminal e disposto a aprender, aplicação cresceu além do que cabe num VPS único sem dor.",[11,397,398],{},[105,399,400],{},"A elefante na sala:",[11,402,403],{},"O Docker Swarm está em modo de manutenção desde 2019. A Docker Inc. não investe ativamente em features novas. Bugs críticos ainda são corrigidos, mas o ecossistema de plugins estagnou, e a evolução do scheduler praticamente parou. Funciona — milhares de empresas rodam Swarm em produção sem problemas hoje. Mas você está apostando numa tecnologia cuja trajetória de investimento foi cortada há mais de cinco anos.",[11,405,406],{},"A versão honesta disso: se você adota Swarm em 2026, está adotando com a expectativa de eventualmente migrar pra outra coisa. Não é um problema imediato — é um problema que aparece quando você precisar de algo que o Swarm nunca vai ganhar.",[11,408,409],{},[105,410,175],{},[11,412,413],{},"3 a 30 servidores, tráfego na casa de 5 mil requisições por segundo agregadas, tolerância de 5 a 30 segundos de failover quando uma máquina cai. Acima disso, ou você complementa com peças externas (observability stack, autoscaler manual, DNS GSLB), ou você sobe pro próximo degrau.",[11,415,416],{},[105,417,418],{},"Onde mais dói no dia a dia:",[11,420,421],{},"A overlay network sob carga alta tem edge cases conhecidos, principalmente em redes de provedor cloud com MTU não-padrão. Recovery após split-brain em alguns cenários precisa de intervenção manual — o cluster não se recompõe sozinho em 100% dos casos. E qualquer coisa que envolva observabilidade detalhada (métricas persistidas, logs estruturados, tracing distribuído) você monta separado, mantendo dois ou três produtos a mais.",[30,423,425],{"id":424},"estagio-4-cluster-com-plano-de-controle-replicado","Estágio 4: Cluster com plano de controle replicado",[11,427,428],{},"O degrau onde \"produção\" começa a ter o mesmo significado que tem em empresas de plataforma maduras. Você não está mais rodando um orquestrador legado em manutenção, nem dependendo de um único servidor pra continuidade.",[11,430,431],{},[105,432,293],{},[41,434,435,438,441,444,447],{},[44,436,437],{},"3 a 5 servidores na configuração mínima, com o plano de controle replicado entre os três primeiros. Os demais entram como agentes.",[44,439,440],{},"Eleição automática de coordenador. Se o atual cair, em poucos segundos outro assume e o cluster continua aceitando deploys e atendendo tráfego.",[44,442,443],{},"Roteador integrado, certificados automáticos, health check antes de promover versão nova, rolling deploy com janelas configuráveis.",[44,445,446],{},"Métricas e logs como serviços internos do próprio cluster — você não monta cinco produtos pra ter observabilidade básica.",[44,448,449],{},"Submissão de jobs via CLI, API ou painel web. O cluster decide em qual servidor cada réplica vai rodar.",[11,451,452],{},[105,453,315],{},[11,455,456],{},"SaaS com SLA contratual de 99,9%, multi-tenant com requisitos formais de isolamento, time de plataforma de 1 a 3 pessoas, contratos B2B em que uptime é parte do SOW, qualquer empresa em que \"ficar fora vinte minutos\" gera reembolso.",[11,458,459],{},[105,460,461],{},"Riscos que mudam de natureza:",[11,463,464],{},"A complexidade não some — ela muda de forma. Em vez de você operar três VPS na mão, você opera um cluster que resolve a maior parte dos problemas sozinho mas tem mais peças. Curva de aprendizado pra quem nunca operou cluster antes existe e é real. E é genuinamente overkill se você nunca vai além do estágio 2: três servidores rodando um app de hobby é desperdício.",[11,466,467],{},[105,468,469],{},"Números concretos pra calibrar:",[11,471,472],{},"Um cluster pequeno bem configurado roda confortavelmente em 4 servidores totalizando 5 vCPUs e 10 GB de RAM, com o plano de controle ocupando entre 200 e 400 MB por servidor. A eleição de coordenador, quando o atual cai, leva cerca de 7 segundos até o cluster voltar a aceitar deploys. Comparativamente, a configuração equivalente no Kubernetes começa em centenas de linhas de manifesto pra um app \"hello world\" — e o HeroCtl resolve a mesma coisa em cerca de 50.",[11,474,475],{},[105,476,175],{},[11,478,479],{},"3 a 500 servidores. Acima disso, o ecossistema do Kubernetes gerenciado tem ferramentas que cluster pequeno não precisa: federação multi-região, scheduler avançado pra workloads heterogêneos, biblioteca profunda de operadores especializados pra databases stateful. Não é que cluster pequeno não escale — é que acima de 500 nós você está num mercado em que outras ferramentas têm cinco anos de vantagem.",[30,481,483],{"id":482},"os-quatro-estagios-lado-a-lado","Os quatro estágios lado a lado",[485,486,487,509],"table",{},[488,489,490],"thead",{},[491,492,493,497,500,503,506],"tr",{},[494,495,496],"th",{},"Critério",[494,498,499],{},"Estágio 1 (compose 1 VPS)",[494,501,502],{},"Estágio 2 (compose + auto-update)",[494,504,505],{},"Estágio 3 (Docker Swarm)",[494,507,508],{},"Estágio 4 (cluster replicado)",[510,511,512,530,547,563,579,596,610,626,639,655],"tbody",{},[491,513,514,518,521,524,527],{},[515,516,517],"td",{},"Custo mensal mínimo (BR, 2026)",[515,519,520],{},"R$30",[515,522,523],{},"R$50",[515,525,526],{},"R$150 (3 VPS)",[515,528,529],{},"R$200 (4 VPS)",[491,531,532,535,538,541,544],{},[515,533,534],{},"Complexidade operacional",[515,536,537],{},"Mínima",[515,539,540],{},"Baixa",[515,542,543],{},"Média",[515,545,546],{},"Média-alta",[491,548,549,552,555,558,561],{},[515,550,551],{},"Tempo até primeiro deploy",[515,553,554],{},"15 minutos",[515,556,557],{},"1 hora",[515,559,560],{},"1 dia",[515,562,560],{},[491,564,565,568,571,573,576],{},[515,566,567],{},"Alta disponibilidade real",[515,569,570],{},"Não",[515,572,570],{},[515,574,575],{},"Sim, com ressalvas",[515,577,578],{},"Sim",[491,580,581,584,587,590,593],{},[515,582,583],{},"Escala máxima realista",[515,585,586],{},"1–3 apps",[515,588,589],{},"5–10 apps",[515,591,592],{},"30 servidores",[515,594,595],{},"500 servidores",[491,597,598,601,603,606,608],{},[515,599,600],{},"Deploys sem downtime",[515,602,570],{},[515,604,605],{},"Quase",[515,607,578],{},[515,609,578],{},[491,611,612,615,618,621,624],{},[515,613,614],{},"TLS automático",[515,616,617],{},"Manual ou plugin",[515,619,620],{},"Sim, embutido",[515,622,623],{},"Sim, via roteador",[515,625,620],{},[491,627,628,631,633,635,637],{},[515,629,630],{},"Observabilidade na caixa",[515,632,570],{},[515,634,570],{},[515,636,570],{},[515,638,578],{},[491,640,641,644,647,649,652],{},[515,642,643],{},"Time mínimo pra operar",[515,645,646],{},"1 dev (parcial)",[515,648,646],{},[515,650,651],{},"1 dev (dedicado)",[515,653,654],{},"1 dev (parcial) ou 2 (parciais)",[491,656,657,660,663,666,669],{},[515,658,659],{},"Faixa de aplicação ideal",[515,661,662],{},"Hobby, MVP",[515,664,665],{},"Indie hacker, primeiro cliente",[515,667,668],{},"SaaS B2B early-stage",[515,670,671],{},"SaaS com SLA, multi-tenant",[11,673,674],{},"A coluna que costuma surpreender é a de \"time mínimo pra operar\". O estágio 4 com ferramenta certa não exige mais gente do que o estágio 3 — exige gente que pensa diferente. O salto cognitivo é maior do que o salto operacional.",[30,676,678],{"id":677},"os-sinais-de-que-e-hora-de-subir-o-degrau","Os sinais de que é hora de subir o degrau",[11,680,681],{},"Subir antes de precisar é desperdício; ficar abaixo do necessário é dor. Os sinais práticos de cada transição:",[11,683,684,687],{},[105,685,686],{},"Estágio 1 → Estágio 2."," Você descobriu que precisa rodar mais de uma aplicação no mesmo VPS, deploys manuais começaram a ficar tensos (medo de derrubar produção às nove da noite de uma sexta), apareceu o primeiro cliente pago e ele tem expectativas — mesmo que não escritas — de que você não vá sumir por trinta minutos no meio do dia útil.",[11,689,690,693],{},[105,691,692],{},"Estágio 2 → Estágio 3."," Um cliente pediu SLA pela primeira vez, mesmo que informalmente (\"quanto tempo no máximo isso pode ficar fora?\"). Ou o VPS único caiu uma vez e você aprendeu na pele que precisava de redundância. Ou o time cresceu pra três ou mais pessoas e você não quer mais ser a única que sabe fazer deploy. Ou você está pagando R$300 por mês num VPS gigante quando três VPS médios resolveriam o mesmo com fail-over.",[11,695,696,699],{},[105,697,698],{},"Estágio 3 → Estágio 4."," Contrato B2B exige uptime medível e auditável (palavras como \"99.9%\" e \"janela de manutenção\" começaram a aparecer em proposta comercial). Compliance pediu auditoria detalhada e você precisa mostrar trilha de quem fez o quê. Ou — o sinal mais comum hoje — você está cansado dos patches do Swarm e quer uma ferramenta com roadmap claro pelos próximos cinco anos.",[11,701,702,705],{},[105,703,704],{},"O sinal universal de \"subiu cedo demais\"."," Você está gastando mais tempo configurando infraestrutura do que escrevendo features de produto. Volta um degrau. Sério. A infra existe pra suportar o produto, não o contrário, e a maior parte das startups que morrem cedo morrem porque construíram plataforma sem cliente em vez de cliente sem plataforma.",[30,707,709],{"id":708},"a-trajetoria-que-nao-funciona","A trajetória que não funciona",[11,711,712],{},"Três armadilhas comuns em que times caem ao tentar acelerar o salto:",[11,714,715,718,719,721],{},[105,716,717],{},"Pular do compose direto pra Kubernetes."," A tentação é genuína: \"se vou ter que migrar uma vez, melhor migrar pra ferramenta líder de mercado e nunca mais\". A realidade é mais cruel. Seis meses depois você ainda está lutando com manifestos de 300 linhas, operadores especializados, operadores de operadores, e gastando metade do tempo de engenharia em problemas que sequer existiam quando você rodava ",[15,720,21],{},". Enquanto isso, o concorrente mais simples shipou doze features. K8s vale a pena num momento muito específico — quando você já sabe que vai escalar pra 50+ servidores, tem time pra operar, e os problemas que ele resolve são problemas que você de fato tem. Antes disso, é capital queimado.",[11,723,724,727],{},[105,725,726],{},"Ficar no compose por orgulho."," O outro extremo. \"DevOps complicado é overkill, eu não preciso, sempre rodei tudo num VPS e nunca tive problema\". A realidade chega na primeira sexta-feira às cinco da tarde em que o disco do VPS morre, o backup do mês passado tem três semanas, e você descobre simultaneamente que (a) precisava de HA e (b) precisava de procedimento de recuperação testado. Os dois aprendizados num único final de semana são caros.",[11,729,730,733],{},[105,731,732],{},"Comprar a stack porque está hype."," Service mesh, observability stack completa com cinco produtos, GitOps com dois repositórios e três pipelines, autoscaler com policies sofisticadas — pra uma aplicação de três contêineres servindo 200 usuários ativos. Você está construindo plataforma sem ter usuário pra plataforma. A mesma energia investida em features do produto teria gerado dez vezes mais retorno. Se você está num estágio anterior, não importa quão bonita a ferramenta do estágio seguinte seja.",[30,735,737],{"id":736},"detalhes-tecnicos-que-valem-em-qualquer-estagio","Detalhes técnicos que valem em qualquer estágio",[11,739,740],{},"Algumas decisões valem desde o estágio 1 e seguem valendo no estágio 4. Vale gastar três parágrafos nelas porque cada uma já causou dor em produção pra muita gente.",[11,742,743,746,747,749,750,753,754,757],{},[105,744,745],{},"Restart policies."," No Compose, ",[15,748,121],{}," é o caminho certo pra quem quer que o contêiner volte sozinho depois de qualquer falha. ",[15,751,752],{},"on-failure"," é mais econômico mas vai te morder quando o processo der exit 0 por engano. No Swarm, ",[15,755,756],{},"restart_policy.condition: any"," faz papel similar. Em qualquer estágio, pensar na política de restart é parte de pensar no design da aplicação — não é detalhe.",[11,759,760,763,764,767],{},[105,761,762],{},"Health checks."," Toda aplicação que aceita HTTP precisa expor um endpoint ",[15,765,766],{},"\u002Fhealthz"," retornando 200 quando está saudável. Sem isso, nenhum orquestrador acima do estágio 1 consegue distinguir \"contêiner subiu\" de \"contêiner subiu e está realmente atendendo tráfego\". Timeout razoável: 5 segundos. Retry razoável: 3 vezes antes de marcar como unhealthy. Sem isso, você vai entrar em restart loops e demorar horas pra entender o que está acontecendo.",[11,769,770,773,774,777,778,781],{},[105,771,772],{},"Volumes nomeados versus bind mounts."," Volumes nomeados (",[15,775,776],{},"volumes: [meudata:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata]",") sobrevivem a recriação do contêiner, são gerenciados pelo Docker, e funcionam consistentemente entre estágios. Bind mounts (",[15,779,780],{},".\u002Fdata:\u002Fvar\u002Flib\u002Fpostgresql\u002Fdata",") dependem do filesystem do host, têm comportamento estranho com SELinux e AppArmor, e quebram quando o contêiner muda de máquina (estágio 3 e 4). Use bind mount só pra desenvolvimento e pra arquivos de configuração read-only.",[11,783,784,787],{},[105,785,786],{},"Logs."," Stdout e stderr é o caminho certo, sempre. Aplicação que escreve log em arquivo dentro do contêiner é aplicação que vai te dar dor de cabeça. O orquestrador captura stdout, roteia pra onde precisa ir (driver syslog, agregador externo, serviço interno), e você nunca mais precisa exec dentro do contêiner pra ver o que aconteceu.",[11,789,790,793,794,797],{},[105,791,792],{},"Secrets."," Variáveis de ambiente em arquivo ",[15,795,796],{},".env"," são confortáveis e perigosas — vazam em log, em backup, em snapshot. Pra estágio 1 e 2, dá pra viver com elas se você for cuidadoso. Pra estágio 3 em diante, use o mecanismo nativo de secrets do orquestrador. Em ferramentas mais novas (HeroCtl incluso), o cofre é parte do cluster — você não monta um produto separado só pra guardar senha.",[30,799,801],{"id":800},"custo-concreto-de-cada-estagio-brasil-2026","Custo concreto de cada estágio (Brasil, 2026)",[11,803,804],{},"A matemática crua, sem floreios:",[41,806,807,813,819,825],{},[44,808,809,812],{},[105,810,811],{},"Estágio 1."," 1 VPS de R$30 por mês = R$360 por ano. Tempo de setup inicial: uma tarde. Tempo de operação contínua: cerca de 1 hora por mês.",[44,814,815,818],{},[105,816,817],{},"Estágio 2."," 1 VPS de R$50 por mês = R$600 por ano. Tempo de setup: um dia. Tempo de operação: cerca de 2 horas por mês, principalmente lidando com Watchtower atualizando algo que não devia.",[44,820,821,824],{},[105,822,823],{},"Estágio 3."," 3 VPS de R$50 = R$150 por mês = R$1.800 por ano. Tempo de setup: cerca de 3 dias até estar confortável. Tempo de operação: 4 a 8 horas por mês, dependendo de quantos jobs rodam.",[44,826,827,830],{},[105,828,829],{},"Estágio 4 (HeroCtl Community)."," 4 VPS de R$50 = R$200 por mês = R$2.400 por ano. Tempo de setup: 1 a 2 dias até estar confortável. Tempo de operação: comparável ao estágio 3, mas sem os patches manuais e com observabilidade na caixa.",[11,832,833,834,837],{},"E pra calibrar a comparação que muita gente faz cedo demais: ",[105,835,836],{},"Kubernetes gerenciado pra a mesma escala"," custa entre R$700 e R$1.500 por mês de plano de controle e load balancers, então R$8,4k a R$18k por ano só de infraestrutura — sem contar os 1 a 2 SREs (R$25k a R$35k por mês cada) que esse estágio passa a exigir. A diferença entre estágio 4 e Kubernetes gerenciado, no quesito custo total, costuma ser de uma ordem de grandeza inteira.",[30,839,841],{"id":840},"perguntas-que-a-gente-recebe","Perguntas que a gente recebe",[11,843,844,850,851,853],{},[105,845,846,847,849],{},"Compose com ",[15,848,121],{}," não é suficiente?","\nÉ suficiente até a primeira coisa que ",[15,852,121],{}," não cobre: o VPS inteiro indisponível, o disco corrompido, a falha de rede do provedor, ou um deploy que sobe imagem quebrada e entra em loop sem alguém pra notar. Pra hobby project, suficiente; pra cliente pago, é o ponto de início, não o ponto de chegada.",[11,855,856,859],{},[105,857,858],{},"Docker Swarm está realmente deprecated?","\nNão no sentido oficial — a Docker Inc. não anunciou descontinuação. Mas está em manutenção, sem features novas relevantes desde 2019, e o ecossistema de plugins parou de crescer. Funciona em produção hoje. Uma escolha defensável pra quem já está nele. Uma escolha questionável pra quem está adotando agora em 2026.",[11,861,862,865],{},[105,863,864],{},"Quando vale subir pra Kubernetes gerenciado?","\nQuando você tem mais de 50 servidores, time de plataforma com 3+ pessoas dedicadas, e problemas específicos que o ecossistema do K8s resolve melhor (federação multi-região, autoscaling sofisticado, biblioteca profunda de operadores stateful). Antes disso, está pagando o custo sem usar o benefício.",[11,867,868,871],{},[105,869,870],{},"Watchtower é seguro?","\nRazoavelmente, com ressalvas. Ele puxa qualquer imagem nova publicada na tag que você está apontando, sem distinguir entre \"atualização que você publicou\" e \"imagem comprometida que alguém empurrou via cadeia de suprimento\". Pra estágio 2, o trade-off vale: o ganho operacional supera o risco. Pra estágios maiores, prefira mecanismos que validam imagem antes de promover.",[11,873,874,877,878,881,882,884,885,888,889,892],{},[105,875,876],{},"Como faço backup de volume Docker no estágio 1?","\nCron diário rodando ",[15,879,880],{},"docker exec"," no contêiner do banco com o utilitário de dump nativo (",[15,883,135],{},", ",[15,886,887],{},"mysqldump",", etc.), pipe pra ",[15,890,891],{},"gzip",", e upload pra storage objeto fora do mesmo provedor. A regra de ouro: o backup tem que viver longe do dado primário. Se o data center cair, o backup precisa estar em outro data center.",[11,894,895,898],{},[105,896,897],{},"Posso pular do estágio 1 direto pro 4?","\nTecnicamente sim, especialmente com ferramentas que fazem o salto suave (HeroCtl é uma delas, instala em minutos e roda confortavelmente em 3 servidores). Recomendado, só se você já sabe que vai precisar do estágio 4 nos próximos seis meses. Caso contrário, o estágio 2 te ensina coisas (deploy automatizado, TLS, registry de imagens) que você vai usar de qualquer jeito mais tarde.",[11,900,901,904,905,908],{},[105,902,903],{},"E se eu não souber Linux profundamente?","\nEstágio 1 e 2 são muito acessíveis com conhecimento básico. Estágio 3 começa a exigir entendimento de rede (overlay networks, MTU, iptables ocasional). Estágio 4, com a ferramenta certa, abstrai a maior parte da complexidade — mas debug de incidente ainda exige saber ler log de systemd, entender o que ",[15,906,907],{},"dmesg"," está dizendo, e diagnosticar disco cheio. Não há mágica que substitua os fundamentos quando algo dá errado às três da manhã.",[30,910,912],{"id":911},"fechando","Fechando",[11,914,915],{},"A maturidade não é virtude moral. Não é \"melhor\" estar no estágio 4 do que no estágio 1 — é melhor estar no estágio que combina com o tamanho do problema que você está resolvendo. Hobby project no estágio 4 é desperdício de capital e atenção; SaaS com cinquenta clientes pagantes no estágio 1 é negligência operacional.",[11,917,918],{},"O HeroCtl existe pra tornar o estágio 4 acessível pra quem antes precisava escolher entre o desconforto do Swarm e o custo do Kubernetes. Se você sente que passou do estágio 2 e está pesando entre as opções:",[185,920,922],{"className":187,"code":921,"language":189,"meta":190,"style":190},"curl -sSL https:\u002F\u002Fget.heroctl.com\u002Finstall.sh | sh\n",[15,923,924],{"__ignoreMap":190},[194,925,926,929,932,935,938],{"class":196,"line":197},[194,927,928],{"class":207},"curl",[194,930,931],{"class":221}," -sSL",[194,933,934],{"class":211}," https:\u002F\u002Fget.heroctl.com\u002Finstall.sh",[194,936,937],{"class":230}," |",[194,939,940],{"class":207}," sh\n",[11,942,943],{},"Instala em minutos, roda confortavelmente em 3 a 5 servidores, e tem plano Community gratuito permanente — sem feature gate artificial, sem limite de servidores, sem amarração contratual. Os planos Business e Enterprise existem pra empresas com requisitos formais de SSO, auditoria detalhada e suporte com SLA, e os preços estão publicados sem \"fale com vendas\" obrigatório.",[11,945,946,947,952,953,957],{},"Pra quem está comparando ferramentas no mesmo nicho, dois posts complementares: ",[948,949,951],"a",{"href":950},"\u002Fblog\u002Fheroctl-vs-coolify","HeroCtl vs Coolify"," cobre o trade-off de adotar uma ferramenta com HA real versus um painel single-server elegante; ",[948,954,956],{"href":955},"\u002Fblog\u002Fheroctl-vs-dokploy","HeroCtl vs Dokploy"," cobre a diferença de adotar um cluster com plano de controle replicado versus um painel que internamente roda Swarm.",[11,959,960],{},"E se a pergunta for \"qual estágio combina comigo agora?\", a resposta honesta quase sempre é: o anterior ao que você acha que precisa. Volta um, fica até doer, sobe quando doer mesmo.",[962,963,964],"style",{},"html pre.shiki code .sH3jZ, html code.shiki .sH3jZ{--shiki-default:#8B949E}html pre.shiki code .sQhOw, html code.shiki .sQhOw{--shiki-default:#FFA657}html pre.shiki code .s9uIt, html code.shiki .s9uIt{--shiki-default:#A5D6FF}html pre.shiki code .sFSAA, html code.shiki .sFSAA{--shiki-default:#79C0FF}html pre.shiki code .suJrU, html code.shiki .suJrU{--shiki-default:#FF7B72}html pre.shiki code .sZEs4, html code.shiki .sZEs4{--shiki-default:#E6EDF3}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":190,"searchDepth":204,"depth":204,"links":966},[967,968,969,970,971,972,973,974,975,976,977,978],{"id":32,"depth":204,"text":33},{"id":90,"depth":204,"text":91},{"id":284,"depth":204,"text":285},{"id":348,"depth":204,"text":349},{"id":424,"depth":204,"text":425},{"id":482,"depth":204,"text":483},{"id":677,"depth":204,"text":678},{"id":708,"depth":204,"text":709},{"id":736,"depth":204,"text":737},{"id":800,"depth":204,"text":801},{"id":840,"depth":204,"text":841},{"id":911,"depth":204,"text":912},"engenharia",null,"2026-04-21","Docker Compose resolve o dev. Em produção basta até um servidor sem SLA. Acima disso, você precisa de cluster real. Trajetória honesta dos quatro estágios de maturidade.",false,"md",{},true,"\u002Fblog\u002Fdeploy-docker-producao-do-compose-ao-cluster","15 min",{"title":5,"description":982},{"loc":987},"blog\u002Fdeploy-docker-producao-do-compose-ao-cluster",[208,993,994,995,996,979],"deploy","producao","cluster","ha","4Rex7CknFpoABnJvD7T4kmIcg_Oe56jP98EZjFWC9UM",[999,1006],{"title":1000,"path":1001,"stem":1002,"description":1003,"date":1004,"category":1005,"children":-1},"Como sair da AWS sem reescrever toda a stack: guia prático 2026","\u002Fblog\u002Fcomo-sair-da-aws-sem-reescrever-toda-stack","blog\u002Fcomo-sair-da-aws-sem-reescrever-toda-stack","Migrar de AWS pra cloud mais barato (Hetzner\u002FDO) ou auto-hospedado parece projeto de 1 ano. Na prática, dá pra fazer em 6-8 semanas se você mapear os 12 serviços AWS-only que sua stack usa de verdade.","2026-05-26","caso-de-uso",{"title":1007,"path":1008,"stem":1009,"description":1010,"date":1011,"category":979,"children":-1},"Deploy zero-downtime sem Kubernetes: tutorial prático em 2026","\u002Fblog\u002Fdeploy-zero-downtime-sem-kubernetes-tutorial","blog\u002Fdeploy-zero-downtime-sem-kubernetes-tutorial","Você não precisa de Kubernetes pra ter deploy sem downtime. Tutorial completo com 2 servidores, Caddy\u002FTraefik na frente, e rolling update via script ou orquestrador leve.","2026-06-09",{"path":1013},"\u002Fen\u002Fblog\u002Fdocker-deploy-production-compose-to-cluster",1777362207697]