Runs on the Gateway VPS (/opt/stacks/crowdsec/) in LAPI mode, paired with Caddy's native bouncer module (caddy-cs-bouncer) — malicious traffic gets blocked directly at the edge, not via a separate firewall rule sync step.
3 local custom scenarios live in hot-config/gateway/crowdsec/scenarios/, on top of the standard collections:
hot/admin-scan — multi-path scan detectionhot/forgejo-bf — Forgejo brute-forcehot/keycloak-bf — Keycloak brute-forcehot/vaultwarden-bf — Vaultwarden brute-force (added after /identity/connect/token's 400-on-bad-login response turned out to be uncovered by the standard generic-401/403 scenarios)Ban notifications post to Ntfy via gateway/crowdsec/notifications/http.yaml.
Runs on sn-security (wazuh.house-of-trae.com) — manager, indexer, and dashboard. All 7 non-manager fleet hosts run an enrolled agent (Gateway, hot-bm-nl, sn-infra, sn-web, sn-monitor, hot-pn, hot-erp-nl), reporting back to the manager on sn-security.
sn-security is permanently capped at 2 vCPU (not the originally-planned 4) — hot-bm-nl hangs at guest SMP bring-up above 2 vCPUs, a real limitation of its nested-virtualization depth. Real-world impact is negligible: the VM idles at 0.06–0.21 load average even with the full Wazuh stack running.
CrowdSec's ban notifications and Wazuh's own signals feed into the same alerting architecture documented on Backups & Alerting — severity determines whether it's email-only, Ntfy, or escalates to SMS. Wazuh itself has no direct Ntfy integration; its only external path beyond its own dashboard is PrivateNexus's Security Lockdown Mode webhook, for level ≥10 events.