task: measure the resource cost of the host-hardening baseline

[tucktuck101]

Parent PRD

#5

Objective

Produce a report, attached to this issue, recording the memory, disk and CPU overhead that a minimum internet-facing hardening baseline adds to a host with the cohort VPS's specification.

Definition of done

• The baseline under measurement is stated as an explicit package list before any measurement is taken
• Steady-state RSS is recorded for each added service individually, not only as a total
• Peak memory during an unattended-upgrades run is recorded — this is a spike rather than a steady cost, and is the measurement most likely to change the sizing verdict
• Peak memory is recorded with the hardening baseline and the full Buzz stack running together, since that combination is what the VPS must survive
• Additional disk consumed by the baseline, including log and journal growth over a stated observation window, is recorded
• The report states whether the combined footprint fits 1.9 Gi with 496 MB of swap, citing measurements rather than judgement
• Every measurement is taken on the spec-matched VM and the method is reproducible by a reviewer
• Any component in the stated baseline that was not measured is listed as unmeasured

Impacted components

launchpad/deploy/    will consume this report when host hardening is automated

No repository files change — this issue produces evidence, not code.

Out of scope

• Writing the hardening automation. This issue measures the cost of a baseline so # prd-03 — reproducible and hardened Buzz deployment: rebuild the cohort server from a bare Ubuntu host #5 can be sized; # prd-03 — reproducible and hardened Buzz deployment: rebuild the cohort server from a bare Ubuntu host #5 still implements it.
• Choosing the configuration management tool, which is an open question on # prd-03 — reproducible and hardened Buzz deployment: rebuild the cohort server from a bare Ubuntu host #5.
• Any claim that the measured baseline is sufficient hardening. This is a resource study, not a security review.
• Verifying that the controls work. Whether fail2ban actually bans belongs to # prd-03 — reproducible and hardened Buzz deployment: rebuild the cohort server from a bare Ubuntu host #5's post-deployment test suite.

---

_{Filed by an AI agent (Claude Opus 5) on behalf of @tucktuck101. Parented to #5 rather than #2 because #2 lists hardening as an explicit non-goal and defers it here; measuring what hardening costs is not "security controls as code", so it does not pre-empt #5's implementation scope either. Its output is what makes the sizing verdict for #2 trustworthy. Drafted, not executed — no measurement here has been run. Reparent if the cohort would rather this sat under #2.}

[serina-mcfall]

PRD #5 (this issue's parent) closed 2026-08-17 and moved wholesale to the private launchpad-26/buzz-infrastructure repo per ADR-0016 — that repo's #23 is explicitly "a private mirror of #5". The hardening-cost measurement this issue asks for is superseded there by the CIS L1 batches already applied and closed (buzz-infrastructure#88, #89, #90), against a different baseline than the one this issue was scoped to measure. Ongoing classification work continues at buzz-infrastructure#41.

🤖 Closed by Claude Code, from a QA triage pass over open issues in this repo, reviewed and directed by @serina-mcfall.