Host-Based Detection Part 4: Standing Up a Manager, Two Different Ways
Two Wazuh managers already exist on this site’s infrastructure, built for two genuinely different reasons, and the contrast between them is a better lesson in sizing and placement than building a third one from scratch would be.
The homelab manager: one shared instance, deliberately not Debian
From Dropbox to Daily Driver Part 6 built a single, shared, all-in-one Wazuh manager on pve specifically so a hardened Raspberry Pi would have somewhere to ship logs to, but scoped it deliberately larger than one Pi needs. Wazuh’s own documented all-in-one profile, manager, indexer, and dashboard together on one host, is comfortable up to 100 agents and 90 days of indexed retention, so building to that spec once means anything else in the homelab wanting centralised logging later has somewhere to plug into, rather than a second manager getting stood up every time something new needs watching.
The genuinely useful decision in that build wasn’t the sizing, it was the OS choice. Every other VM on that pve host is Debian. This one is Ubuntu 24.04 LTS, on purpose. Wazuh’s .deb packages install cleanly on Debian, and there’s no specific reason to expect a problem, but Wazuh’s own certified support matrix lists Ubuntu, RHEL, CentOS Stream, and Amazon Linux, not Debian. For a one-off lab VM, that distinction wouldn’t matter much. For a piece of permanent, shared infrastructure that’s meant to keep running and keep getting upgraded for years, building on the platform actually covered by a vendor’s own support matrix, rather than the platform that would probably also work, is the more defensible call. That’s a real, general lesson worth carrying into any future “just run it on whatever the rest of the fleet already uses” decision: check the support matrix before assuming consistency with the rest of your homelab is the more important variable.
The lab manager: dedicated, isolated, disposable
Old Kit, New Kit took the opposite approach on purpose: a second, entirely separate Wazuh manager, built specifically for an isolated Proxmox pentest range and never shared with the homelab instance from Part 6. The reasoning is placement, not capability. A pentest lab’s targets are deliberately vulnerable, sometimes deliberately compromised on purpose as part of testing a tool pair, and a manager watching them sits one hop away from whatever’s actually running on those hosts. Sharing that manager with the one watching genuinely trusted production infrastructure would mean a single compromised lab target has a plausible path toward the same instance holding real homelab security data, exactly the kind of pivot-path risk this site’s own Pivoting and Tunneling series spent a whole series on. Two managers, two blast radii, is the safer trade even though it means running Wazuh twice and never getting the one-pane-of-glass convenience a single shared instance would offer.
The decision, generalised
Building a manager comes down to answering one question honestly: is this watching infrastructure you trust, or infrastructure you’re deliberately putting at risk. A shared, well-sized, all-in-one instance is the right answer for the first case, built once, on a supported OS, big enough that nothing else needs its own. A dedicated, disposable instance is the right answer for the second, kept small, kept isolated, and never sharing a blast radius with anything that actually matters. Both already exist here. Part 5 of this series covers what actually gets enrolled into each.