What a Wazuh implementation involves
A Wazuh rollout is four components working together, and the plan starts by deciding where each one runs. The Wazuh indexer is the full-text search and analytics engine that stores alerts. The Wazuh server decodes and analyzes agent data with decoders and rules, and it can run as a cluster when event volume grows. The Wazuh dashboard is the web interface analysts use, and the Wazuh agents on endpoints collect the data that feeds everything else. Devices that cannot run an agent, such as firewalls, can send syslog to the server and be polled through their APIs, so the source inventory should list agent and agentless feeds separately.
The software itself carries no license fee. Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with OpenSSL, so the cost of a self-hosted deployment sits in three places: infrastructure for indexer storage, server compute and dashboard hosting; build effort for decoders, rules, identity integration and any offline vulnerability repository; and staff time to operate the stack. Build effort is mostly one-time, although custom content needs review after each upgrade, while infrastructure and staff time recur. Ask any partner to break its quote into these lines so you can compare it with your own estimate.
Four situations usually start a project. Teams replacing an existing SIEM need to map current alerts, log sources and retention rules before cutover. Teams consolidating endpoint visibility usually want agent coverage across Linux, Windows and macOS with one inventory. Compliance pressure, often from PCI DSS, HIPAA or NIST 800-53 obligations, creates a need for evidence and dashboards that map to specific requirements. The fourth is a team with no security analytics platform at all, where the first job is deciding what to collect before any tuning begins. Each trigger changes the scope, so name the one driving the project before you ask for a quote.
A capable platform team can build Wazuh in-house if it already operates distributed search clusters, is comfortable with Linux and configuration management, and can assign someone to write and tune rules after go-live. A partner makes more sense when the deadline is fixed, sources span several business units, SAML integration or offline operation is required, or nobody owns detection content. Whichever path you choose, DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the findings.
What the work includes
A typical Wazuh engagement moves through a fixed set of workstreams, each ending in a document or working configuration you keep. The list below shows what you receive at each stage so you can judge a partner's scope against your own team's effort.
Architecture and sizing
We size the Wazuh indexer, server and dashboard against your agent count, event rate and retention requirement, and choose between a single-node and clustered layout. The deliverable is a sizing record listing node counts, storage, network paths and the assumptions behind them. Check that the record states the event volume it was built on, because sizing errors usually come from that input.
Installation on your chosen platform
We install the stack using the deployment option you select, such as the all-in-one or step-by-step installation, the OVA, an Amazon Machine Image, Docker, Kubernetes, Ansible or Puppet. The deliverable is a configuration baseline and a rebuild procedure that your team can rerun. Confirm which options your environment supports and whether an offline installation is required.
Agent enrollment and grouping
We enroll agents across Linux, Windows and macOS hosts, then assign them to agent groups that carry centralized configuration for each server or workstation role. The deliverable is a tested agent coverage report that lists enrolled hosts, groups and any gaps. Ask how unreachable endpoints and agents running unsupported operating systems will be tracked.
Log source onboarding
We connect each log source, including agentless devices such as firewalls that send syslog to the Wazuh server and are polled through the API where supported. The deliverable is a log source register with the collection method, decoder status and owner for every source. Check which sources need custom decoders, because those add work that a standard onboarding list does not show.
Dashboard and compliance views
We configure dashboards and enable the prebuilt compliance views for the frameworks your auditors use, such as PCI DSS, HIPAA or NIST 800-53. The deliverable is a dashboard pack with a note of which control mappings it covers and which were left for your team to validate. Confirm with your assessor which mappings they accept as evidence before go-live.
Access setup
We set up dashboard users, roles and, where you need it, SAML single sign-on with your identity provider, mapping identity groups to administrator and read-only roles. The deliverable is an access matrix and a record of the default credentials that were changed. Ask who holds the administrator role after handover and how role changes will be reviewed.
Handover and runbook
We hand the environment to your operations team with a runbook covering upgrades, backups, agent rollout and day-to-day alert triage. The deliverable is the runbook, a tested restore record and a training session for the staff who will run the platform. Ask whether the runbook is kept in your repository and who maintains it after the engagement ends.
What drives effort and cost
This table lists the scope drivers that change the effort of a Wazuh rollout, why each one matters and how to keep it under control, since the fixed-scope price is set by the written scope.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Endpoints and operating systems | Each agent platform (Linux, Windows, macOS, Solaris, AIX, HP-UX) needs its own package, enrollment method, grouping and testing. Mixed fleets add packaging and validation work and more agent groups to maintain. | Group endpoints by OS and role, retire unsupported hosts before enrollment and standardize on fewer platforms where the business allows. |
| Event volume and retention period | Volume sets indexer node count, storage and query performance tuning. Longer retention multiplies disk needs and adds archive and restore work, and it changes how sizing is validated. | Measure real event rates during a pilot, filter low-value events at the source and set retention per data class instead of one global period. |
| Log sources, including agentless devices | Agents need installation and configuration. Agentless devices such as firewalls depend on syslog collection and periodic API probing, which needs parsing, network paths and per-device testing. | Inventory sources early, prioritize those that serve compliance or detection goals and defer low-value devices to a later phase. |
| Deployment target | A single node is the simplest build. Multi-node server and indexer clusters, Kubernetes, Docker, or an air-gapped install using the offline guide each add design, automation, image or repository, and verification steps. | Pick the target that matches real capacity needs, and confirm air-gapped requirements, including the offline vulnerability repository, before the design is written. |
| SAML single sign-on scope | Connecting the dashboard to a SAML identity provider involves IdP configuration, group-to-role mapping, testing for each user population and coordination with your identity team. Scope grows with the number of identity providers and role models. | Limit the first release to one identity provider and a small set of roles, then extend once the mapping is proven. |
| Custom decoders and rules | Each custom decoder or rule needs writing, testing against sample logs, tuning of alert levels and a regression check after every Wazuh upgrade. Effort grows with the number of log formats and detection use cases. | Start from prebuilt decoders and rules, document each customization with an owner and a purpose, and keep a shared test log set. |
| Number of environments (lab, staging, production) | Each environment needs its own installation, configuration, agent enrollment and test cycles. Keeping configuration aligned across environments is a recurring task that grows with the number of environments. | Use one automated, versioned configuration for all environments and keep the lab small, with only the sources needed for testing. |
| Compliance framework views in scope | Mapping rules and dashboards to PCI DSS, GDPR, HIPAA or NIST 800-53 needs requirement mapping, evidence design and review by your compliance lead. Each framework adds mapping and evidence work, and assessors decide what is sufficient. | Confirm with your assessor which frameworks and evidence formats apply, then limit the first scope to the framework with the nearest deadline. |
Project phases and outputs
The sequence moves from agreed requirements to a tested lab, a proven pilot, a production build and a handed-over, supported Wazuh deployment inside your own infrastructure.
Confirm requirements and scope
DeployOpen runs discovery workshops with your security, infrastructure and compliance owners to record data sources, endpoint counts by operating system, retention needs, identity integration and any air-gapped constraints. The closing output is a requirements register that both parties sign off before the written scope is finalized.
Size and decide the architecture
Using the requirements register, the team sizes the indexer, server and dashboard, chooses single-node or clustered layouts, and selects the installation method and vulnerability data source. The output is a sizing and architecture decision record that lists each trade-off, the assumptions behind it and the questions to confirm with your infrastructure team.
Build and test the lab environment
DeployOpen builds the stack in a lab that mirrors your planned platform, then writes and tests installation scripts or automation for each component. The step closes when a clean rebuild from the scripts completes and the dashboard, indexer and agent enrollment checks pass in the lab.
Pilot with a staging agent group
The team deploys the stack to staging and enrolls a small agent group covering the operating systems in scope. Alert volume, decoder coverage, resource use and agent group configuration are measured. The output is a pilot results report listing defects, tuning changes and the go or no-go criteria for production.
Build the production environment
The tested scripts are applied to production infrastructure in your accounts or data centers, with certificates, access controls, backups and monitoring of the platform itself configured. The closing output is a production runbook covering procedures for start-up, backup, restore, upgrade and incident response.
Roll out agents in phases
Agents are enrolled in waves by agent group, starting with the lowest-risk systems and checking event volume and performance before each next wave. Each wave closes with a short verification record showing enrolled endpoints, unreported agents and open issues, so the rollout pace stays under your control.
Tune, hand over and support
After the final wave, alert rules, noise thresholds and dashboards are tuned with your analysts, and the handover pack is delivered with architecture records, scripts, runbook, access model and training notes. Ask for the written phase plan with dates and any ongoing support retainer terms before work starts.
What teams keep in-house and what they outsource
This table maps each part of a Wazuh rollout to the team that usually owns it, the skills it needs, and whether it is typically kept in-house, shared, or outsourced, so you can see where a partner adds capacity and where your own staff must stay accountable.
| Work area | Skills required | Typical ownership | Notes for the decision |
|---|---|---|---|
| Alert priorities and response duties | Detection engineering, incident response process, knowledge of your threat model and reporting obligations | In-house | Security owners must decide which rule levels page people and who acts on them. A partner can draft the mapping but cannot accept the risk. |
| Hosts, storage and network paths | Linux administration, virtualization or cloud compute, block and object storage, firewall and routing changes | Shared | Infrastructure teams provide the indexer, server and dashboard hosts and the agent-to-server ports. Ask the partner to name the sizing inputs they need from you. |
| Indexer, server and dashboard sizing | Capacity planning for event volume, indexer node design, retention modeling | Outsourced or shared | Sizing is the most common scoping gap. Confirm which party signs off the sizing assumptions before installation starts. |
| SAML identity integration | Identity provider administration, SAML metadata exchange, group-to-role mapping, certificate handling | Shared | Identity owners supply the application registration, claims and group names. The partner configures the Wazuh side and tests role mapping. |
| Installation and agent enrollment | Wazuh deployment methods (step-by-step, OVA, Docker, Kubernetes, Ansible or Puppet), enrollment and agent groups | Outsourced or shared | Ask whether the partner also delivers the offline installation path if your network has no internet connectivity. |
| Rule tuning and decoder baseline | Log source knowledge, Wazuh decoders and rules, false-positive triage | Shared | Platform specialists tune the baseline, while security owners approve suppressions and any changes to alert levels. |
| Vulnerability detection feed | Choice between the Wazuh Cyber Threat Intelligence platform and an offline vulnerability repository, network routing and update handling | Shared | Confirm which feed your network policy allows before design, since this changes how updates reach the server. |
| Compliance framework views | Mapping of control requirements to Wazuh dashboards and rules, evidence collection | In-house | Wazuh offers prebuilt views for several frameworks. Your compliance lead decides what counts as evidence, and an independent assessor makes the determination. |
| Upgrades and ongoing support | Patch cadence, upgrade ordering across components, regression testing of custom rules | See sibling topic | Covered in Wazuh upgrades and support. This page does not compare ongoing ownership. |
| Cloud or self-hosted comparison | Total cost modeling across infrastructure, storage, staff time and vendor support | See sibling topic | Covered in Wazuh cost of ownership: self-hosted vs Wazuh Cloud. This page stays on implementation roles. |
What usually goes wrong
Most Wazuh rollout problems come from decisions deferred until after go-live. Each failure below has a prevention step to settle during planning, before agents and alerts reach production.
Indexer storage undersized after go-live
The Wazuh indexer stores every alert and archived event, so disk demand grows with agent count, log volume and retention period. Teams that size storage from the server's hardware alone often find the disk full within weeks of go-live. Before sizing, confirm expected event volume per agent, the retention period for each index, and how archives will be handled.
Agents enrolled without groups or baselines
Wazuh manages agent configuration remotely through agent groups, so endpoints enrolled without groups end up with ad hoc settings that must be fixed one host at a time. Define groups by role or environment and a configuration baseline for each before the first enrollment wave. Check that each group's file integrity and log collection settings match what the compliance scope requires.
Default rules flood unowned alert queues
Default rules fire heavily on a new deployment, and without tuning the dashboard fills with low-value alerts that analysts learn to ignore. Run a pilot, review the most frequent rules, and suppress or adjust them under a named owner. Assign who triages alerts, at which severity levels, and who signs off on rule changes before the alert feed is connected to on-call staff.
No offline plan for restricted networks
Networks without internet access cannot reach the default vulnerability data source, and the offline installation guide covers that case separately. Plan how packages, updates and an offline vulnerability repository will be transferred across the boundary, and who approves each transfer. Confirm this before the build, because retrofitting an offline path after installation usually means rebuilding the update process.
Identity mapping deferred until after launch
Wazuh supports SAML single sign-on alongside its internal user database, so access depends on which identity provider groups map to administrator and read-only roles. Leaving mapping until after launch tends to leave shared local accounts in use and makes later role changes harder to audit. Agree the group-to-role mapping during design, and test it with a small pilot group before the dashboard is opened to all users.
Patch releases with no test window
Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months. Without a scheduled test window, each patch becomes an unplanned change to a production security tool. Set aside time per release to test custom rules and decoders, confirm the upgrade order across indexer, server, dashboard and agents, and roll back if a rule breaks.
How the work differs by starting point
A greenfield rollout on virtual machines is the most common starting point and the most predictable. Scope centers on sizing the indexer, server and dashboard, then enrolling agents in waves.
- Effort is driven mainly by sizing decisions made before installation, including indexer storage and node count for the expected event volume.
- Installation paths include the all-in-one option and the step-by-step option, plus a prebuilt OVA if your virtualization standards allow it.
- Agent enrollment, agent groups and baseline configuration take up most of the schedule after the first install.
- Confirm the hypervisor, backup target, DNS and certificate plan before the build starts.
- Ask for a written list of sizing assumptions in any quote so you can check it against your event forecast.
Container-based deployment changes the build more than the design. Docker and Kubernetes are documented deployment options, so the work shifts toward storage, persistent volumes and how your platform team runs the stack.
- Confirm which container images and Kubernetes manifests your team will use, and match them to the 4.14 release line you have chosen.
- Indexer nodes need stable storage and identities, so persistent volume design and storage class selection carry more weight than in a VM build.
- Upgrades follow your cluster's change process, which can add approval steps for each component.
- Platform engineers take on certificate rotation, secrets handling and resource limits that a VM team would manage directly.
- Ask the implementer which parts they will deliver as code and which will be delivered as runbooks.
Offline networks change the supply chain for the whole build. Packages, updates and vulnerability data must be brought in on approved media, and the offline installation guide sets the baseline.
- Follow the Wazuh offline installation guide for systems without internet connectivity, and set up a transfer process for packages before the installation window opens.
- Vulnerability detection can use an offline vulnerability repository in place of the Wazuh CTI platform, so plan how that data is refreshed and verified.
- Endpoints need the same offline path for agent packages and dependencies, which often adds effort on hosts with limited package access.
- Change control, media handling and review of imported content often take longer than the technical install, so confirm who approves each transfer.
- Ask whether refreshing the offline repository is included in the quote or will be handled by your team after go-live.
Multiple sites or a clustered design keep the same components but change sizing and networking. The question shifts from one node's capacity to how agents reach the server and how indexer nodes share data across links.
- Sizing is set per site and per node role, so the event volume of each location should be measured separately before hardware or cloud capacity is ordered.
- Network paths between sites affect agent connection design, firewall rules and where load balancing sits.
- Indexer and server node counts depend on retention and expected growth, which moves the sizing decision earlier in the plan.
- Monitoring the cluster itself adds operational work that a single node does not require.
- Use this tab to set the sizing and network inputs, then follow the high availability topic for the cluster design itself.
A hybrid estate with Windows, Linux and macOS endpoints plus network devices is driven by coverage rather than by the platform build. Each endpoint type has its own enrollment path, and devices that cannot run an agent need a separate collection method.
- Wazuh agents run on Linux, Windows and macOS, and each operating system has its own packaging, permissions and rollout window.
- Network devices such as firewalls can be monitored without an agent through syslog collection and periodic API probing, so confirm which devices support each method.
- Agent groups and centralized configuration separate policies by platform, which adds design work before rollout begins.
- An accurate asset inventory is the largest schedule risk, because it determines how many endpoints must be enrolled and in what order.
- Ask the implementer to confirm device coverage and which systems will use agentless monitoring before the scope is fixed.
What the client needs to provide
Most schedule changes on a Wazuh rollout trace back to inputs the client was asked for and did not supply in time. The fixed-scope quote is built from the list below, so every item that is missing or vague either delays the start or moves into a change order. Name the people and collect the inputs before the scope is signed.
Start with two named owners: a technical owner who can approve architecture, host builds and firewall changes, and a security owner who can approve alert handling, retention and access roles. For sizing, provide the number of endpoints by operating system, an estimate of events per second per segment (or the source volumes you can measure today), and a retention rule that states how long alerts and archived data must be kept. Hosts or cloud accounts for the indexer, server and dashboard should be ready, with CPU, memory and disk classes that match the sizing discussion in the sibling topic on indexer sizing and retention.
Network paths are the item teams most often underestimate. Confirm that agents can reach the Wazuh server on the enrollment and event ports, that the server can reach the indexer, and that the dashboard can reach both. Provide a certificate plan (internal CA or approved public issuer, who owns renewal) and a DNS plan with final names for each component. List every log source (firewalls, identity systems, cloud audit trails, agentless devices) with a named owner who can enable forwarding and answer questions about format. If SAML single sign-on is in scope, provide administrator access to the identity provider and a group structure that maps to Wazuh roles.
Finally, agree change windows for host builds, agent rollout waves and cutover, and provide a test environment that mirrors production closely enough to validate custom rules and upgrades. Ask the vendor to confirm which of these items are prerequisites for each phase, because a missing test environment usually shifts the whole plan, not just one task.
Frequently asked questions
Does Wazuh charge a license fee for self-hosted deployments?
No. The self-hosted Wazuh software is open source and distributed under the GNU General Public License version 2, so there is no license fee to pay. The real costs are the infrastructure to run the indexer, server and dashboard, the storage that alert data consumes over time, and the staff hours to install, tune, upgrade and operate the platform. Infrastructure and labor recur, and they grow with event volume, agent count and retention period. Ask any partner to separate one-time implementation labor from recurring infrastructure and support charges in the quote.
What drives the price of a Wazuh implementation partner engagement?
The written scope drives it. The main inputs are the number and type of endpoints and network devices to onboard, the expected event volume and retention period that size the indexer, whether the server runs as a cluster, how many custom decoders and rules are needed, and how many integration points are in scope, such as SAML single sign-on or ticketing. Air-gapped environments, hardening, testing, documentation and handover all add effort. DeployOpen does not publish a price list, and a quote follows from the agreed scope.
How long does a Wazuh rollout take from start to finish?
It depends on scope, and no duration is quoted here. A single-site deployment with a short list of Linux and Windows endpoints involves far less work than a multi-site rollout with clustering, custom rules, SSO and compliance dashboards. Timing also depends on how quickly your teams approve the architecture, provide access and test agent enrollment. The written scope sets the phases and timelines, so ask for a plan that shows sizing, build, enrollment, tuning and handover as separate milestones.
What does my team need to provide for a Wazuh deployment?
Expect to provide access and decisions before the build begins. In most cases that means cloud accounts or virtual machine and data center capacity, DNS and certificate details, network paths from agents to the Wazuh server, an inventory of endpoints and log sources, your retention and compliance requirements, and an identity provider contact if you want SAML single sign-on. A named owner who can approve changes keeps decisions moving. Confirm the exact list in the written scope before work starts.
Can a small IT team install and run Wazuh without a partner?
Yes, a small team can install and run Wazuh alone if it has Linux administration skills, time to size and monitor the indexer, and a clear owner for alert triage. Documented options such as step-by-step installation, Docker, Ansible and Puppet make a first deployment achievable in-house. The harder parts are sizing for growth, maintaining custom rules, upgrading four components in the right order, and keeping compliance evidence current. A partner is most useful for those areas or for a fixed-scope handover.
Is the Wazuh Cloud trial a useful first step before self-hosting?
It helps you evaluate dashboards, alert workflows and agent behavior. The vendor's Wazuh Cloud page describes a 14-day free trial that needs no credit card. The trial runs on the vendor's infrastructure, so it does not test your network paths, sizing, storage, identity integration or air-gapped constraints. Use it to learn the product, then plan the self-hosted build against your own environment and written requirements. Confirm the current trial terms with Wazuh before you rely on them.
How DeployOpen scopes and delivers Wazuh work
DeployOpen plans, implements, hardens, documents and supports self-hosted Wazuh inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Written scope lists the Wazuh indexer, server, dashboard and agent counts agreed for your environment before any build starts.
- We size components from your endpoint inventory, expected event volume and retention requirements, then confirm the sizing assumptions with you.
- The quote follows from the written scope, including which deployment method you choose and which integrations and SSO work are included.
How we build
- We install the chosen Wazuh deployment method, such as step-by-step, Docker, Kubernetes, Ansible or an offline installation, in your infrastructure.
- Agent enrollment is rolled out in phases with agent groups and centralized configuration, and each phase is tested before the next begins.
- Vulnerability detection is set up against either the Cyber Threat Intelligence platform or an offline repository, depending on your network connectivity.
How we hand over
- Handover documentation records the architecture, component versions, certificate and credential locations, and the configuration you approved.
- Test results cover agent connectivity, alert flow, dashboard access and any custom rules or decoders delivered in the scope.
- Your team receives a runbook for routine checks, upgrade order across indexer, server, dashboard and agents, and escalation steps.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, and the terms are agreed in writing.
- Retainer work can cover keeping Wazuh current on the 4.14 line and retesting custom rules and decoders after each upgrade.
- Confirm with DeployOpen during scoping which support levels, response expectations and handover responsibilities apply to your environment.
