WanderingMonster packaging report: don't package
Wazuh — Cloudron Packaging Assessment
Verdict: Don't package. Wrong category, wrong scale, wrong topology. Wazuh is an open-source SIEM/XDR platform — a security infrastructure stack for monitoring fleets of endpoints, not an app a Cloudron operator runs alongside Nextcloud and a wiki. The URL points to the Wazuh GitHub organisation, which contains dozens of repos that together compose the platform. Even the smallest sensible deployment is a multi-node cluster sized in tens of GB of RAM. This belongs on dedicated infrastructure, not on Cloudron.
What Wazuh actually is
A free, open-source security monitoring platform — log analysis, intrusion detection, file integrity monitoring, vulnerability detection, configuration assessment, and regulatory compliance reporting (PCI-DSS, HIPAA, GDPR, NIST). It originated as a fork of OSSEC and now ships as a four-part stack:
Component
What it does
Repo
Wazuh Manager (Server)
Receives data from agents, runs detection rules, generates alerts. C + Python daemons (ossec-analysisd, ossec-remoted, wazuh-modulesd, etc.)
wazuh/wazuh
Wazuh Indexer
Search and analytics backend. A fork of OpenSearch, which is itself a fork of Elasticsearch. JVM-based.
wazuh/wazuh-indexer
Wazuh Dashboard
Web UI. A fork of OpenSearch Dashboards, which is itself a fork of Kibana. Node.js.
wazuh/wazuh-dashboard
Wazuh Agents
Lightweight collectors installed on every endpoint you want to monitor (Linux, Windows, macOS, AIX, Solaris, Docker, K8s).
wazuh/wazuh
The Cloudron operator would only ever package the first three. The agents live on the machines being monitored, which is the whole point.
Auto-Detected Axes
Axis
Score
Notes
Data
2
The Wazuh Indexer (OpenSearch fork) is the database. There's no Cloudron addon for OpenSearch — it must run inside the container, with its data on /app/data. Indices grow continuously and unboundedly with log volume.
Runtime
2
C, Python, Java 11+ (indexer + dashboard's bundled JVM), Node.js. Java is not in cloudron/base:5.0.0 and would need to be installed via apt.
Broker
0
None per se, but the manager-to-indexer pipeline acts as one (Filebeat by default).
Processes
8+
A non-exhaustive count: ossec-analysisd, ossec-remoted, ossec-monitord, ossec-execd, wazuh-modulesd, wazuh-db, the Wazuh API (Python aiohttp), Filebeat, the OpenSearch JVM, the OpenSearch Dashboards Node process, Nginx in front. Supervisor mandatory and complex.
Manual Axes
Filesystem writes
Wazuh Manager state and rules → /app/data/wazuh/{etc,logs,queue,stats,var} — extensive, every daemon writes constantly.
Indexer (OpenSearch) data → /app/data/indexer — this is the elephant. Tens of GB minimum, hundreds with real fleets.
Dashboard config and saved objects → /app/data/dashboard.
TLS certificates → Wazuh uses internal mTLS between manager, indexer, and dashboard. Generate on first boot, store under /app/data/certs.
Authentication
Wazuh has its own user system in the Indexer's security plugin (RBAC, internal users, role mapping). LDAP integration exists but is more involved than typical Cloudron ldap addon wiring — the security plugin's config files want OpenSearch-style YAML. SSO via the Cloudron oidc addon is theoretically possible but is days of work, not hours.
Memory — the dealbreaker
Realistic per-component minimums for a single-node, single-tenant, evaluation-grade deployment:
Indexer (OpenSearch JVM): 4 GB heap minimum. 8 GB is the documented production floor.
Dashboard (Node + bundled Chromium for reports): 1 GB.
Manager + daemons + Filebeat: 2 GB.
OS / cache headroom: 1 GB.
Floor: 8 GB. Wazuh's own documentation specifies 16 GB / 8 vCPU as the minimum for an all-in-one deployment, scaling rapidly with agent count and EPS (events per second). Set memoryLimit: 16384 and warn loudly. This is not a 256 MB sidecar.
Disk
Indices grow with retained log volume. A small deployment (10 agents, 30-day retention) is in the tens of GB. A real one is hundreds of GB to terabytes. Every byte sits under /app/data and is therefore included in Cloudron backups — meaning the backup pipeline has to move all of it on every snapshot. This alone makes Cloudron the wrong substrate.
Process count — 8+, Supervisor mandatory
Boot ordering is delicate: certificates must exist → Indexer must be up and have its security index bootstrapped → Manager can register and start Filebeat → Dashboard can connect. Each of these has a cold-start time measured in minutes; the Cloudron healthcheck must serve 200 from Nginx immediately or the platform will kill the container before the stack is up.
Agents — the architectural mismatch
Wazuh's value comes from running agents on the machines you want to monitor. Those agents connect inbound to the Manager on TCP/UDP 1514 (encrypted) and 1515 (enrolment). Cloudron only routes HTTP(S) on the app's domain through its outer Nginx. There is no first-class way to expose arbitrary TCP ports per app — any agents would have to connect over the host's IP directly, bypassing Cloudron's routing model. This is the structural reason Wazuh doesn't fit Cloudron, independent of memory or process count. A SIEM that can't accept agent connections is a dashboard for an empty database.
Why this isn't a Cloudron app
Cloudron is a personal-server PaaS. Its sweet spot is Nextcloud, a wiki, a blog, a chat server — single-tenant web apps with modest footprints. Wazuh is enterprise security infrastructure. The two have approximately nothing in common operationally.
Resource floor exceeds typical Cloudron host capacity. A real Wazuh deployment alone would dwarf the rest of an entire Cloudron server's apps combined.
Multi-port ingest doesn't fit the platform model. Even if you crammed the three server components into one container, the agents have nowhere to connect.
Backup pipeline mismatch. Cloudron backups assume gigabytes, not terabytes; OpenSearch indices want their own snapshot lifecycle (snapshot-to-S3, ILM policies), not filesystem rsync.
Upstream ships its own deployment tooling. Wazuh's installation methods are an all-in-one bash script, distribution packages (rpm/deb), an official Docker Compose stack, Ansible roles, Puppet, and Kubernetes manifests. None of this is shaped like a Cloudron package, and there is no upstream interest in making it so.
It's a fork-of-a-fork. Wazuh Indexer is a fork of OpenSearch, which is a fork of Elasticsearch. Wazuh Dashboard is a fork of OpenSearch Dashboards, which is a fork of Kibana. Tracking upstream security patches across that lineage is an ongoing maintenance burden that doesn't make sense for a single packager.
Recommendation
Don't package this. If you want SIEM/log monitoring on a Cloudron-class machine, the realistic options are:
Run Wazuh on its own host using the official wazuh-docker Compose stack on a dedicated VM (4–8 vCPU, 16 GB RAM minimum), and let it monitor your Cloudron box as one of its endpoints by installing the Wazuh agent on the Cloudron host. This is the deployment shape Wazuh was designed for.
Use a lighter alternative if your needs are modest. CrowdSec is closer to Cloudron-scale (small Go agent, optional local API, modest RAM) and there's existing community interest in packaging it. Graylog, Loki + Grafana, or even plain journald + rsyslog forwarding cover the "I want to see my logs in one place" use case at a fraction of the footprint.
For endpoint hardening on the Cloudron host itself, install a Wazuh agent on the host OS pointing at an external Wazuh manager. The agent is lightweight (~50 MB RAM) and runs fine alongside Cloudron without needing to be a Cloudron app.
If you're absolutely set on running Wazuh "near" Cloudron, the right shape is a separate VM on the same hypervisor or LAN — not a Cloudron app.
Reference
Packaging conventions and templates: forgejo.wanderingmonster.dev/WanderingMonster/cloudron-packaging.
