Substituindo uma conta de US$ 3.000/mês do Heroku por um servidor de US$ 55/mês

• A plataforma sem fins lucrativos de empregos Idealist migrou para um servidor dedicado de baixo custo para resolver o problema do alto custo dos ambientes de staging no Heroku
• No Heroku, por causa da cobrança por ambiente, cada ambiente de staging gerava um custo de cerca de US$ 500 por mês
• Em vez disso, a equipe montou vários ambientes em um único servidor Hetzner CCX33 (US$ 55/mês) e, com o Disco, manteve a mesma experiência de git push e automação do Heroku
• Um único servidor roda de forma estável 6 ambientes de staging, com uso de CPU de 2% e memória em torno de 14 GB de 32 GB, com bastante folga
• Com isso, os ambientes de staging deixaram de ser “um fator de custo” para se tornar “um recurso que pode ser criado livremente”, melhorando bastante a cultura de experimentação e deploy da equipe de desenvolvimento

---

Relato prático de uma estratégia para reduzir custos do Heroku

O problema: um ambiente de staging de US$ 500 por mês

• O Idealist.org é uma grande plataforma sem fins lucrativos de empregos, com milhões de visitantes por mês, e por isso um ambiente de staging quase idêntico ao de produção é essencial
• No Heroku, o custo de um ambiente de staging com os componentes necessários, como dynos web/worker e Postgres, ficava em cerca de US$ 500/mês
• Manter apenas dev e main já gerava um custo fixo superior a US$ 1.000
• O modelo de preços do Heroku é uma cobrança por ambiente, então mesmo reduzindo dynos a economia é pequena, e os custos disparam conforme o número de aplicações cresce

O experimento: migrar para um único servidor

• Para buscar a redução ideal de custos, a equipe começou um experimento alugando um único Hetzner CCX33 (US$ 55/mês)
• Usando a solução Disco, aplicou no servidor o mesmo modelo de deploy via git push que já usava no Heroku
• Todos os ambientes de staging passaram a usar uma instância compartilhada de Postgres no mesmo servidor, reduzindo drasticamente o custo com banco de dados gerenciado
• Do ponto de vista de testes, isso também funcionou bem porque era fácil reinicializar bancos de dados separados por desenvolvedor

Por que usar Disco: a diferença em relação ao Docker Compose

• Apenas rodar docker-compose up no servidor não oferece uma experiência de desenvolvimento suficiente
• O Disco traz vantagens como:
  • O mesmo processo de deploy via git push do Heroku
  • Deploys automáticos sem downtime para todas as implantações
  • Emissão e renovação automáticas de certificados SSL para URLs por branch
  • Uma interface web intuitiva para logs e gerenciamento de ambiente
• Assim, é possível manter a praticidade para os desenvolvedores sem precisar construir e manter automações próprias de gestão de deploy

Explosão de ambientes de staging e eficiência dos recursos do servidor

• Com o Disco, expandir ambientes de staging ficou extremamente simples
• Em um único servidor, a equipe opera simultaneamente ambientes como:
  • branch principal
  • branch feature-freeze
  • ambientes temporários descartáveis para PRs
  • ambientes de longo prazo para desenvolvimento de grandes funcionalidades
• No total, 6 ambientes de staging independentes estão rodando sem dificuldades
• No Heroku isso exigiria US$ 3.000 por mês, mas no Hetzner a estrutura de baixo custo consome apenas 2% de CPU e 14 GB de memória (de 32 GB)

Trade-offs e considerações práticas

• Não é uma alternativa completa, e há alguns ônus operacionais adicionais
• Trabalhos de infraestrutura como configuração de DNS e CDN para cada novo ambiente não estão automatizados
• Passa a existir responsabilidade operacional por monitoramento do servidor, atualizações de segurança e resposta a incidentes
• Como a Hetzner tem limitações de região nos EUA, ela pode não ser adequada para serviços de produção voltados a usuários americanos
• Há um trade-off de disponibilidade ao aceitar a possibilidade de reinstalação em caso de falha do servidor
• Foi necessário cerca de um dia de trabalho de engenharia para adaptar a aplicação ao networking do Docker

Insights obtidos e mudanças percebidas

• Depois de mais de 6 meses de operação, essa infraestrutura se consolidou como uma estrutura permanente
• A maior mudança não foi apenas a redução de custos, mas a mudança de percepção dos ambientes de staging como um recurso abundante e livre
• Os desenvolvedores passaram a poder criar ambientes por pull request sempre que necessário, sem precisar pedir aprovação nem se preocupar com custo
• A equipe concluiu que o verdadeiro prejuízo não era só o custo em si, mas também a hesitação em usar esses ambientes
  • "O peso financeiro vinha limitando a velocidade de desenvolvimento e a experimentação"

[GN⁺]

Comentários do Hacker News

• Pela captura do htop, chamou atenção a ausência de swap, então recomendo ativar o earlyoom para evitar que o servidor inteiro caia quando um serviço começar a consumir memória de forma anormal; o OOM killer do kernel Linux geralmente age tarde demais. Outra opção é ativar zram para comprimir a RAM e fazer overprovisioning como um profissional. Softwares de longa duração frequentemente apresentam vazamentos de memória, e a compressão costuma ser bem eficiente. Deixei em um gist como aplicar isso com Ansible em servidores bare metal da Hetzner; funciona igual em VMs

  • Discordo totalmente. Quando se chega ao swap, a maioria dos apps já entra em sérios problemas. Isso é um fato bem conhecido, e as instâncias AWS EC2 também vêm com swap desativado por padrão. Claro, a AWS também quer vender mais RAM, mas swap não combina com as expectativas de hoje em dia. Nos anos 90 até se aceitava esperar 2 ou 3 segundos por clique; hoje, se algo não responde, as pessoas já acham que morreu e reiniciam na hora

  • Outra alternativa é adicionar mais memória e ajustar o oom_score por app, dando um peso maior de eliminação para apps menos importantes e peso negativo para os críticos. Por exemplo, o OpenSSH já vem com oom_score_adj definido como -1000. Também é muito útil praticamente desativar o overcommit em servidores de staging/produção. Dá para calcular e configurar valores de min_free e reserve com base na quantidade de RAM. Isso funcionou na prática por mais de 10 anos operando 50.000 servidores físicos sem swap. OOM só acontecia quando as exigências de memória eram mal calculadas durante deploys de código. Também acontecia quando não se seguiam boas práticas em Java, mas isso é outra história. Também há como aplicar limites de memória por aplicação com cgroups, mas vou pular essa parte. Se for um servidor totalmente in-memory e sem necessidade de gravar em disco, também recomendo configurar para que OOM nunca aconteça e para que haja self-healing automático. Também é útil configurar reinício por pânico (kernel.panic, vm.panic_on_oom etc.) para dar tempo de capturar mensagens de crash via DRAC/iLO. Aliás, em sistemas diskless com NFS, isso pode até ser usado intencionalmente para disparar o reinício de toda a fazenda em cenários de recuperação de falha

  • Obrigado pelas boas informações. Estou controlando isso com limites do sistema (systemd) baseados em limiares de RAM, mas fiquei curioso se o earlyoom seria uma opção melhor para evitar que uma instância inteira fique sem resposta por comportamento anômalo de um processo

  • Acho uma boa ideia manter uma quantidade bem pequena de swap por precaução, tipo 1GB

  • Não uso swap desde 2010

• Ontem vi o Nate Berkopec escrever sobre algo parecido em relação à performance de Rails, dizendo que a Heroku é de 25 a 50 vezes mais cara por desempenho. Chega a ser ridículo o quanto não há vontade de competir em preço, e penso que se ao menos licenciassem toda a stack por um valor razoável, como o Sidekiq, mesmo com o hardware separado já seria muito melhor. Em 2025, um dyno com 1GB de RAM por $50 é praticamente um assalto. Especialmente porque um app Rails padrão não ficou muito mais pesado e, se algo, até ficou mais eficiente; ainda assim, os preços subiram e a qualidade caiu. É quase cômico quantos desenvolvedores mantêm apps na Heroku por centenas de dólares por mês usando máquinas mais lentas do que o MacBook que usam para desenvolver. No fim, como em tantas outras coisas hoje em dia, a tendência parece ser parar de oferecer um bom produto por um preço razoável para o público amplo e focar só nos clientes do topo que têm mais dinheiro, aumentando os preços sem parar

  • Não é só uma questão de aumento de preço. Acho que a Heroku e os vendors de nuvem se beneficiam do efeito psicológico de preço-âncora. O usuário cria uma referência de preço quando começa a usar o serviço, e depois as expectativas só mudam linearmente. Já o desempenho real do hardware evolui de forma exponencial, mas o usuário percebe isso só de forma linear. O preço da Heroku não mudou por pelo menos 7 anos, mas o hardware avançou enormemente. Então, a sensação de golpe vem do fato de que, na prática, você está comparando o ponto de referência de 2025 com preços do meio da década de 2010. Os grandes vendors de nuvem colocam barreiras como desbloqueio de performance em hardware novo ou atualizações de SKU. A Heroku nem teve esse tipo de concorrência, então manteve os preços fixos, e textos como este aparecem sempre que novos engenheiros sentem na pele o avanço do hardware

  • Você falou que um dyno com 1GB de RAM por $50 é um assalto, mas a AWS também não é muito diferente. Por $50/mês, você pega um m7a.medium, com 1 vCPU e 4GB de RAM. Tem mais memória, claro, mas dá para entender por que a AWS imprime tanto dinheiro

  • Concordamos tanto com essa ideia de licenciar toda a stack de software por um preço razoável, como o Sidekiq, que fizemos o canine.sh como open source. Achamos que não fazia sentido provedores de PaaS colocarem uma margem exagerada em cima de nuvem que já vem com margem embutida

  • É parecido com dizer que a troca de óleo da oficina do bairro ou o bife do restaurante saem mais baratos se você fizer em casa

• A nuvem faz a gente esquecer quanta coisa dá para fazer com um único servidor. Mesmo em ambiente de staging, eu realmente não entendo subir isso em uma nuvem cara, embora eu compreenda a necessidade, já que hoje a nuvem envolve uma mistura complexa de vários fatores

  • Ensinar fundamentos de nuvem para vários desenvolvedores e manter alguns especialistas de nuvem costuma ser economicamente vantajoso por um bom tempo. Se staging e prod forem parecidos, os erros também aparecem mais rápido. Mais tarde, a conta da nuvem acaba superando o custo de pessoal, e aí sair da nuvem passa a gerar ganho real. No fim, acho que ao migrar para servidores próprios sempre chega um ponto em que os custos ultrapassam o preço da equipe e do hardware

  • Dá a sensação de que, por causa da nuvem, os desenvolvedores passaram a ter medo de servidores Linux em si. Acho que boa parte da margem cobrada é o preço dessa insegurança do desenvolvedor. Só que self-hosting é, na prática, fácil e divertido. Nunca vi muito apelo em Heroku, Vercel e similares, e acredito que não há experiência melhor do que subir seus próprios servidores desde o começo. Recomendo que todo desenvolvedor faça isso pelo menos uma vez

  • Ajuda bastante replicar completamente o ambiente de prod para ficar parecido com a operação real. O processo de deploy fica semelhante, economiza tempo e permite testar de forma muito mais próxima da produção

  • Seria interessante criar um site de aprendizado de infraestrutura baseado nisso: você recebe X recursos na nuvem e precisa configurar tudo para suportar uma determinada carga, com um ranking de desempenho para as pessoas competirem entre si

  • Por volta de 2006, a menor máquina da AWS tinha porte de um desktop de desenvolvimento decente, então era preciso alugá-la por mais de 2 anos para compensar. Hoje, as máquinas da AWS estão mais para nível de celular ou notebook barato, e alugar por 3 a 6 meses já torna mais vantajoso comprar o hardware. A menos que você tenha 75% de desconto, on-premise economiza tanto gente quanto dinheiro em relação à nuvem

• Olá, estou desenvolvendo um PaaS open source chamado Disco junto com meu amigo Antoine Leclair. Hoje em dia há muita discussão sobre self-hosting e saída da nuvem. Fiquem à vontade para perguntar qualquer coisa

  • Quando você mencionou que “o uso de recursos do servidor foi muito baixo”, isso fica ainda mais impressionante lembrando que o load average no htop é por núcleo de CPU. Por exemplo, em uma máquina com 8 núcleos, load average de 0,1 equivale a cerca de 1,25% da capacidade total de CPU. Gostei bastante do blog; aprendo muito com esse tipo de padrão também

  • Queria entender o que exatamente o Disco oferece de diferente em comparação com ferramentas como o Coolify. Hospedo a maior parte dos meus serviços em uma VPS da Hetzner, então, se houver algum diferencial forte do Disco, gostaria de saber

• Tivemos uma experiência parecida no Hack Club. Nossa organização sem fins lucrativos foca em ajudar estudantes do ensino médio a começar em programação e eletrônica. Antes usávamos Heroku, mas, além do custo, ficava sempre a dúvida se aquele pequeno app utilitário realmente valia $15 por mês. Neste ano, passamos para self-hosting com Coolify e estamos rodando 300 serviços em um único servidor da Hetzner de $300/mês. Como resultado, conseguimos colocar muito mais código em produção. A maior lição foi perceber que, se você não precisa de 99,99% de uptime e 99% já basta, o mundo fica muito maior. A maioria das ferramentas para desenvolvedores é obcecada por 99,99%, mas, se 99% é suficiente, dá para operar com muito mais eficiência. O Disco também me deixou curioso e pretendo testar com certeza

  • Obrigado. Se tiver qualquer dúvida sobre o serviço Disco, fique à vontade para perguntar no Discord. Temos dois casos parecidos: em um bootcamp/escola de programação em Porto Rico, fizemos os projetos finais dos alunos serem todos implantados em uma única VPS, e no Recurse Center estamos hospedando 75 projetos web em um único Raspberry Pi (link)

  • E, se você realmente precisa de 99,99%, acho que faz sentido evitar hyperscalers, como mostrou a recente indisponibilidade de várias horas na AWS

  • 300? Fiquei curioso sobre o que cada serviço faz

• Pelo cenário atual, self-hosting parece realmente uma solução muito atraente, mas quero comentar algo sobre o texto em si. Este post parece ter sido fortemente editado por IA e, de fato, a seção “Bridging the Gap: Why Not Just Docker Compose?” é um copia e cola 1:1 de “Powerful simplicity” na landing page do produto Disco. Este post de blog também é o único estudo de caso exibido na página principal deles

  • Isso está totalmente certo. Eu daria três razões para isso (brincadeira), mas nossa biblioteca é open source e temos orgulho de a Idealist ter economizado dinheiro. Se se orgulhar disso conta como marketing, então sim, tenho orgulho mesmo

  • Você está dizendo que texto de marketing é um problema, mas por que acha isso um problema? Isso é proibido pelas diretrizes do Hacker News, ou você acha que todo marketing deveria vir sinalizado? Quase não existe texto no mundo que não seja marketing de alguma forma

  • Estão escrevendo um post de blog de marketing sobre competição de preços, mas no próprio site não mostram os preços e só pedem para marcar reunião. Para mim, isso é o maior sinal de alerta possível quando o assunto é preço

  • Eu também fui atrás para entender o modelo de receita de imediato, mas só fiquei com a impressão de que isso deve ser divulgado em breve

  • Não é a primeira vez que aparece um texto com marketing embutido, e sinceramente não entendo qual é o problema de marketing por meio de texto baseado em caso. Achei um caso relativamente moderado e, mesmo com esse lado promocional, foi interessante e útil de ler

• Os preços da Heroku são realmente insanos. Fiquei chocado ao ver, em uma startup onde trabalhei há cerca de 10 anos, que se gastava mais de $10.000 por mês para rodar um serviço que basicamente gerava QR codes em uma tabela HTML e os mostrava por e-mail. Saía por cerca de $0,15 por unidade. O líder técnico nunca tinha nem feito profiling do código, então eu baixei para $0,01 por unidade, mas ainda assim era absurdo

  • Não entendo como algo tão simples pode custar tanto para gerar um único QR code. Só com hospedagem em edge cloud isso já poderia ser feito de graça

• Não entendo bem por que seria preciso ter 6 servidores de staging (a $500 cada). Se isso for por causa de uma equipe grande, então $3.000 em custos de servidor não é praticamente nada perto de mais de $100 mil por ano em custo de pessoal, não? Dei uma olhada no idealist.org e parece só um quadro de vagas, então achei exagerado

  • Os 6 servidores de staging existiam para main, dev e várias branches, para que o QA não técnico pudesse verificar cada uma diretamente. Cada deploy de staging rapidamente acumulava custos com dynos Performance-M, vários dynos Standard, RabbitMQ, banco de dados etc. O serviço da Idealist atende 100 mil pessoas por dia, então há muita engenharia por trás da confiabilidade e velocidade

  • Pelo que entendi lendo, parece que eles criaram esses servidores de staging para usar como ambientes de desenvolvimento com vários serviços rodando em paralelo para cada desenvolvedor, então precisavam de vários deles

  • Muita gente ignora o custo de pessoal (homem-dia) no cálculo real

• Quero sair da Heroku, mas basicamente só preciso despejar meu site Django e o banco de dados em algum lugar. Qual seria a melhor opção se eu quiser evitar administrar o sistema por conta própria?

  • Render.com é provavelmente a opção mais parecida, e estou realmente satisfeito com ela. O fluxo de trabalho é igual ao da Heroku, é mais barato, e também estou satisfeito com reinícios noturnos e suporte às versões mais recentes do Python

  • Também recomendo aprender Docker Swarm. O deploy vira só empurrar um container e rodar um comando. Eu mesmo criei o rove.dev, uma ferramenta CLI gratuita para deploy e diff de serviços. Ou então vale considerar PaaS baseados em VM, como Semaphore, Dokku e Dokploy

  • Basta escolher a VPS que quiser de acordo com preço/desempenho/localização/suporte e então usar a ferramenta de deploy que preferir, como Coolify ou Dokploy. Recentemente migrei um Django/Postgres do Google App Engine usando Coolify e Mythic Beasts, e foi realmente fácil fazer a migração mesmo com minhas habilidades já enferrujadas

  • Acho que basta subir um único servidor na Hetzner e configurar nginx e um serviço no systemctl

  • PythonAnywhere (link) também é uma boa

• Projeto muito legal. Pelos documentos, parece que a integração com GitHub é um requisito obrigatório no Disco; queria confirmar se é isso mesmo. E também queria saber se dá para implantar diretamente imagens Docker já existentes no meu registry, sem processo de build, algo parecido com --skip-push --version latest do Kamal

  • Sim, por enquanto a integração com GitHub é necessária. Mas o Disco também consegue puxar e implantar diretamente imagens Docker já existentes (nós fazemos self-host do RabbitMQ dessa forma). Como exemplo, veja como implantar a imagem do Meilisearch aqui e neste tutorial. Fiquei curioso se seu fluxo normalmente envolve build e push para registry, e gostaria de ouvir mais detalhes sobre como é o seu processo de deploy hoje