Wazuh has no licence fee. That is the easy part of the answer and it is also why the question keeps being asked badly. The real Wazuh cost is people first, engineering second, infrastructure third, and that ratio does not change with scale. This page is a framework for deciding whether to build a Wazuh-based SOC, buy one, or stage the decision, written for whoever signs off the budget rather than whoever runs the console.
What you need
- A realistic count of endpoints, and whether they include servers, cloud accounts and network devices or only laptops.
- An honest answer to one question: does an alert at three in the morning need a response before nine.
- A view of what you are trying to achieve. Compliance evidence, threat detection and incident response are three different products, and only one of them needs a rota.
- If you are still deciding on the tool itself rather than the operating model, start with Wazuh compared with the alternatives.
Where the money actually goes
Set the licence line to zero and everything else stays. Five cost centres carry a Wazuh deployment for its whole life.
Infrastructure. Compute and storage for the indexer, manager and dashboard, growing with data volume and retention. This is the most visible cost and usually the smallest of the five.
Build. Designing the deployment, installing it, integrating identity, wiring log sources, setting retention, hardening the stack. Concentrated at the start, and mostly one-off.
Tuning. Turning raw output into a queue a human can work. This is where inexperienced teams badly underestimate, because the first weeks after deployment feel productive and the deployment is nowhere near usable yet. Tuning never quite ends; it drops to a trickle and then spikes whenever a new source arrives.
Operations. Someone reading and acting on what the system produces. This is the dominant cost in any deployment that claims to do detection and response, and the one that decides the build versus buy question by itself.
Upkeep. Patching the stack, minor version upgrades, keeping detection content current as threats and your estate change, and periodically the sort of version transition that version 5 represents.
The order matters. If you are comparing self-hosting against a service on infrastructure cost, you are comparing the two smallest numbers in the calculation.
Infrastructure scales predictably, and stays modest
This is the one cost centre that behaves the way people expect. It rises with data volume and retention, it is easy to model, and for most organisations it stays small relative to a single engineer’s time.
Wazuh publishes the hardware guidance. The manager wants a minimum of 8 GB of memory and 4 cores, with 16 GB and 8 cores recommended, and at least 20 GB of disk because the vulnerability feed alone needs 15 GB. An all-in-one deployment handling up to twenty-five endpoints is documented at 4 vCPU and 8 GiB; up to a hundred endpoints at 8 vCPU and 16 GiB, with storage rising as retention rises. Beyond that the guidance is a distributed deployment with clustering on both the manager and the indexer.
The variable that actually drives the bill is not endpoint count, it is events per endpoint per day multiplied by how long you keep them. A thousand quiet workstations can cost less to store than fifty chatty servers. Measure your own volume once running rather than sizing from a table, as covered in Wazuh system requirements and sizing.
Version 5 changes the arithmetic. Every event is indexed, not only the ones that matched a rule, which is why the shipped retention on the raw and normalised event streams is measured in minutes and hours while findings are kept for months. Retention policy stops being a background setting and becomes a budget decision that someone has to own.
People time is the real number
Split it by phase, because the shape is uneven and a single annual figure hides the risk.
Build. Weeks, not months, for a competent engineer on a standard estate. Longer if identity integration, network segmentation or multiple cloud accounts are in scope. Front-loaded and finite.
Tune. The phase that decides whether the investment survives. An untuned deployment produces a volume of low-value output that trains the team to ignore it, and a queue nobody reads is worse than no queue, because it carries the appearance of coverage. Budget dedicated time here, not spare capacity, and keep a named owner. The method is in cutting false positives without going blind.
Operate. The step change. Business-hours monitoring by an existing team is an increment to someone’s week. Round-the-clock coverage with response is a rota, and a rota is several people, with holiday, sickness, attrition and handover. There is no gradual path between those two states, which is precisely why the decision is binary and why it should be made deliberately rather than discovered.
Maintain. A steady background load: patching, version upgrades, new log sources, detection content upkeep, periodic review of what is still worth alerting on. Small per month and easy to defer, which is how deployments silently rot.
The costs that do not appear in the plan
Tuning debt. Every noisy rule left unaddressed is interest paid daily in analyst attention. It compounds quietly and shows up as a team that has stopped looking.
Key-person risk. Small deployments concentrate in one engineer who understands the detection logic and the quirks. When that person leaves, the organisation discovers how much of the system was undocumented. This risk is the most commonly ignored and among the most expensive to realise.
On-call. Not only the rota cost, but what it does to the people on it. Attrition driven by a bad on-call experience is a real cost and it lands in a different budget line from the tool.
Content upkeep after a major version. Version 5 moves detection to Sigma-format YAML rules evaluated on the indexer, and there is no conversion tool for existing custom XML rules and decoders. Every piece of custom content an organisation has written is re-authored by hand. Whatever that inventory looks like, it is a one-off engineering project that has to be scheduled, and it is described in the 4.x to 5 migration runbook.
Integration maintenance. Ticketing, chat, automation and reporting connections break when either side changes. In version 5 they move to indexer alerting monitors and notification channels, so existing integrations are rebuilt once during the transition and maintained thereafter.
Evidence production. If the deployment exists partly to satisfy an auditor, someone assembles that evidence periodically. That work is real and it belongs in the operating cost, not in a project budget.
A framework by size and maturity
Size alone is a poor guide. Pair it with whether the organisation already employs someone who can own a detection platform.
| Profile | Security staff | Realistic option | Why |
|---|---|---|---|
| Small organisation, compliance-driven | None dedicated | Buy, or deploy narrowly for evidence only | Nobody will read the queue. A deployment that produces evidence and nothing else is honest and cheap; one that claims detection without an operator is neither |
| Small to mid, one security-capable engineer | One generalist | Build for visibility, buy the watching | Self-hosted tooling owned internally, with external coverage outside working hours, avoids paying for a rota before the estate justifies it |
| Mid-size, small security team | Two to four | Build, if response outside hours is not required | Enough people to own tuning and content. Coverage gaps are the constraint, not capability |
| Mid to large with round-the-clock requirement | Team plus rota | Either, decided on staffing not tooling | The tool is the cheap half. Ask whether you can recruit and retain a rota before assuming you can run one |
| Large, existing mature SOC | Established function | Build | Wazuh becomes one telemetry source among several, operated by a function that already exists. Control and cost both favour self-hosting |
| Regulated with data residency constraints | Varies | Build, or buy from within the jurisdiction | Where data may sit can override the economics entirely, and it is the first question to settle, not the last |
| Service provider serving multiple clients | Varies | Build, with tenancy designed in from the start | Multi-tenancy is an architecture decision made once. Retrofitting it is expensive, as multi-tenant Wazuh for MSSPs sets out |
When self-hosting is the cheaper answer
- You already employ people who operate infrastructure and read logs, and adding a platform is an increment rather than a new function.
- Coverage is required during working hours only, and you are content to accept the overnight gap explicitly rather than pretend it away.
- Data residency, contractual or regulatory constraints make external processing awkward or slow to arrange.
- The estate is unusual enough that most detection value will come from content you write yourself. Custom content is where self-hosting pays back hardest.
- You intend to keep the capability for years. Build costs amortise; a short horizon does not.
When buying is the cheaper answer
- Round-the-clock response is a requirement rather than an aspiration. The cost of a rota is the whole argument.
- There is no internal owner today and no plan to recruit one. Tooling without an operator is a purchase, not a capability.
- The board wants coverage this quarter. Building to a usable state takes longer than most sponsors expect, and the gap between deployment and usefulness is where projects lose their backing.
- Detection content and threat intelligence upkeep is work your organisation has no reason to do itself.
- You need someone accountable for the outcome. Internal teams carry the work; a contract can carry the obligation.
Questions to settle before deciding
Ask these in the room where the budget is approved, not afterwards.
- What are we buying: compliance evidence, visibility, or detection and response? Only the third needs a rota.
- Who reads the output on a Sunday, and what are they allowed to do about it?
- Who owns tuning, by name, and how much of their week is protected for it?
- What happens when that person leaves?
- How much data do we generate now, how fast is it growing, and how long must we keep it?
- What is our time-to-usable, and does the sponsor understand that deployment is not the finish line?
- If we build and it does not work, what is the exit, and how much of the work transfers?
A hybrid answer is often the right one and it is rarely offered. Owning the platform while buying the watching keeps the data and the detection logic in-house, keeps costs proportionate to the estate, and removes the rota problem. It also leaves a clean path to bringing coverage in-house later, because the deployment is already yours.
Whichever way the decision goes, cost it as an operating capability with people attached, not as a piece of software. Managed SOC services built on Wazuh exist if the internal rota is the blocker.
The Wazuh quickstart page carries the current hardware and operating system guidance if you are sizing a build.
Next: Wazuh Commands Cheat Sheet.
Frequently asked questions
Is Wazuh really free?
The software is open source and there is no per-endpoint or per-gigabyte licence fee. The cost sits in infrastructure, in the engineering time to deploy and tune it, and above all in the people who watch it. Organisations that budget only for the servers are the ones who abandon the project within a year.
What drives the cost of running Wazuh?
Three things, in order: the staff time to operate and respond, the engineering time to tune detections and maintain content, and the infrastructure to store and search the data. Data volume drives the third and indirectly the second, because more data with the same tuning means more noise to work through.
Is a managed Wazuh service cheaper than self-hosting?
It depends almost entirely on whether you need coverage outside working hours. Self-hosting is usually cheaper when the tool serves a single team during business hours. A managed service is usually cheaper once round-the-clock response is required, because the cost of staffing that internally is a step change, not a gradual increase.
How many people does it take to run a Wazuh SOC?
For visibility and compliance evidence during working hours, part of one competent engineer's week can sustain a tuned deployment. For genuine round-the-clock monitoring with response, you are staffing a rota, and that is a different order of commitment. Be honest about which one you are actually buying.
Does the move to Wazuh 5 change the cost picture?
It adds a one-off cost and shifts an ongoing one. The one-off is the migration, which includes re-authoring every custom rule and decoder by hand because there is no conversion tool. The ongoing shift is that version 5 indexes all events rather than only rule matches, so storage planning and retention policy carry more weight than before.