Wazuh cost of ownership: self-hosted vs Wazuh Cloud

Each of the four Wazuh components carries a different share of the infrastructure and staff cost of a self-hosted deployment, and the license-free software does not change that. The Wazuh indexer is a full-text search and analytics engine that stores alerts, and it is usually the largest storage consumer in the stack. Its disk footprint grows with the volume of events you keep and how long you keep them, so retention policy is a cost decision as much as a compliance one. Before you compare any vendor quote, confirm with your own team how many events per second you expect from your agents and which indexes you intend to keep online. The Wazuh server analyzes agent data with decoders and rules, and it is the component that turns raw events into alerts. Its compute load follows the number of enrolled agents and the event rate, so it is usually sized in CPU and memory rather than disk. The server can run as a cluster for horizontal scaling, which means you can add nodes as the estate grows instead of replacing one large machine. Clustering adds its own operational work, including node health monitoring and balancing, so ask any partner or internal team to price the single-node option and the clustered option separately. The Wazuh dashboard is the web interface that analysts, auditors and administrators use daily. Its own infrastructure cost is modest, but the number of users, saved searches and prebuilt compliance views you rely on affects how much query load lands on the indexer. The Wazuh agents run on endpoints and report to the server, and the server manages their configuration and upgrades remotely. That remote management reduces visits to individual machines, but it does not remove the work of deciding which agent groups exist, which configuration each group receives and when agents move to a new release. Those decisions are staff time, and staff time is often the largest recurring cost you will not see on an infrastructure invoice. For detailed numbers on indexer nodes, disk sizing and retention windows, use the sibling topic on Wazuh indexer sizing and data retention rather than estimates from this page. When you request a quote for a self-hosted build or compare it with Wazuh Cloud, ask each party to state the assumed event volume, retention period, number of agents and the staff hours they assume for upgrades and rule maintenance. Without those four inputs, two cost comparisons cannot be read side by side.

Teams should keep the decisions that only they can make: the business case for leaving or staying with a managed service, the data classification and retention rules that set how much alert data must be kept and for how long, and the final approval of the budget. These decisions depend on information that sits inside the organization, such as which log sources fall under regulatory retention, who signs off on risk acceptance, and how much operational risk the business will carry if an internal stack has an outage. An outside partner can frame the options, but the accountable owner should write down the assumptions and approve them. Skills needed here are mostly governance and finance: a security leader who understands the regulatory obligations, a compliance lead who can map retention periods to those obligations, and a finance owner who can judge total cost against the organization's budget cycle.

The work that teams most often outsource is the technical cost modeling that depends on measured data. Sizing with real event samples means collecting a representative window of agent and syslog traffic, measuring events per second and average event size, then projecting indexer storage, server capacity and dashboard load from those numbers. Building the cost model means turning those measurements into line items for compute, storage, backup, network and staff time. Both tasks need Linux administration to run the collection and read system metrics, search cluster operations knowledge to interpret indexer shard and storage behavior, and SIEM content engineering to judge how much rule tuning will change alert volume. A partner that has run these exercises across several environments can usually shorten the work, but the client must supply the sample data.

The comparison against Wazuh Cloud tiers needs cloud finance and vendor-management skills alongside the technical model. Wazuh Cloud is sold in Small, Medium, Large and Custom tiers, and every paid plan includes at least Standard support. Ask the vendor for the tier limits that apply to your measured event volume, the retention and data residency terms, what support level is included, and what is excluded, such as custom integrations or onboarding help. Then compare these against the self-hosted model, where the Wazuh software has no license fee but the infrastructure, storage, backup and staff time all carry cost. Confirm which items each option includes so the comparison is like for like. The free 14-day trial of Wazuh Cloud, which needs no credit card, can help validate assumptions about ingestion before a commitment.

The upgrade effort estimate is another task that teams often hand to a partner, because it depends on how much custom content the environment carries. Wazuh has released several 4.14 patch versions in 2026, including 4.14.8 on 23 September 2026 and 4.14.9 on 14 October 2026, so the team should expect recurring upgrade work on the four components: the indexer, the server, the dashboard and the agents. The effort depends on the number of custom decoders and rules that must be retested, the number of agents, and whether upgrades run in a test environment first. Self-hosted operators pay this effort in staff time every year. Managed service customers shift much of it to the vendor, but should confirm in writing which upgrades are included and how long the vendor needs to apply them.

Before finalizing the decision, the team should ask for a written quote that separates one-time costs, such as sizing, migration and initial configuration, from recurring costs, such as infrastructure, storage growth, patch cycles and support. The quote should state the assumptions used for event volume, retention period and agent count, and it should name who performs each task. Plan for risks that are easy to miss: storage growth when retention rules change, the cost of a second environment for testing upgrades, and the loss of internal knowledge if one engineer owns the stack. Each of these should appear as a line item or a documented assumption in the model, so the approval decision rests on numbers the organization can defend.

An accurate comparison between self-hosted Wazuh and Wazuh Cloud starts with a complete inventory of what will be monitored. List every agent target with its operating system and version, grouped by Linux, Windows, macOS and any other platforms in scope. Add the agentless sources you expect to collect through syslog or periodic API probing, such as firewalls, load balancers and cloud control planes. The number of endpoints drives agent licensing on managed plans, agent counts on the server side and the storage the indexer needs, so approximate counts by platform and by environment (production, staging, development) are the minimum. Ask whether any hosts are air-gapped or behind restricted egress, because that affects both deployment choices and whether the offline vulnerability repository must be planned. Next, provide event volume. Current event volume estimates from your existing SIEM, log platform or endpoint tooling are the best input. If you do not have totals, export a representative sample covering a normal business week and a peak period, such as month-end processing or a patch cycle, and record events per second and daily gigabytes by source type. Without that data, both the self-hosted storage estimate and any Wazuh Cloud tier selection rest on guesswork. Also state which log sources are high-volume, such as proxies, domain controllers or cloud audit trails, because they often change the answer more than the endpoint count does. Retention is the third input and the one most often left vague. Write down the minimum retention period for alerts, raw archived events and audit logs as set by internal policy, contract terms and each regulation that applies to you. Note whether any data must remain in a specific country or region, and whether any system must be restricted to on-premises infrastructure. Identify the existing identity provider and its owner, since SAML single sign-on planning affects configuration effort in either model. Confirm whether your identity provider supports one of the documented Wazuh guides or whether you will need a generic SAML setup. Finally, name the people who will own each cost. Infrastructure, security operations and finance each need a named owner: infrastructure for hosts, networks, backups and patching, security operations for rules, alert handling and on-call, and finance for the three-year view of spend. Decide who approves a Wazuh Cloud trial, which runs for 14 days without a credit card, and what success criteria the trial must test, such as ingestion of your sample data and a dashboard review by analysts. If you are replacing an existing SIEM or log platform, gather its current license, storage, support and staff costs now, because those figures are the baseline against which any Wazuh option must be compared.