
Sixty containers on one server
One bare-metal box runs dozens to hundreds of Hoody containers. KSM and BTRFS dedup make the marginal cost near zero.
Every Sunday at 7am a hoody-cron entry wakes a hoody-agent in a fresh container. The agent's prompt: behave like a malicious user. It probes login forms, fuzzes the API, tests the rate limiter — against a snapshot of prod, never prod itself. By 9am it writes a findings report to a URL.
every line in this report is a real-looking finding from a sunday run · click to expand
Three HTTP calls in sequence. The cron entry triggers a snapshot of prod, an agent container is spawned against the snapshot with an attack prompt, and the report gets PUT to a URL when the agent exits. No long-running infrastructure between Sundays.
The three pieces — Cron, Container Snapshots, the Agent service — already exist in the Kit. Wiring them together is one shell script. There is no canary platform to install.
Two hours, top to bottom. The agent reads its own prompt as a runbook. Each finding is documented with reproduction steps so the engineer who reads it on Monday can verify in under a minute.
Cron fires. The runner script POSTs to the snapshots endpoint and then to the agent service. A canary-2026-05-03 alias is created.
Agent opens hoody-browser against the snapshot URL. It enumerates routes from the OpenAPI spec and the homepage links, building a map of the surface.
OWASP top 20 in order: SQLi, XSS, IDOR, SSRF, race conditions, rate-limit bypass. Before each risky request, the agent takes a sub-snapshot so a destructive payload cannot poison subsequent tests.
Each non-error response gets a severity, a reproduction recipe, and a suggested fix. Findings the agent itself can verify with a second request get a confidence score.
Report PUT to /canary/last-sunday.html. Container destroyed. Cron exits 0. The next entry won't fire for another seven days.
Two hours of Sunday morning produces a static report your team can read with a coffee. There is no dashboard to log into and no agent to babysit while it works.
A pen-tester cannot let an agent loose on production. With Container Snapshots, the agent has an exact clone to break — and the live system never feels it.
The snapshot the agent attacks is a copy-on-write clone of prod's filesystem and config. A successful exploit modifies the clone, not the live container. When the agent retires, the clone retires with it.
The snapshot is retained for thirty days. The reproduction steps in the report point at a snapshot URL, so an engineer can re-run any payload on Monday against the exact state the agent saw on Sunday.
When the agent submits a thousand garbage payloads, they end up in a database that gets thrown away. No support ticket about a phantom user, no real refund accidentally credited, no audit log full of the agent's experiments.
The standard answer to 'we should pen-test the app' is a $40,000 annual engagement that covers two weeks of someone else's calendar. The canary runs every Sunday on the flat-rate Hoody server you already rent — cron is the trigger, not the billing unit.
Two two-week windows of an external pen-test firm scoping, scanning, and writing a PDF you read once. Findings six months stale by the time the next contract starts.
A managed Hoody Cron entry. A short shell script. The snapshot lives thirty days. The container exists for two hours. There is no firm to hire and no calendar to coordinate.
Cost framing. The $40k figure is a typical mid-market pen-test engagement, not a Hoody quote. The canary runs on the flat-rate server you already pay for; server cost is the same whether the agent runs two hours or twenty. The agent's LLM calls go through the Hoody AI Gateway (provider cost + 5% markup, drawn from AI Balance) or your own provider key (BYO path, provider bills separately). Two balances, firewalled: General Balance funds the server; AI Balance funds the gateway. A runaway agent can't drain your infrastructure budget.
Every Sunday morning, an agent earns its keep by trying to break what you built.
The standard tools when you want continuous adversarial pressure on your own product. Each one charges you a contract, a platform seat, or a bug-bounty marketplace. The canary runs on the flat-rate Hoody server you already pay for; the cron line is configuration, not a billing unit.
Wire the cron, point it at a snapshot, give the agent its prompt — and read the findings on Monday with your coffee.