Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
Contêineres·Snapshots
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoOtimizar custosParaEquipes de desenvolvimentoParaDevOps & infraServiçosContêineresServiçosSnapshotsPor que HoodyEconomia de contêineresPor que HoodyViagem no tempo de snapshot
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoOtimizar custosParaEquipes de desenvolvimentoParaDevOps & infraServiçosContêineresServiçosSnapshotsPor que HoodyEconomia de contêineresPor que HoodyViagem no tempo de snapshot
use-cases / kill-the-staging-tax / hero
CONTAINERS · SNAPSHOTS · COST
Acabe com o imposto do servidor de staging
A maioria dos times paga por produção e depois paga de novo por uma stack de staging que se parece mais ou menos com a produção. No Hoody, staging é um snapshot do contêiner de produção — ramificado no mesmo bare metal quando alguém precisa, congelado de volta para o disco quando não.
billing.containers.hoody.com
https://billing.containers.hoody.com/staging-cost-auditauditoria · economizado
ANTES · STACK DUPLICADAo que você costumava pagar
- prod EC2 m5.large$70us-east-1 · 24×7$0,096/h · × 730 h
- staging EC2 m5.large$70us-east-1 · 24×7 ocioso$0,096/h · × 730 h
- RDS prod (db.t3.medium)$281Multi-AZ · 100 GB gp3$0,380/h · × 730 h
- RDS staging (db.t3.medium)$281divergindo da prod$0,380/h · × 730 h
TOTAL MENSAL$702 / mês
DEPOIS · SNAPSHOT DA PRODo que você paga agora
- contêiner prod$49Hoody bare-metal · 24×7$0,067/h
- staging-via-snapshot$0ramificado sob demanda · ~12 h/semsó delta
- sem segunda máquina · sem segundo banco · sem drift
TOTAL MENSAL$49 / mês
DELTA MENSAL
−$65393% de economia
# snapshot da prod, depois ramifique staging a partir dela sob demandacurl -X POST api/v1/containers/$PROD/snapshotscurl -X POST api/v1/containers/$PROD/copy -d '{"source_snapshot":"prod-baseline"}'
COPY-ON-WRITEbase compartilhada · só deltas pagos
uma leitura real da coluna que a maioria dos times já tem mas não audita
use-cases / kill-the-staging-tax / mechanism
Três chamadas. Um snapshot. Sem stack duplicada.
Snapshots são baratos no Hoody porque a camada de armazenamento é copy-on-write. A imagem base é referenciada, não copiada. Staging compartilha as páginas da produção até algo divergir — então só o delta é pago.
01
PASSO 01Tire um snapshot da prod
POST /containers/$PROD/snapshots com um alias. A imagem base permanece referenciada; só os metadados são novos. A chamada retorna um nome de snapshot em menos de um segundo.
02
PASSO 02Ramifique staging a partir dele
POST /containers/$PROD/copy com source_snapshot=prod-baseline. Um novo contêiner inicia no mesmo hardware, compartilhando páginas com a prod. Escritas vão para um delta — staging só é cobrado pelo que ele muda.
03
PASSO 03Congele quando ocioso
Pare o contêiner de staging quando o QA terminar. Disco persiste, RAM e CPU caem a zero. Restaure em 5–15 segundos quando o próximo ticket chegar. Drift é impossível porque cada branch parte de um estado de prod conhecido.
shell · contra a Hoody Containers API
POST · snapshot + copy# 1. snapshot da produção — coloque um alias para humanos acharemcurl -X POST https://api.hoody.com/api/v1/containers/$PROD/snapshots \ -H 'Authorization: Bearer $TOKEN' \ -d '{"alias":"prod-baseline","expiry":30}'# 2. ramifique staging a partir desse snapshot exatocurl -X POST https://api.hoody.com/api/v1/containers/$PROD/copy \ -d '{"target_project_id":"$STAGING","source_snapshot":"prod-baseline"}'→ 200 OK · contêiner de staging inicia em 5–15 s, pagando só pelo delta
Snapshots podem carregar uma expiração em dias; a limpeza é automática. Copies podem escolher um target_project_id e target_server_id diferentes, então o QA pode viver em uma região ou subconta separada sem mudar a receita.
use-cases / kill-the-staging-tax / powers
O que largar a duplicata destrava
Quando staging é um branch em vez de um aluguel paralelo, vários incômodos recorrentes deixam de existir. A conta é só o mais visível.
ORÇAMENTO
Uma stack, não três
Produção, staging e QA costumavam ser três aluguéis cobrados separadamente. Agora são um contêiner mais dois branches baratos que acordam quando precisam. O ambiente marginal custa um delta, não uma duplicata.
FIDELIDADE
Drift se torna impossível
Cada branch de staging parte de um snapshot real de produção — mesma imagem de OS, mesmos pacotes, mesmo formato de dados, mesmas env vars. A classe de bug 'funciona em staging, quebra em prod' fica fechada por construção.
VELOCIDADE
Restaure em segundos, não horas
PATCH no contêiner contra um snapshot mais antigo para reverter um deploy ruim, ou ramifique uma cópia QA fresca a partir do backup de ontem à noite. Sem rsync, sem dump de DB, sem job de provisionamento de 90 minutos — só um nome de snapshot.
use-cases / kill-the-staging-tax / ledger
O livro-caixa mensal, com a duplicata removida
Mesma carga de trabalho — produção, staging, QA — contada de duas formas. Uma vez como três aluguéis completos, uma vez como um contêiner com dois branches de snapshot.
ANTES · STACK DUPLICADA$702 / mês
Duas instâncias EC2 m5.large a $0,096/h (730 horas), mais duas instâncias RDS db.t3.medium Multi-AZ a $0,380/h. Staging ocioso a maior parte da semana; o medidor não se importa.
DELTA · O QUE É PAGOsó delta
Staging ramifica de um snapshot da prod. Páginas compartilhadas são referenciadas, não duplicadas. Só os bytes que uma rodada de QA realmente escreve são cobrados — geralmente algumas centenas de MB em vez de 100 GB.
DEPOIS · UM CONTÊINER$49 / mês
Um contêiner Hoody cuida da prod 24×7. Staging e QA acordam de um snapshot quando o trabalho precisa, congelam de volta para o disco quando não. Uma conta, três ambientes, sem drift.
Os preços AWS usam tarifas públicas on-demand para us-east-1 EC2 m5.large e RDS db.t3.medium Multi-AZ no início de 2026. O preço do contêiner Hoody é ilustrativo e depende do servidor subjacente (precificado pelo marketplace a partir de $20/mês); o armazenamento de snapshot é cobrado pelo tamanho do delta. Os números mostrados são uma comparação representativa, não uma cotação.
use-cases / kill-the-staging-tax / punchline
Staging costumava ser uma duplicata da produção. Agora é um snapshot dela.
ANTES · DOIS ALUGUÉIS, UM PROPÓSITOalugar prod, alugar staging, sincronizar os dois na mãodois EC2s · dois RDSs · dois monitores · uma cópia divergindo
DEPOIS · UM CONTÊINER, MUITAS VISTASsnapshot $PROD → copy com source_snapshotbase compartilhada · branches só de delta · livre de drift por construção
use-cases / kill-the-staging-tax / replaces
O que isso substitui
As formas padrão de os times pagarem o imposto de staging. Cada uma cobra por um ambiente que está ocioso a maior parte da semana ou que diverge da prod até a hora em que você precisa.
- Duplicatas EC2 da AWS para stagingSegunda VM cobrada 730 h/mês para 12 h de uso
- dynos paralelos de staging HerokuConta por dyno + por add-on, ociosa a maioria dos dias
- vários VPS para camadas de ambienteCusto linear nos ambientes — três máquinas, três contas
- ferramentas customizadas de detecção de driftTooling para encontrar a lacuna entre staging e prod
- risco do "a gente não tem staging"O bug entra em produção porque ramificar a prod era caro demais
- Réplicas RDS para stagingSegundo banco para manter sincronizado, no medidor 24×7
use-cases / kill-the-staging-tax / cta
Pare de alugar um ambiente que diverge. Ramifique um que não pode.
use-cases / kill-the-staging-tax / related
Leia os outros
