Why Wazuh agent deployment at scale is harder than installing packages
Putting Wazuh agents on hundreds or thousands of Linux, Windows and macOS endpoints is hard because of enrollment, grouping and configuration control, not the package install. Installing the agent package is the repeatable step. What decides whether the fleet is useful is whether every endpoint registers with the intended Wazuh server, lands in the correct agent group, and keeps the configuration assigned to that group over time. Teams that treat the rollout as a package push often find out weeks later that large parts of the fleet are reporting in the wrong way or not at all.
Fleet rollouts usually fail in a small number of predictable ways. Agent versions drift apart across operating systems and sites, so the same rule set produces different results on different endpoints. Endpoints join a default group with no tailored settings because nobody defined the group model before rollout. Some hosts never enroll at all, often because of missing enrollment credentials, a service that installed but did not start, or traffic blocked between the endpoint and the server. Local edits to agent configuration made outside the group then cause configuration drift, and segmented subnets, NAT or cloud network rules can break the path from endpoints back to the server. Confirm the required connectivity and ports for your version in the Wazuh documentation before the first wave.
Configuration control is a design decision you make before the rollout begins. The Wazuh server manages agent configuration remotely through agent groups, so the group model determines what each endpoint receives. Decide which attributes define a group, such as operating system, server role, environment or data sensitivity. Decide who may change shared group configuration and how those changes are reviewed and recorded. Remote upgrades are also managed from the server, so version consistency becomes a server-side policy as well as an endpoint task. Automation with Ansible or Puppet, both documented deployment options, can install and enroll agents at speed, but the playbook or manifest still needs a correct mapping from each host to its group.
A structured approach becomes necessary when the endpoint count outgrows what one administrator can check by hand, when several operating system families or business units need different configurations, or when auditors expect evidence that every in-scope endpoint is covered. It also matters when the rollout has to finish inside a fixed window. Before you start, ask for a current inventory of endpoints, a draft group model, a named owner for group changes and a connectivity check from each network segment. Sizing the server and indexer, and the wider rollout phases, are covered on the Wazuh implementation plan page and the indexer sizing page.
Which Wazuh components an agent rollout depends on
An agent rollout touches four Wazuh components, and each one has a different job during deployment. Knowing which component enrolls agents, which stores alerts and which shows group and agent status tells you where to check before, during and after the rollout.
Wazuh agents on endpoints
The agent is installed on each Linux, Windows and macOS endpoint and collects logs, file integrity data and software inventory. During a rollout, the agent package, its version and its enrollment settings determine whether a host reports at all. Check the operating system matrix for every platform in your fleet before you schedule waves, and confirm how each host will receive its group assignment.
Wazuh server for enrollment
The Wazuh server analyzes agent data with decoders and rules, and it is the component that enrolls agents and pushes their configuration and upgrades remotely. Enrollment credentials, the agent group definitions and the server's reachability from every network segment all shape the rollout. If you plan to run a server cluster, confirm how agents are distributed across nodes before the first wave.
Wazuh indexer for stored alerts
The indexer is the full-text search and analytics engine that stores the alerts generated from agent data. As agent count grows, the indexer's disk and node capacity become the constraint that is easiest to overlook during a rollout. Before enabling new log sources across the fleet, confirm the expected event volume per agent with the team that owns storage and retention.
Wazuh dashboard for group and status checks
The dashboard is the web interface where operators confirm that agents have enrolled, are connected and belong to the right groups. It is also where compliance views for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53 are checked. Define a status check, such as agent counts by group and connection state, that the rollout team reviews at the end of each wave.
Agentless devices as a separate scope
Devices such as firewalls can be monitored without installing an agent, using syslog collection and periodic API probing. These sources do not appear in the agent count, so they need their own inventory and their own acceptance checks. Keep them on a separate tracking list, and confirm with the device owner which log formats and API permissions the collection depends on.
Which enrollment, grouping and automation choices fit your fleet
This table compares the main choices that shape a Wazuh agent rollout: how agents register, how they are grouped, what automation tool drives the work, and whether names and groups are preset at install time. Read each row for the fleet conditions where the option fits and the operational cost it carries. The main takeaway is that automation reduces manual drift but concentrates risk, so group design and change control matter as much as the enrollment method.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| Enrollment | Manual registration on each host | Small fleets, pilot groups or hosts that need hand-checked configuration before they join | Slow at scale, inconsistent results between administrators, and weaker traceability of who enrolled what and when |
| Enrollment | Automated registration during install | Fleets of dozens or more hosts built from images or templates with a repeatable install step | Enrollment credentials must be protected in the install pipeline, and a flawed template can enroll many hosts incorrectly at once |
| Grouping | Groups by operating system | Mixed Linux, Windows and macOS estates where configuration differs by platform | Groups multiply quickly if teams also split by role or environment, so confirm the naming scheme before rollout |
| Grouping | Groups by role or environment | Production, staging and development hosts that need different rules, alert thresholds or file integrity scopes | A shared group that is misconfigured affects every host in it, so the blast radius of one change grows with group size |
| Automation | Ansible playbooks | Teams already running Ansible for patching or server builds who want one toolchain for agent install and configuration | Playbooks need ongoing maintenance as Wazuh versions and package names change, and roles must be tested against each supported operating system |
| Automation | Puppet modules | Estates already managed by Puppet with established module review, promotion and reporting | Module updates follow the Puppet release cycle, and teams must confirm the module version matches the Wazuh release line in use |
| Automation | Scripts or existing configuration tooling | Organizations with a mature internal tool that already enforces change approval and inventory | Custom scripts need their own testing and documentation, and they rarely cover the upgrade path without extra work |
| Preset at install time | Agent names and groups set during install | Fleets where hostnames follow a standard and groups map directly to a build template | Naming errors in the template are repeated across hosts, and renaming agents later adds administrative work |
| Preset at install time | Assign groups after enrollment | Environments where ownership of a host is confirmed after it boots, or where classification is reviewed by another team | Hosts can sit in a default group for a period, so confirm that the default group's configuration is acceptable |
How to build a Wazuh agent rollout in order
This sequence takes a Wazuh deployment from a reachable server to a fleet of enrolled agents, with each stage producing an artifact and a check before the next one starts.
Confirm the server and dashboard are healthy
Before any agent is touched, confirm the Wazuh indexer, server and dashboard are installed, reachable from the network segments where agents sit, and report healthy status. Check that agents can reach the server's enrollment and communication ports, that certificates are valid for the hostnames agents will use, and that the dashboard shows the server as running. The artifact is a short infrastructure readiness record listing versions, hostnames, ports and the tested network paths. The step closes when a test endpoint on each network segment can reach the server and the dashboard loads without errors. Confirm the exact ports and component versions against the Wazuh documentation for your release line.
Define the agent group hierarchy and shared configuration
Decide how agents will be grouped, usually by role, environment or business owner, and create the matching agent groups on the server. Each group gets a shared agent configuration that controls which log sources, file integrity monitoring paths and inventory collection apply to its members. Keep the hierarchy shallow enough that a new host's group is obvious to an administrator. The artifact is a group map and the version-controlled configuration files for each group. The step closes when a test agent assigned to each group receives the expected configuration and a review by the security owner signs off on the group map.
Build the installation and enrollment automation for one pilot OS
Choose one operating system for the pilot, most often the one with the largest share of the fleet, and build the installation and enrollment playbook or Puppet module for it. The automation should install the agent package from an approved source, set the manager address, enroll the agent with credentials held outside the playbook, and assign it to a group. Wazuh documents Ansible and Puppet as deployment options, so confirm which tool your team already runs and the module versions it supports. The artifact is a tested playbook or manifest in version control with its variables documented. The step closes when a clean test host installs, enrolls and reports to the expected group in a single run.
Test enrollment and group assignment on a pilot set
Run the automation against a small pilot set that includes representative hosts: different network segments, a host behind a proxy if one exists, and a few machines with unusual configurations. Confirm each agent appears on the server as active, lands in the correct group, and receives the group's configuration. Record failures, such as blocked ports, package conflicts or enrollment timeouts, and fix the automation rather than patching hosts by hand. The artifact is a pilot report listing each host, its result, the issues found and the fixes applied. The step closes when the pilot report shows every pilot host active in its intended group with no open failures.
Extend the automation to Windows and macOS
Build the Windows and macOS installation and enrollment paths, which differ in package format, service handling, permissions and how configuration is delivered. Windows installs typically run under a service account with its own privileges, and macOS packages need approved signing and any required system permissions granted before monitoring starts. Test each platform on its own pilot hosts and confirm the platform-specific checks: service running, agent connected, file integrity and inventory collection producing data. The artifact is a platform addendum to the playbook and a pilot report per platform. The step closes when each platform's pilot hosts show active status and the expected inventory and log data on the dashboard.
Expand in waves while watching connection status
Roll out to the rest of the fleet in defined waves, starting with lower-risk groups and moving toward production-critical systems. Before each wave, confirm the previous wave's agents remain active and that the server and indexer have capacity for the added load. During each wave, watch the agent connection status view for disconnected or never-connected agents and investigate them before continuing. The artifact is a wave log recording the hosts in each wave, the connection counts before and after, and any exceptions. The step closes when the final wave's agents are all active, every exception has an owner and a resolution, and the fleet inventory matches the asset list.
How agent groups and central configuration keep a fleet consistent
The Wazuh server is the control point for agent configuration. Each enrolled agent is assigned to one or more agent groups on the server, and each group has a folder of shared configuration files, including the agent configuration file (agent.conf) and any files that the group distributes, such as decoder or rule content where supported. When an agent checks in, it receives the configuration that applies to the groups it belongs to. The alternative, editing the local ossec.conf on each endpoint by hand, produces drift that nobody sees until an alert fails to fire. Central groups make the intended state a single set of files that can be reviewed, tested and rolled back.
Group design decides how far a change reaches. A group that mixes Linux database servers with Windows workstations will receive every setting meant for either, so groups should follow a property that changes configuration together, such as operating system, role, network zone or data sensitivity. Before any production change, confirm with the Wazuh documentation for the 4.14 line how group membership is assigned, how agents are moved between groups, what happens to an agent that is in no group, and whether a change is applied on the next check-in or needs a restart. Write those answers down in your runbook, because they determine the blast radius of every later change.
Keep every group file under version control, with one repository or branch per environment, and make the server's group folders a deployment target rather than the place where edits are made. Review changes to agent.conf the same way you review code: a named owner, a peer review, and a test group of a few agents in a non-production zone before wider rollout. Automation tools such as Ansible or Puppet can push the same files, but the repository should remain the single source. Record which commit is live on the server so that a rollback is a known operation, not a reconstruction from memory.
Some endpoints legitimately belong to more than one group, for example a Linux web server that is both in a web-tier group and a PCI-scoped group. Decide in advance how overlapping settings are resolved and avoid relying on order you have not verified. Where two groups set the same option differently, treat that as a defect to fix in design, not a runtime rule to memorize. Keep the number of multi-group memberships small, document each one with its reason, and review them whenever the environment or the compliance scope changes.
After any change, verify what the agent actually received instead of assuming the server copy is correct. Compare the configuration the agent reports or the merged file present on the endpoint with the expected group files, check the agent's group membership and its last check-in time on the server, and confirm the expected alerts appear in the dashboard for a test event. Add these checks to the rollout checklist for every group change, and keep the evidence with the change record. Illustrative example: a change to a file integrity monitoring path that reaches only the test group, followed by a test file write that should produce an alert on that agent alone.
What drives the effort and cost of a Wazuh agent rollout
This table lists the main drivers of effort and cost when rolling out Wazuh agents across a fleet, with a way to keep each one down. Read it as a checklist for scoping: the more a driver is left unplanned, the more staff time, pilot work and change windows the rollout tends to need. No figures are given because the self-hosted software carries no license fee and the real cost depends on your environment.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Endpoint count and OS mix | Each OS family (Linux, Windows, macOS, and any Solaris, AIX or HP-UX hosts) needs its own package, enrollment steps and testing, so a mixed fleet multiplies the work. | Confirm the inventory by OS and version early. Consolidate onto supported platforms where the business allows, and group hosts by OS to reuse one automation path per family. |
| Number of environments and network zones | Each zone may need its own manager address, firewall rules for agent ports, and proxy or DNS handling, and each one needs its own verification. | Standardize the network request template. Roll out one zone at a time and reuse the same firewall change pattern across zones. |
| Distinct group policies | Every agent group carries its own configuration, so each unique policy adds design, review and test effort, and drift between groups becomes a support problem. | Start from a small set of standard group templates (for example, server, workstation, and privileged host). Add a new group only when a documented requirement needs it. |
| Mobile or intermittently connected endpoints | Laptops that sleep or roam report late, may miss configuration pushes, and generate support tickets about 'missing' agents that are simply offline. | Set expectations on check-in behavior up front. Plan for delayed registration and confirm how configuration reaches agents that reconnect after long gaps. |
| Change control and approvals | Agent installs touch production hosts, so change requests, approval boards and maintenance windows set the pace more than the install itself. | Bundle installs into a small number of standard changes per OS and business unit. Ask your change board early which pre-approved change types can be reused. |
| Configuration management maturity | Teams with Ansible or Puppet already in place can reuse inventory, roles and reporting. Teams without them must build automation and secrets handling from scratch. | Assess the current tooling before design. Where it exists, extend it rather than build a parallel path. Where it does not, scope the automation as a separate deliverable. |
| Custom collection needs | File integrity monitoring paths, Windows registry keys and application log sources each need a defined list, testing for noise, and review by the data owner. | Document each custom source as a request with an owner. Start with the baseline collection set and add custom sources in later phases after the baseline is stable. |
| Phasing by business unit | Rolling out everything at once concentrates staff time and change windows, while phasing spreads the work but adds coordination and interim states. | Phase by business unit or risk tier, with a pilot group first. Agree the exit criteria for each wave in writing before the next wave starts. |
How connected, air-gapped and Ansible or Puppet rollouts differ
In a connected network, agents reach the Wazuh server directly, so the rollout depends mainly on distributing packages from a source your endpoints can reach and pointing each agent at the server during installation. The work is straightforward per endpoint, but it still needs a plan for version alignment and configuration ownership across a large fleet.
- Packaging: Install agents from the official Linux, Windows and macOS packages, with agent versions aligned to the server release line you run (the current line is 4.14).
- Enrollment: Agents register with the server using the server address and your chosen enrollment method. Confirm which registration options apply to each operating system and version.
- Configuration: Assign agents to agent groups so the server pushes shared configuration remotely. Groups are the main control point once the fleet grows.
- Upgrades: The server can manage agent upgrades remotely, so confirm the required upgrade order against the release notes before rolling out a patch.
Before committing, confirm in the official deployment documentation which package sources, network paths and enrollment options apply to each agent operating system and to your server version.
In an offline or air-gapped network, the Wazuh offline installation guide applies, and every package, dependency and update must be staged inside your environment before any endpoint is touched. The rollout takes longer to prepare because nothing is fetched on demand, and every staged artifact becomes part of your change record.
- Packaging: Mirror the required agent packages to an internal repository or file share, and verify each artifact against the checksums published by the vendor before it is approved for use.
- Enrollment: Enrollment works the same way logically, but the server address and certificates must resolve inside the isolated network. Test registration on a pilot segment first.
- Configuration: Keep agent group configuration in version control so changes can be reviewed and then applied through the server without internet access.
- Vulnerability data: Vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, so plan how that repository is updated and who approves each import.
- Updates: Each patch release must be staged, tested and transferred again, so build the transfer cadence into the operating plan.
Before committing, confirm in the offline installation guide which components must be mirrored, how dependencies are resolved, and how the offline vulnerability repository is refreshed for your version.
With Ansible, the playbook or role becomes the source of truth for installing agents, setting the server address, enrolling endpoints and placing configuration. Inventory and variables define which hosts belong to which agent group, so the same change can be reviewed, repeated and audited like any other infrastructure code.
- Packaging: The playbook installs packages from the repository your environment can reach, whether that is the public source or an internal mirror in an isolated network. Pin the agent version explicitly.
- Enrollment: Pass the server address and enrollment credentials as variables held in an encrypted vault, and make the enrollment task idempotent so reruns do not re-register healthy agents.
- Configuration: Map inventory groups to Wazuh agent groups, and template configuration files from variables so differences between environments are visible in the code.
- Drift control: Run the playbook on a schedule or in check mode to detect hosts that have diverged from the declared state.
- Testing: Validate the role on a lab inventory before running it against production hosts.
Before committing, confirm in the official deployment documentation whether an Ansible role or collection is supported for your operating systems and server version, and which variables and tasks it expects.
With Puppet, agent installation, enrollment and configuration are expressed as classes and modules applied by the Puppet agent on each endpoint. Hiera or a similar data layer holds environment-specific values, and Puppet's reporting shows whether each node converged to the declared state.
- Packaging: A module declares the agent package and version, and manages the repository source so each platform pulls the correct build from your approved location.
- Enrollment: Server address and enrollment secrets are supplied through the data layer and protected with your secrets tooling, so enrollment runs only where the catalog says it should.
- Configuration: Use classes to declare the agent configuration and group membership, keeping shared settings in one place and environment overrides in data.
- Ordering: Declare dependencies between the package, the configuration file and the service so the agent starts only after its configuration is in place.
- Reporting: Review Puppet reports after each run to catch failed enrollments or configuration that failed to apply.
Before committing, confirm in the official deployment documentation whether a Puppet module is supported for your platforms and server version, and which parameters it exposes for the server address, groups and enrollment.
How to verify that agents enrolled correctly and fail safely
The rollout is only proven when the dashboard shows the fleet matching your intent. For each Wazuh agent, confirm three things: the agent reports as active on the Wazuh server, its version matches the version you approved for that operating system, and it is assigned to the agent group you planned for it. Build a short reconciliation report that compares the inventory of expected endpoints from your CMDB or host list against the agents the server reports. Gaps fall into two groups: hosts that never enrolled, and agents that enrolled but landed in the default group or on an older build. Treat both as failed checks, not as cleanup for later. Ask your implementation partner or internal team to show this reconciliation output before any expansion step is approved.
Next, prove that configuration changes reach the intended group and no other. Agent groups exist to scope centrally managed configuration, so make a harmless, reversible change to one test group, such as an additional file integrity monitoring path or a log collection location that exists only on pilot hosts. Then check that the change appears on the agents in that group and is absent from agents in every other group. Repeat the check on a Linux host, a Windows host and a macOS host, because the configuration syntax and file paths differ by platform. Record which group membership and configuration version each agent reports, so that a later audit can show how a given endpoint received its settings.
Test the reverse path as well. Deliberately push a broken group change to the pilot group, for example a malformed configuration block that the server should reject or that the agent should fail to load. Confirm that the failure is visible in the dashboard and in the agent logs, that the rest of the fleet is unaffected, and that you can restore the previous configuration from version control and redeploy it. The rollback is only credible if someone who did not write the change can execute it from the runbook within the time your change window allows. Record the actual elapsed time so that the window is based on evidence rather than assumption.
Then test the failure modes that will occur in production. Disconnect a pilot endpoint from the network and confirm that the dashboard marks it disconnected and that it reconnects without re-enrollment when connectivity returns. Re-run enrollment on a host that is already registered to see whether a duplicate agent identity appears, and decide in advance how you will remove the stale entry. Assign one host to the wrong group on purpose and confirm your reconciliation check catches it. Finally, interrupt an Ansible or Puppet run partway through the pilot to see what state the fleet is left in. A partial run is the most common cause of mixed versions and inconsistent groups, so your automation should be idempotent and its output should list every host it did not complete.
How to secure enrollment credentials and automation access
Enrollment is the point where a new endpoint is trusted by the Wazuh server, so the credentials, server permissions, network paths and automation secrets used during rollout deserve the same scrutiny as the server itself. The cards below cover the controls that matter during agent deployment. Server-side and certificate hardening are covered separately in the Wazuh security hardening topic.
Enrollment password lifecycle
Enrollment registration passwords decide which hosts can join the manager. Confirm how each password is generated, who can read it, and how it is replaced after a rollout wave. Check that the password is not reused across environments, and that rotation is part of the runbook rather than an afterthought. Ask your partner to show where the current password is recorded and who has access to it.
Group configuration change control
Agent group configuration is pushed by the server to every member agent, so a single unauthorized edit can change monitoring on thousands of endpoints. Limit which administrator accounts can create groups, assign agents, or edit shared configuration files. Review who holds those roles and record changes to group membership and configuration as part of your change process.
Automation secrets outside playbooks
Ansible and Puppet runs need credentials for the Wazuh server, the enrollment password and sometimes API access. Keep these values in a dedicated secrets store or encrypted vault and inject them at run time, never in playbooks, manifests, inventory files or version control history. Confirm that automation service accounts have only the permissions needed for enrollment and group assignment.
Agent key material on endpoints
Each enrolled agent holds key material that identifies it to the server. Confirm that the agent key file is readable only by the agent service account and root or Administrators, and that it is not included in golden images or cloned virtual machines. Cloning an enrolled host can produce duplicate identities, so define how keys are removed before images are captured.
Network paths to the enrollment port
The enrollment service listens on a port that should accept connections only from the subnets where endpoints are being onboarded. Define these allowed source ranges in firewall or security group rules and close the port once rollout completes. Check that the enrollment path does not traverse shared networks where unrelated hosts can reach it, and confirm the exact port and protocol in the Wazuh documentation for your release line.
Rollout access reviews
Rollout creates temporary access for partners, automation pipelines and staff. Record every account and secret created for the project, assign an owner and an expiry, and remove them when the final wave is complete. Ask for a list of accounts, roles and secrets at handover so that access left behind after go-live can be found and closed.
What to monitor, document and upgrade after the fleet is live
The work after go-live starts with knowing which endpoints are reporting and which are not. Track agent connection status on the Wazuh server and in the dashboard, and alert when an agent stops reporting for longer than your tolerance allows. Disconnected endpoints usually fall into a few groups: hosts that were powered off, hosts where the agent service failed, hosts whose network path to the server changed, and hosts that were removed without being deregistered. Each group needs a different owner and response, so record the cause each time you find one. Before building alerts, confirm which status fields your server version exposes, how last-seen timestamps are reported, and whether your monitoring tool can read them through the Wazuh API.
Know which agent version runs in each agent group. The team should be able to answer, from one query or report, how many endpoints run each agent version and which groups they belong to. This matters because a server upgrade does not change agents that are already enrolled, so mixed versions become the normal state during a staged rollout. Keep the group-to-version mapping in your change log and review it after each 4.14 patch release. The vendor shipped 4.14 patches on six dates in 2026, roughly one every one to two months, so a monthly review is a reasonable starting point for most teams. Confirm the agent version range your 4.14 server accepts before you schedule any agent changes.
Store everything that defines the fleet in version control. That includes group configuration, the centralized agent configuration you distribute, any custom decoders and rules deployed through the server, and the Ansible or Puppet code that installs and enrolls agents. Treat group configuration as code: a change to a shared group should pass through the same review path as a playbook change, and the repository history should show which configuration was in effect on a given date. Keep enrollment passwords and other secrets out of the repository and inject them at run time from your secret store. Tag releases so that an incident review can name the exact configuration version that was live.
Write the enrollment runbook so a second engineer can run it without help. It should cover the package source for each operating system, the registration target, the group assignment, the check that confirms an agent appears as active, and the steps for handling an agent that joins the wrong group or disrupts a host. Rollback is the part teams most often leave out. Define it per platform: removing the agent package, deregistering the agent from the server, and clearing residual state on the endpoint. Test each rollback step on a lab host of each operating system you support, then record the results alongside the runbook so the steps reflect what actually happens.
Plan agent upgrades in step with server upgrades on the 4.14 line, but do not assume the two must move at the same time. The Wazuh server manages agent configuration and upgrades remotely, which avoids manual touch on each endpoint across a large fleet. Before relying on that process at scale, confirm several points with the vendor documentation and in a pilot: which agent versions the server supports during the transition, whether upgrades can be targeted by group in waves, how endpoints that are offline during a wave are handled when they return, how a failed upgrade is detected and reverted, and whether any agent-side settings reset. Run the pilot on one group per operating system you operate.
What buyers and engineers ask before rolling out Wazuh agents
What does a Wazuh agent rollout cost beyond the software?
The self-hosted Wazuh software is open source with no license fee, so the cost of a rollout is the work and infrastructure around it. The main components are staff time for scoping, packaging, pilot testing and change approvals; automation effort to build Ansible or Puppet content for each endpoint family; infrastructure for the Wazuh server and the indexer that stores agent data; and ongoing operations such as agent upgrades and configuration changes. The initial build and pilot are one-time costs. Upgrades, group maintenance and staff hours recur. DeployOpen does not publish a price list. A quote follows a written scope that lists fleet size and mix, automation tooling, approval steps and environments. Ask every bidder to price these components separately so you can compare them.
How long does a Wazuh agent rollout take to complete?
The duration depends mostly on fleet mix and change control. The agent install itself is usually the shortest step. A fleet of mostly Linux servers that already runs a configuration management tool moves differently from a mixed estate of Windows workstations and macOS laptops that need user-facing change windows. Time also depends on how many agent groups you need, how long your change board takes to approve each wave, and how many environments, such as production and regulated segments, must be covered. No duration is given here because it varies widely by estate. Ask any provider for a phased schedule with gates between pilot, waves and full coverage, and check each gate against your own change calendar.
What does our team need to provide for an agent rollout?
Four inputs are needed before work starts. First, network access so agents can reach the Wazuh server for enrollment and event reporting, with firewall rules approved for each network segment. Second, a pilot group of representative hosts across operating systems, used to test enrollment, groups and configuration before wider waves. Third, approval paths for standard changes, emergency changes and endpoint software installs, including who signs off for each environment. Fourth, named automation owners for Ansible or Puppet who can review playbooks or manifests, maintain inventories and handle credentials. Also confirm who holds administrative rights on endpoints, since installs usually need them. Agree these items in the written scope so that blockers do not appear in the middle of a wave.
Can an internal team roll out Wazuh agents without a partner?
Yes, an internal team can do this if it has the skills and time. The steps are well documented: packaging agents, defining enrollment and group logic, testing on a pilot, and running waves through change control. The usual gaps are capacity during the rollout, experience with Windows and macOS packaging, and an owner for the automation after go-live. A partner is most useful when the internal team lacks these skills or cannot give the rollout steady time. DeployOpen works on fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and it offers ongoing support as a retainer. Compare your internal plan with a written partner scope, including the hours your own staff would spend on the pilot and approvals.
Is Ansible or Puppet easier for deploying Wazuh agents?
Neither tool is inherently easier. Wazuh documents both as deployment options, so the effort depends mostly on which tool your organization already runs. With Ansible, the work is usually playbooks run from a control node, with inventories and protected handling of secrets. With Puppet, the work is modules and manifests applied by agents on a schedule, which suits estates already managed by Puppet. Effort increases if the tool is new to your team, if your endpoints are varied, or if Windows and macOS need separate paths. Check the current documentation for each tool's modules or playbooks, and confirm they match the Wazuh release you plan to deploy. Ask each provider to estimate effort per tool against your existing configuration management.
What happens to Wazuh agents already installed by another tool?
They keep running until you change them, so the first task is an inventory. Record each existing agent's version, the manager it reports to, its group membership and the tool that installed it. Then decide per host whether to re-point it to your Wazuh server, upgrade it in place or reinstall it through your new automation. Avoid leaving two agents on one host that report to different managers, since this creates duplicate alerts and confusing inventory. Confirm the upgrade and re-registration path in the documentation for the agent version you plan to use, and test it on the pilot group first. Plan a cutover window for each wave and a rollback path for hosts that fail enrollment. Also check whether the other tool's configuration management will overwrite your changes on its next run.
How do agent groups keep Wazuh configuration consistent across a fleet?
Agent groups let the Wazuh server assign one configuration to many agents and push changes remotely. Group agents by function and environment, such as production web servers or macOS laptops, so each group receives only the configuration it needs. The Wazuh server manages agent configuration and upgrades remotely, which reduces per-host edits, but the group design still needs a named owner. Keep the group list short and documented, because every extra group adds testing. Changes to shared configuration should follow the same pilot and approval path as installs. Confirm how group membership is set at enrollment and whether your automation tool or the server assigns it, since a mismatch can leave agents under the wrong policy.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and Wazuh agent deployment at scale follows the same method. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory operating systems across Linux, Windows and macOS endpoints and group them by role and risk.
- Confirm which agent groups, enrollment method and configuration profiles the written scope covers.
- Record which systems are offline or air-gapped, since these need an offline installation path and an offline vulnerability repository.
How we build
- Build agent packages and enrollment steps for each operating system, then test them on representative hosts.
- Automate enrollment and centralized configuration with Ansible or Puppet, using agreed playbooks or manifests.
- Verify agent check-in, group assignment and configuration delivery against the server before each fleet wave.
How we hand over
- Deliver written runbooks covering enrollment, group changes, agent upgrades and removal for your team.
- Document the automation code, variables and the configuration baseline so your staff can maintain them.
- Walk your operators through the rollout checks and record the acceptance tests agreed in the scope.
How we support
- Ongoing support is available as a retainer for agent upgrades, new operating system builds and fleet changes.
- Retainers can cover keeping agent versions aligned with the Wazuh 4.14 line as patch releases ship.
- Ask any support provider to confirm response terms and coverage in writing before you sign.
