
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.
Toda noite à 1h, uma entrada de cron dá curl numa URL exec. O script roda seu SQL de rollup na URL sqlite e grava a tabela diária de volta. Sem Postgres do Airflow, sem arquivo de DAG, sem dashboard de scheduler com 14 widgets, sem plantão para o próprio orquestrador.
SELECT date_trunc('day', created_at) AS d,
count(*) AS n
FROM events
WHERE created_at >= 'today'
GROUP BY 1 -- the whole pipelineO DASHBOARD É O ORQUESTRADOR. UMA URL. UM AGENDAMENTO.
O pipeline inteiro é uma entrada de cron apontando para uma URL exec. A entrada de cron é um POST em /users/root/entries. A URL exec é um pequeno script que abre a URL sqlite, roda o SQL de rollup e devolve as novas linhas. Esse é o DAG inteiro.
// toda noite às 01:00 UTC
POST /users/root/entries
{
"schedule": "0 1 * * *",
"command": "curl -fsS https://exec.containers.hoody.com/scripts/rollup/run"
}// o corpo do pipeline inteiro
import { Database } from "bun:sqlite";
const db = new Database("events.db");
db.run(`INSERT INTO rollup_daily
SELECT date_trunc('day', created_at), count(*)
FROM events GROUP BY 1;`);
return { ok: true, rows: db.query("SELECT * FROM rollup_daily").all() };Se o rollup falhar, os logs do cron dizem. Se você precisar reprocessar ontem, dá curl na URL exec à mão com um parâmetro de data. Não há um segundo sistema pra aprender, banco de dados de scheduler pra manter vivo, arquivo de DAG pra commitar. O orquestrador é uma entrada de cron apontando pra uma URL.
O Hoody Kit entrega o scheduler, o runtime e o storage como serviços HTTP simples. O pipeline é a chamada curl entre eles — nada mais.
O hoody-cron guarda agendamentos como recursos em /users/root/entries. Sem banco Postgres de metadata pra fazer backup, sem contêiner de scheduler pra manter saudável, sem repositório de DAG pra implantar. POST numa linha, e a execução dispara.
O hoody-exec roda o script de rollup sob demanda em exec.containers.hoody.com/scripts/rollup/run. O cron dá curl, recebe um 200, loga a resposta. Sem fila de worker, sem broker, sem grafo de tarefas serializado.
Toda chamada exec devolve as novas linhas como JSON e é logada pelo cron com status, timestamp e stdout. Reprocessamentos, falhas e re-execuções vivem todos nas mesmas duas URLs — nada extra pra mandar pra um agregador de logs.
O pipeline são duas URLs e um param de data. Reexecutar ontem tem o mesmo formato da execução noturna, só que com ?date=2026-04-30 na URL exec. Sem UI de replay, sem manhas de scheduler.
Se a execução da 1h retornou um non-2xx, o registro de última execução da entrada no hoody-cron mostra o código de saída e o corpo da resposta capturado. Sem serviço de alerta separado pra ligar — GET na entrada e leia.
O script aceita um parâmetro de data. Passe a data de ontem e ele recomputa a linha de rollup daquele dia, substituindo a quebrada com um INSERT OR REPLACE. Um comando, sem UI de re-trigger de DAG.
O exec devolve a linha de rollup recém-escrita como JSON. Compare com o que você esperava e siga em frente. Nada mais pra checar — a URL do dashboard serve a mesma tabela que você acabou de escrever.
Três números descrevem o sistema inteiro. Compare com como uma implantação de Airflow está no seu repo hoje.
minuto, hora, dia-do-mês, mês, dia-da-semana. Essa é a superfície de configuração inteira para quando uma execução dispara.
um POST pra registrar o agendamento, um GET que roda o script. Esse é o pipeline implantável inteiro.
sem processo de scheduler pra manter vivo, sem banco de metadata, sem pool de workers. O Hoody Kit guarda os agendamentos e roda o script.
Os números descrevem o modelo cron + exec no Hoody Kit. Seu pipeline existente provavelmente tem mais peças móveis; essa é a graça da comparação.
O orquestrador é uma entrada de cron apontando para uma URL.
A camada de orquestração colapsa em um cron de uma linha. O DAG vive no seu script.
Pare de rodar um orquestrador. Rode uma entrada de cron.