
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.
Aponte seu webhook real do Stripe para uma URL hoody-files por trinta minutos. O diretório agora tem catorze arquivos JSON — todo payload que bateu em produção, byte por byte. Uma entrada de cron roda um script exec que faz POST deles de volta no staging às 9h, segunda a sexta. O agendamento expira no próximo sábado e se deleta sozinho.
{ "id": "evt_3OHk8ZJs2k9aXq1vQ", "type": "payment_intent.succeeded", "created": 1714723522, "data": { "object": { "id": "pi_3OHk8ZJs2k9aXq1v0K7rT4mB", "amount": 4900, "currency": "usd", "status": "succeeded" } } }
capturado pelo seu webhook real · reproduzido por uma entrada de cron
O fluxo inteiro são três URLs. Tráfego de produção chega na URL de captura. Arquivos pousam em hoody-files. Cron percorre a pasta e faz POST dos bodies de volta no staging. Não há broker, fila, nem serviço de replay — só um diretório e um agendamento.
Configure a URL do seu webhook do Stripe / Intercom / GitHub para um caminho hoody-files. Cada evento chega como PUT e pousa como um arquivo JSON nomeado com seu timestamp. O diretório é a gravação.
Arquivos persistem em disco; cada arquivo tem sua própria URL. Navegue pelo diretório no navegador, liste via API ou entre nele com curl. A gravação é um fato que você pode cat, scp ou versionar.
Faça POST de uma entrada de cron gerenciada com schedule 0 9 * * 1-5 e command bash /scripts/replay.sh /webhooks/2026-05-03. O script lista o diretório e faz POST de cada arquivo de volta para o staging em ordem de timestamp.
Captura e replay são o mesmo protocolo em dias diferentes. O que gravou os bytes é o que os reproduz. Não há parser JSONL, sem sidecar, sem formato de gravação para aprender — arquivos numa pasta, em ordem de tempo.
Captura é um PUT por evento de webhook. Replay é um POST para a Cron API. Hoody Files segura a gravação; Hoody Cron a percorre no agendamento; hoody-exec roda o script bash que faz os POSTs. Três serviços, sem cola entre eles.
# point your real webhook at hoody-files curl -X PUT \ https://files.containers.hoody.com/webhooks/2026-05-03/stripe-08-15-22.json \ --data-binary @- # 30 minutes later, the directory holds 14 files HTTP/1.1 201 Created webhooks/2026-05-03/stripe-08-15-22.json
# one cron entry replays the morning at 9am, mon-fri curl -X POST \ https://cron.containers.hoody.com/api/v1/cron/users/me/entries \ -d '["schedule":"0 9 * * 1-5","command":"bash /scripts/replay.sh /webhooks/2026-05-03","expires_at":"2026-05-10T09:00:00Z"]' HTTP/1.1 201 Created { "id":"f0a8", "schedule":"0 9 * * 1-5", "expires_at":"2026-05-10T09:00:00Z" }
O lado da captura roda uma vez numa sexta de manhã. O lado do replay roda todo dia útil até o próximo sábado, quando o campo expires_at da entrada de cron deleta o agendamento. Você escreveu uma URL PUT na config do seu webhook, e um POST na Cron API — esse é o teste de carga inteiro.
Tráfego sintético é o que você imaginou que a request parecia. Tráfego capturado é o que de fato chegou. Mesmos nomes de campo, mesmos casos de borda, mesmas surpresas.
A gravação captura o JSON exato que o Stripe enviou — incluindo todo campo nullable, todo tipo de evento inesperado, todo formato de customer_id que você esqueceu. Seu handler encontra os mesmos payloads em que falhou ontem.
A expressão cron 0 9 * * 1-5 entrega o replay no horário em que seus usuários reais usam o sistema. O handler em teste vê o pico da manhã contra os mesmos caches, os mesmos vizinhos de cron, o mesmo BD barulhento.
A pasta é imutável; o cron roda toda terça até expires_at. Se o handler ainda quebra na rodada de terça, você corrige e deixa a rodada de quarta provar. Mesma entrada toda vez — o handler é a única coisa que muda.
Os números vêm da Hoody Cron managed entries API e da spec padrão de expressão cron — não de benchmarks inventados.
Expressão cron padrão de 5 campos — minuto, hora, dia-do-mês, mês, dia-da-semana. A mesma sintaxe que você usou em 1985 ainda agenda o replay em 2026.
GET /users/[user]/entries pagina até 200 entradas gerenciadas por vez. Sessenta e três agendamentos de replay por ambiente cabem bem dentro do orçamento.
Crie o replay recorrente com um POST /users/me/entries — schedule, command, expires_at. PATCH depois para mutar; DELETE para aposentar; expires_at aposenta para você.
Limites pela Hoody Cron Managed Entries API: expressões cron padrão de 5 campos mais macros @daily / @hourly, paginação até 200 entradas por página, expires_at é opcional e desativa a entrada automaticamente após o prazo.
Tráfego de produção, gravado uma vez, reproduzido no agendamento.
As ferramentas padrão para reproduzir tráfego de webhook — gravadores, serviços de replay, mocks agendados. Cada uma é um SaaS, um sidecar ou um script que você fica de babá. O par hoody-files + hoody-cron não é nenhum desses.
Capture o tráfego de sexta. Agende o replay da próxima semana. Deixe a entrada de cron expirar sozinha quando o experimento acabar.