Wazuh Deployment Guide for MSPs: Sizing, Clustering, and Costs

Wazuh is free to download and expensive to run badly. That's the part missing from most write-ups, which stop at the install command and leave out sizing, tenant isolation, agent rollout, and the tuning work that decides whether your techs trust the alerts or mute the channel. If you're weighing a self-hosted SIEM against a commercial one, the license fee is the least interesting number in the comparison. Here's what a real MSP deployment involves, what the hardware and staffing cost, and where buying wins instead.

TL;DR

What Wazuh Replaces, and What It Doesn't

Wazuh does four jobs that MSPs usually buy separately. It collects and correlates logs from endpoints, servers, firewalls, and cloud services. It runs file integrity monitoring on paths you define. It scans installed packages against vulnerability feeds. And it maps detections to compliance controls, with rule sets covering PCI DSS, HIPAA, NIST 800-53, and GDPR out of the box, which is why it shows up in so many audit conversations.

What it doesn't do is replace your EDR. Wazuh's agent collects telemetry and can trigger active responses like blocking an IP or killing a process, but it isn't a behavioral prevention engine with a research team behind it. Shops running Wazuh alongside a commercial endpoint agent are the norm, not a sign somebody bought wrong. Treat Wazuh as the SIEM layer and the compliance evidence store, sitting under whatever endpoint tooling you already sell.

That distinction matters for how you price it to clients. Wazuh answers the log retention and compliance reporting questions. It doesn't answer the 2 a.m. containment question on its own. The MSP security stack breakdown walks through where each of the six layers sits and what the commercial equivalents cost per endpoint.

Sizing the Deployment Before You Install Anything

This is where deployments go wrong, because the single-host install is easy enough that people skip capacity planning entirely and discover the ceiling in production.

Wazuh's published sizing guidance scales from 25 agents on a single node with 4 vCPU and 8 GB of RAM, up to roughly 100 agents on a single node with 8 vCPU and 8 GB. Past that, the documentation points you toward multi-node clustering rather than continuing to grow one box. Take that seriously. An MSP with fifteen clients averaging forty endpoints each is looking at 600 agents, which is cluster territory from day one, not something you grow into later.

Storage is the number people underestimate. Retention is the whole reason a compliance-driven client wants a SIEM, and log volume scales with what you enable. Turn on file integrity monitoring across a file server with active user directories and ingest climbs fast. Decide retention per client before you build, because retrofitting an indexer cluster with more disk while it's live is a maintenance window nobody enjoys.

Plan the three tiers separately: the manager nodes that receive agent data and evaluate rules, the indexer nodes that store and search it, and the dashboard layer your techs log into. On small deployments they collapse onto one host. On anything client-facing they shouldn't, because a dashboard restart taking down log ingestion is an availability problem you created for yourself.

The Multi-Tenant Architecture Problem

Wazuh wasn't designed multi-tenant first, and this is the single biggest gap between a lab install and something you can sell. A single-tenant deployment shows every alert from every client in one dashboard. That's a data segregation issue the first time a client asks who can see their logs, and a real problem if you're under any contractual confidentiality obligation.

The architecture that works for MSP use runs a manager cluster for high availability, with a primary node handling coordination and worker nodes distributing agent load. Behind it sits an indexer cluster with primary and replica nodes for storage and search. On top, you run multiple dashboard instances that give each tenant an isolated view, plus a separate operations dashboard for your own team's global oversight across all clients.

Two practical approaches. Run one Wazuh stack per client, which gives you clean isolation and a painful patching story once you pass ten clients. Or run one clustered stack with agent groups and index patterns per tenant, plus role-based access controls mapping each client to their own index, which is more work up front and far less work forever after. The second is the right answer for anyone planning to grow, and it's the one that needs designing before the first agent is deployed rather than after.

Whichever you pick, document the tenant boundary and how it's enforced. That document is what you hand an auditor, and it's what protects you if a client's counsel asks the question directly.

Agent Rollout Across Client Networks

Deploying the manager is an afternoon. Deploying agents to 600 endpoints across fifteen networks with different domain setups, different firewall rules, and different change control processes is the actual project.

Push agents through the RMM you already run rather than touching machines individually. The agent installer takes the manager address and an enrollment key as arguments, which makes it a scriptable package rather than an interactive install. Register agents into groups that match the client, because agent groups are how you scope configuration and how you keep one client's file integrity monitoring paths from applying to everybody.

Budget for the machines that resist. Older Windows Server builds, appliances you don't control, network gear that only speaks syslog, and any endpoint behind a NAT that blocks outbound 1514. Syslog forwarding covers most of the gear that can't take an agent, and it's worth configuring on the firewalls specifically, since perimeter logs are where you see the credential stuffing attempts that never reach an endpoint.

Then verify enrollment against your inventory rather than the Wazuh console. A console showing 580 active agents when the client has 600 billable endpoints is a twenty-machine blind spot, and those twenty are disproportionately the unmanaged ones that get compromised.

What Commercial SIEM Costs, and What Wazuh Costs Instead

Commercial SIEM pricing runs on ingest volume, which is why quotes vary so wildly between shops of similar size.

The Sentinel free-ingest tiers deserve attention if your clients are Microsoft 365 tenants, because a meaningful share of the logs you'd want are exempt from the per-GB meter. That changes the comparison for a small client more than any Wazuh optimization will.

On the Wazuh side, the honest accounting looks like this. There's no license cost and no per-GB meter, so ingest volume stops being a budget conversation. What replaces it is infrastructure and salary. Industry cost analyses put mid-market self-hosted infrastructure at $15,000 to $40,000 a year, and note that keeping a deployment of that size healthy typically assumes a dedicated engineer in the $130,000 to $160,000 range. Those same analyses put realistic year-one total cost for a 50 GB-per-day Wazuh deployment at $180,000 to $280,000 once both are counted.

Read those numbers in context. Fifty GB a day is a large enterprise deployment, not a fifteen-client MSP, and the engineer line assumes a full-time hire rather than a fraction of an existing tech's week. Scale it down and the picture for a typical MSP is a few thousand a year in compute and storage plus a meaningful slice of one senior person's time. That slice is the number to argue about internally, because it's the one that gets wished away in planning and then shows up as a tech who no longer has capacity for billable work.

The fair comparison isn't free versus expensive. It's a predictable per-GB bill you can pass through to clients versus a fixed infrastructure cost plus labor you absorb. Shops with a strong senior technician and clients who need long retention come out ahead on Wazuh. Shops billing every hour at capacity usually don't.

AI Threat Hunting With a Local LLM

The development worth knowing about is that Wazuh now supports AI-assisted threat hunting using locally deployed language models, which matters for MSPs specifically because it doesn't send client logs to a third-party API.

The setup pairs Wazuh's data with a local model such as LLaMA 3 running on Ollama, using vectorized log data and LangChain to connect them. The result is a chatbot embedded in the OpenSearch-based dashboard, where a technician can ask something like who attempted to exfiltrate files this week and get back specific events with timestamps, user identities, and attack vectors instead of writing the query by hand. Wazuh has also published work on agentic approaches, where the system plans and executes multi-step investigation rather than answering one question at a time.

For a technician who knows the environment but not the query syntax, that collapses the learning curve that keeps most Wazuh deployments underused. It also keeps the data local, which is the part that makes it sellable to a client with confidentiality requirements. Worth pairing with the broader picture in our AI agents for IT operations guide, since the same data pipeline feeds both.

Set expectations honestly with your team. A local model on commodity hardware is slower and less capable than a frontier API model, and it will occasionally summarize confidently and wrongly. Use it to accelerate investigation, not to decide whether something is a real incident.

Wazuh has previewed a 5.0 release without committing to a general-availability date, so plan around what's shipping today rather than what's on a roadmap slide.

Tuning Is the Part That Decides Whether This Works

A fresh Wazuh install generates a lot of noise. Level 3 and 5 rules fire constantly on normal Windows behavior, and a dashboard nobody trusts is worse than no dashboard, because it trains your team to ignore the one alert that mattered.

The work is unglamorous and it never fully ends. Raise the alerting threshold so only meaningful severities page anybody. Write exclusions for the specific noisy behaviors in each client environment, per agent group rather than globally, because the backup job that looks like mass file access at one client is genuinely suspicious at another. Route alerts into the ticket queue your techs already work instead of a Slack channel or an email alias, so a detection becomes tracked work with an owner.

Then review what fired weekly for the first couple of months. That review is the detection engineering job, it's the thing that has no vendor doing it for you, and it's the reason a named owner matters more than any architecture decision in this post.

Wazuh vs the Other Open-Source Options

Wazuh isn't the only free option, and the alternatives fail for different reasons in an MSP context.

Security Onion bundles network security monitoring with Zeek and Suricata alongside host logs, so it sees traffic Wazuh's agents never touch. The tradeoff is that it wants network taps or SPAN ports at each client site, which turns a software rollout into fifteen hardware conversations. Strong for a single monitored network, awkward across a client base.

OSSEC is the project Wazuh forked from, and Wazuh has since added the indexer, the dashboard, the vulnerability detection, and the compliance rule sets. Choosing OSSEC today means choosing a smaller feature set with a slower release cadence, which is why the comparison mostly settles itself.

Elastic and OpenSearch give you the storage and search layer without the security content. You get a log platform and then write the detection rules yourself. Wazuh essentially ships as that stack with several thousand rules and the compliance mappings already built, which is most of the value for a shop that doesn't employ a detection engineer. Graylog sits in similar territory, strong at log management and lighter on security-specific content.

For MSP use the deciding factor is rarely raw capability. It's how much security content arrives pre-written, because that content is the labor you're trying not to pay for.

When to Buy Instead

Self-hosting is the right call when you have a senior technician who wants to own detection, clients who need long retention or specific compliance evidence, and enough endpoint volume that per-GB pricing hurts. It's the wrong call when your team is fully booked on billable work, when nobody owns security as a named responsibility, or when you need 24/7 eyes on detections and don't have a night rotation. In that last case you're buying a managed service regardless, and the MSSP guide covers what that costs and where the handoff boundaries land.

There's also a middle path worth pricing: run Wazuh for collection, retention, and compliance reporting, and buy managed detection for the after-hours watch. You keep the storage economics and stop pretending a business-hours team covers a 24-hour threat window.

On the platform side, OpenFrame is where we've put our own work: an AI-native all-in-one MSP and IT platform with native PSA included, priced without multi-year lock-in. It isn't a SIEM and it isn't open source. What it does is give Wazuh's alerts somewhere useful to land, as tickets in the same queue your techs already work, with an audit trail attached. A detection nobody turns into a ticket is a log entry with extra steps.

Wazuh's license is free. The person who tunes it is not, and that's the line item to settle before you install anything.