Wazuh high availability: when one server stops being enough
When a SIEM becomes a dependency for detection, compliance evidence and incident response, the first question is no longer whether it works but what happens when one of its nodes fails. In Wazuh, that question has no single answer. The platform has four components: the Wazuh indexer, which is a full-text search and analytics engine that stores alerts; the Wazuh server, which analyzes agent data with decoders and rules; the Wazuh dashboard, which is the web interface; and the Wazuh agents installed on endpoints. High availability applies differently to each of them, so the design is a set of per-component decisions rather than one switch that a team turns on.
The reasons to take this seriously are concrete. Agent telemetry should keep flowing while a server node is patched or replaced, so that endpoints do not build a gap in the record. Analysts need the indexer to answer searches during an active investigation, which is exactly when a single failed node hurts most. Maintenance windows should not create blind spots, which means the team must be able to take one component down while the others keep collecting and retaining events. Each of these needs is different, and each points to a different part of the architecture.
What makes this harder than it looks is coupling. Agents connect to a server address, so whatever sits behind that address must accept their connections, and the team has to decide whether agents reach a single name, a load balancer or a list of servers. The indexer holds the alert history, which means losing it loses investigation context even if the server keeps analyzing events. The dashboard depends on both the indexer and the server, so a dashboard that is highly available in front of an unavailable indexer still gives analysts nothing useful. Ask your team to draw each dependency arrow before choosing any topology.
The Wazuh server can run as a cluster for horizontal scaling, and it manages agent configuration and upgrades remotely. Those two capabilities matter for the design: clustering helps with capacity and resilience on the analysis side, while remote management affects how changes reach agents during a failover or a rolling upgrade. Because this topic is written for the 4.14 release line, confirm with the vendor documentation for your exact version how cluster membership, agent reconnection and configuration distribution behave before you commit to a layout. Do not assume that a clustered server removes the need to plan for indexer failure.
Which Wazuh components need redundancy and how they relate
A clustered Wazuh design protects four Wazuh components and one piece of customer infrastructure that sits between agents and the server layer. Each component has a different job, so each needs its own redundancy decision and its own failure check before the design is approved.
Wazuh indexer as the storage layer
The Wazuh indexer is a full-text search and analytics engine that stores the alerts the server produces. It is the component that holds your alert history, so losing it means losing searchable evidence. Plan its node count, shard and replica settings, and disk headroom together, and confirm the indexer cluster prerequisites for the 4.14 patch release you select in the official Wazuh documentation.
Wazuh server as the analysis layer
The Wazuh server applies decoders and rules to agent data and can run as a cluster for horizontal scaling. Clustered server nodes share the analysis workload and also manage agent configuration and upgrades remotely. Check how cluster membership, the master node role and worker node failover behave in your chosen release before you size the node count.
Wazuh dashboard as the read interface
The Wazuh dashboard is the web interface analysts use, and it reads its data from the indexer rather than from the server nodes. A dashboard outage does not stop collection or analysis, but it does stop investigation. Decide whether one dashboard instance is enough for your operating model or whether you need a second instance behind the same access path, and test login and search after a failover.
Wazuh agents on endpoints
Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX endpoints and connect to the server layer to send events and receive configuration. Agents are the only component that cannot be made redundant by adding more of them, because each endpoint has one agent. What you control is the server address they use, the agent group configuration they receive, and how they reconnect after a server node fails.
Load balancer or DNS name in front of servers
The load balancer or DNS name that agents use to reach the server nodes is customer-supplied infrastructure, not a Wazuh component. Its health checks, failover behavior and session handling determine how quickly agents recover when a node is lost. Confirm with your network team which product will own this layer, who maintains it, and how it is tested alongside the Wazuh cluster.
Agentless collection depends on the server layer
Agentless sources such as firewalls reach Wazuh through syslog collection or through periodic API probing, and both paths land on the server layer. A server node outage can therefore stop syslog intake or API polling for these devices even when agents keep reporting. Identify which device sources use each path, decide where syslog senders point during a failover, and verify that each source is still collected after a node restart.
Which high availability decisions to make first
This table compares the main architecture choices for a Wazuh high availability design, from how many hosts to use through to the platform you run them on. Read each row for when the option fits and what it asks of your team to operate it over time. The main takeaway is that clustering adds operational work at every layer, so decide the simplest layout that meets your recovery and availability targets before adding nodes.
| Decision | Option and when it fits | Operational burden to plan for |
|---|---|---|
| Host layout | Single all-in-one node suits a lab, pilot or small estate where a rebuild from backup is acceptable. Separate indexer, server and dashboard hosts suit larger estates that need each tier sized and patched independently. | All-in-one is simple to upgrade but couples every component's downtime. Separate hosts add certificates between components, a fixed upgrade order and more hosts to monitor. |
| Server tier | A single Wazuh server with a tested fast rebuild from backups fits organizations whose agent outage tolerance is measured in hours. A clustered server fits estates where agent communication must survive loss of one server. | Clustering needs a shared configuration and consistent versions across members. Staff must know how to restore the cluster master and how agents fail over during maintenance. |
| Indexer node count | A single indexer node fits small volumes and non-critical retention. Multiple indexer nodes fit higher volumes and replica-based protection of stored alerts. | Each added node adds certificates, heap and disk monitoring and rolling restart steps. Confirm the indexer's documented node and replica rules for your version before sizing. |
| Quorum parity | Use an odd number of indexer nodes so that a majority survives a single node loss. Even counts can split into two halves during a network partition and risk cluster stall. | Quorum loss halts writes and can make the cluster unavailable. Operators must recognize split-brain symptoms and know the recovery procedure before go-live. |
| Availability zones or data centers | Spread nodes across zones when the site can tolerate the latency between them and a third site can host a tie-breaking node. Keep all nodes in one site when latency between sites is high or no third location exists. | Cross-site latency affects indexing and quorum timing. Site loss tests, network dependency mapping and documented failover runbooks become recurring tasks. |
| Agent connection endpoint | Load balancing agent connections fits estates with many agents and a team comfortable running a health-checked balancer. A stable DNS name pointing at a managed address fits smaller estates and simpler failover. | A balancer adds its own certificates, health checks and failure modes. DNS-based failover depends on record change times and client caching, so test it against real agent behavior. |
| Platform for hosts | Virtual machines fit teams with existing hypervisor and configuration tooling. Containers or Kubernetes fit teams already running those platforms and able to manage persistent storage for indexer data. | Containers add storage class, pod disruption and volume backup work. Kubernetes adds cluster upgrade coordination and skills that must be on the staff roster. |
How to build a clustered Wazuh deployment in order
This sequence builds a Wazuh deployment where indexer, server and dashboard tiers are clustered and agents can reconnect to a different server node without re-enrollment. Each step closes with a check, so a fault found early does not compound into later layers.
Confirm the target 4.14 patch and topology
Choose the 4.14 patch release you will deploy and read its release notes and the multi-node installation guidance in the official Wazuh documentation for that exact version. The latest 4.14 patch in the supplied release history is 4.14.9, released 14 October 2026, but confirm the current patch when you start. Record the version for the indexer, server, dashboard and agents, along with the node counts, hostnames and ports the documentation requires. Done when you have a written version matrix that your team and any partner have reviewed and signed off.
Provision and form the indexer cluster
Build the indexer nodes in your own infrastructure with stable hostnames, then configure the cluster name, node names, discovery settings and certificates as the documentation specifies. Start the nodes and query the cluster health and node list through the indexer API from each node. Done when the health status matches the value the documentation gives for a healthy cluster and every node appears in the node list. Do not move to the server tier until all indexer nodes have joined.
Join the server nodes into a server cluster
Install the same Wazuh server version on each server node, then set the cluster name, node type, shared cluster key and indexer connection details in the server configuration. Start each node and run the cluster status command for your release. Done when every server node reports its cluster membership and each node lists the same set of members. If a node reports as standalone or missing, fix the cluster key and network path before continuing.
Place a load balancer or stable DNS name in front
Create a single stable address for agents, either a TCP-level load balancer or a DNS name that resolves to the server nodes, and point agent manager settings at that address. Configure health checks against the agent communication port, not only a web endpoint, so that a node which stops accepting agent connections is removed from rotation. Confirm the port in the documentation for your release. Done when a test connection to the stable address reaches more than one server node and a stopped node is dropped from the pool.
Install the dashboard against every indexer node
Install the Wazuh dashboard and configure it with all indexer endpoints, not a single address, so that reads continue if one indexer node is unavailable. Log in with an administrator account and confirm the indices and alerts are visible. Then check that the dashboard can query data served by each indexer node, for example by reviewing shard allocation and running a test search. Done when the dashboard loads the indexed data and the test search returns results from each node.
Enroll a test agent and verify failover
Enroll one test agent through the stable address and confirm it appears as active in the agent list and sends events. Note which server node the agent is connected to, then perform a controlled restart of that node. Done when the agent reconnects through the stable address, reports to a different server node, and its events continue to reach the indexer without a new enrollment. Record the result in your runbook so the test can be repeated after every upgrade.
How the design changes across single node, clustered, Kubernetes and air-gapped environments
A single node places the indexer, server and dashboard on one host, either through the all-in-one installation or the step-by-step method run on one machine. This is the shortest path to a working platform and suits a lab, a pilot or a small estate where a monitoring gap can be tolerated while a host is restored.
- Build: one host runs all components, so there is no inter-node certificate distribution and no load balancer to configure.
- Failover: none. If the host fails, ingestion and the dashboard stop until it is restored, and agents hold events only within their local buffering limits.
- Sizing: storage, memory and compute are shared on one machine, so indexer growth competes directly with the server process.
- Stays the same: agent enrollment, decoders, rules and dashboard views work the same way, so content built here carries forward when you move to a cluster.
Confirm how long a restore from backup takes on this host and whether that window meets your monitoring obligations.
Clustered virtual machines separate the indexer and server roles onto multiple nodes, with a load balancer distributing agent connections across the server nodes. This is the most common resilient pattern because each role can be scaled, patched and replaced on its own.
- Build: several indexer nodes form an indexer cluster, several server nodes form a server cluster, and the dashboard connects to the indexer cluster through its own configuration.
- Load balancing: agents connect to a virtual address in front of the server nodes, so a failed node can leave rotation without re-enrolling agents.
- Certificates: each node needs a certificate issued for its role, and every member must trust the same authority, so plan the certificate design before the first node is built.
- Stays the same: rules, decoders, agent groups and dashboard views are shared across the cluster, so administrators work through the same interface.
Confirm the cluster sizing, load balancer health checks and failover behavior for your version in the Wazuh documentation before you fix the host count.
Wazuh documents a Kubernetes deployment option. In this model, availability depends less on virtual machine placement and more on pod scheduling, persistent volumes and service exposure, so the platform team's Kubernetes skills become part of the availability design.
- Scheduling: pod anti-affinity and node pool design decide whether replicas land on separate hosts. Without them, one node failure can take several components down together.
- Storage: indexer data sits on persistent volumes, so the storage class, replication and snapshot approach determine how data survives a node loss.
- Service exposure: how agents reach the server service, through a load balancer, ingress or node port, defines the agent connection path and needs the same care as the virtual address in a VM cluster.
- Stays the same: the components, rules, decoders and agent behavior are unchanged, and the upgrade order still runs indexer, server, dashboard and then agents.
Confirm which manifests are supported for your version and whether your cluster meets the storage and networking requirements they document.
An air-gapped network has no route to the internet, so installation follows the Wazuh offline installation guide. The larger change is vulnerability detection: the data comes from an offline repository instead of the Wazuh Cyber Threat Intelligence platform, which changes how updates reach every node.
- Build: packages and dependencies are staged through an approved transfer process before installation, and the chosen topology, single node or cluster, still applies.
- Vulnerability data: the offline repository must be refreshed through a controlled transfer, so the update cadence becomes a process your team owns.
- Update flow: every server node and the indexer must receive the same vulnerability content, so verify version consistency after each transfer.
- Agents: agent software and configuration updates must be staged internally, because endpoints cannot reach external sources.
- Stays the same: the four components, the agent model and the dashboard work as they do in connected environments.
Confirm with Wazuh how the offline repository is generated and updated for your version, and agree the transfer and approval steps with your security team before go-live.
What drives the effort and cost of a clustered Wazuh build
This table lists the factors that change how much work and spend a clustered Wazuh deployment needs, with the effect of each and the practical way to limit it. Read it as a checklist to bring to a scoping conversation, because most rows affect infrastructure, staff time and partner fees at the same time. Infrastructure is what you run, staff time is what your own team spends, and partner fees follow from the written scope.
| Driver | How it raises effort or cost | How to keep it down |
|---|---|---|
| Endpoints and agent groups | More enrolled agents means more connections to balance, more inventory and alert traffic, and more group-level configuration to test and maintain. | Group agents by role and configuration early, and size the cluster from a measured agent count rather than the headcount of the organization. |
| Alert and event volume | Volume sets indexer storage, indexer node count and search load, which adds hardware and retention cost on every node that stores alerts. | Filter noisy sources at the agent or decoder level and confirm expected daily volume before sizing. Indexer sizing is covered in its own topic. |
| Number of sites and node placement | Nodes spread across sites need cross-site links, latency planning, and a decision on whether a site outage should fail over automatically or manually. | Agree in writing which sites host nodes and how agents reach them. Keep the cluster in one site where your recovery objectives allow it. |
| Identity provider and ticketing integrations | Each SAML identity provider, group mapping or ticketing connector adds configuration, testing against every node and an owner for ongoing changes. | Limit integrations to those needed at go-live, and document the mapping of identity provider groups to Wazuh roles in one place. |
| Number of environments | Lab, staging and production each need a cluster of matching shape to test upgrades, rules and failover, so infrastructure and rebuild effort multiply. | Keep non-production clusters smaller but of the same version and layout, and automate builds so each environment is rebuilt the same way. |
| Custom rules and decoders | Changes to rules and decoders must be retested after failover, load balancer or node changes, because a rule that works on one node can behave differently after a switch. | Keep customizations in version control, keep a regression set of sample events, and retest after every topology change. |
| Compliance evidence requirements | Assessors may ask for proof of failover tests, configuration history, retention settings and access records, which adds documentation and test runs beyond the build itself. | Ask early which controls the evidence must support, and define the evidence list and test schedule in the scope before the build starts. |
| Team familiarity with Linux networking, certificates and load balancers | Clustering depends on correct DNS, time sync, TLS certificates between components, and load balancer health checks. Gaps in these skills lengthen troubleshooting and add partner hours. | Assign named owners for certificates and the load balancer before the build, and have staff practice a node replacement in a non-production cluster. |
How to test that Wazuh fails over and fails safely
A Wazuh high availability design is only proven when its failure behavior is tested before go-live. Run this plan in a staging copy of the production layout, or in production during an agreed window if your environment allows it. For each test, write down the expected result before you start: which components should keep working, what the dashboard should show, which alerts should appear and which errors you expect to see. Fails safely has a specific meaning here. When a component fails, the platform should degrade in a visible way, with clear alerts on the failure itself, and it should not silently drop agent data. A test passes only when the failure is detected and the data path stays intact or recoverable. A dashboard that still loads does not settle that question.
Start with the indexer. Stop one indexer node during a quiet period and check cluster health through the API or the dashboard. Record whether the status changes, how the change is reported, and whether any shards become unassigned. Then run a search for a known test event and open the main dashboard views, confirming they return results. Before the stop, generate a set of uniquely marked test events from a test agent. After recovery, confirm that every marked event is present in the indexer. Next, simulate a degraded indexer on a non-production copy, for example by stopping more than one node or constraining its resources. Watch whether the dashboard shows an error or warning, or an empty table that looks like no activity. Confirm the exact behavior with your release, because error handling in the dashboard can differ between versions.
Next, test the server tier. Stop one Wazuh server node and confirm that enrolled agents reconnect through the load balancer, then check their status in the management interface. Send new events from a test agent and confirm they are decoded, matched against rules and produce alerts on the surviving node. Test the health check separately. Make the check fail on one server node, for example by stopping the analysis service while the host still answers on the network, and confirm the balancer removes that node from rotation and sends new connections elsewhere. Restore the node and confirm it returns to rotation. Check your balancer documentation for the probe it uses. A check that only confirms an open network port may keep sending agents to a node that cannot analyze their events.
Run restarts in a controlled window, one node at a time, and treat event continuity as a measured result. Before each restart, generate a fixed number of marked test events on an agent and record the count. After the node returns, compare that count with the matching events in the indexer. Differences need an explanation, such as events buffered on the agent and delivered later. Any gap you cannot explain is a failed test. Finally, change a small setting for a test agent group from the management interface and confirm that every server node reports the same configuration and that agents in the group receive it. A configuration that reaches only one server node produces inconsistent analysis, so this check should pass before the first production incident, not during it.
Security controls specific to a clustered Wazuh deployment
A clustered Wazuh deployment adds trust relationships, network paths and stored data that a single server never had. The controls below focus on what changes when several indexer and server nodes sit behind a load balancer. General hardening of each component is covered in the hardening topic, so this section concentrates on the multi-node decisions that are easy to miss.
Certificates across indexer, server and dashboard
Each indexer node, server node and the dashboard authenticate to one another with certificates, and a clustered layout multiplies the number of certificates to issue, distribute and track. Confirm which certificate authority signs them, who holds the private keys, and where each certificate is stored. Plan renewal across all nodes before the first expiry date arrives, because a single expired certificate on one node can break cluster communication or dashboard connectivity. Check the official documentation for the current certificate tool and renewal steps.
Network access to cluster and agent ports
Several ports carry traffic between nodes, from the dashboard and from enrolled agents. Restrict each one to the source networks that need it, so that indexer and cluster ports accept traffic only from other cluster members and administrative hosts, while agent connection ports accept traffic only from the endpoint ranges you manage. Review firewall rules on every node after any topology change, since a new node that is not covered by the rules will fail in ways that look like application faults.
Load balancer TLS and health check settings
The load balancer in front of the Wazuh server nodes terminates or passes through TLS for agent connections, and it runs health checks against the nodes. Keep its certificate and health check configuration in a separate, scoped location from Wazuh application credentials, so that someone who manages the load balancer does not automatically hold cluster or API secrets. Confirm which account can change listeners, backend pools and health check paths, and log those changes.
Node-to-node communication and cluster configuration
Server nodes exchange state and configuration with each other, and the indexer nodes replicate data across the cluster. Protect the shared cluster key or equivalent secret, limit who can read the cluster configuration files, and confirm that node-to-node traffic is encrypted and authenticated as the official documentation describes for your version. A node that joins with a copied or stale secret can receive configuration it should never see, so review membership after every node change.
Backups and snapshots of the indexer
Indexer snapshots hold the alert data that analysts and auditors rely on, and in a clustered setup they are often copied across storage locations for resilience. Treat every snapshot repository and backup copy as sensitive. Restrict write and read access, encrypt data at rest in the repository and in transit, and test restores on a separate environment. Confirm retention and deletion rules with your compliance owner, since old snapshots may contain data that should no longer be kept.
Control over cluster topology changes
Adding, removing or replacing an indexer or server node changes the trust boundary and the data distribution of the whole cluster. Limit this capability to a small named group, require a change record for each topology change, and separate the people who approve a change from those who carry it out. Keep an inventory of current members, their certificates and their network paths, and reconcile it after every change so that an unknown node cannot remain in the cluster unnoticed.
What to monitor, back up, upgrade and document after an HA build
The ongoing work in a clustered Wazuh deployment starts with monitoring, because a cluster can look healthy at the load balancer while one component is degraded. Track indexer cluster health and shard state through the indexer's cluster health and allocation views, and alert on unassigned shards or on a status that stays below green after maintenance. On the server side, watch the status of each cluster node and the agent connection count per node. An uneven split usually means agents are not failing over as expected, or that a node has stopped accepting enrollments. Check dashboard availability with an external probe, and confirm that load balancer health checks exercise the service behind them. Confirm the exact endpoints and thresholds in the 4.14 documentation for your installed version.
Backups for the indexer should be tested as a restore capability. A scheduled job only shows that files were written. Register a snapshot repository on storage outside the indexer cluster, take snapshots on a schedule, and set the retention you need for alert data. Configuration needs separate handling: the server configuration files, custom decoders and rules, agent group definitions, dashboard settings, and the certificates and keys used between components. Keep these in version control or a managed configuration repository with restricted access, because the secrets in them must be protected too. Then run a restore test into an isolated environment at a set frequency. Record how long it took and what was missing, and check that agents reconnect and that alerts appear afterward. Ask your implementation partner for the restore procedure written for your version.
Upgrades on the 4.14 line need a planned sequence across all four components. Follow the Wazuh upgrade guidance for the order, which generally moves the indexer first, then the server nodes, then the dashboard, and then the agents. Upgrade one node at a time and verify it before the next one starts, so the cluster keeps serving agents during the window. Take a snapshot and a configuration backup first, and rehearse the full sequence on a staging copy built from the same topology. Confirm agent compatibility with the server version before upgrading any endpoints. The most recent release in the supplied facts is 4.14.9, dated 14 October 2026. Patch releases on this line have arrived roughly every one to two months, so the team should schedule a recurring upgrade window and retest custom rules after each one.
Documentation keeps the cluster operable when the people who built it are unavailable. Maintain current topology diagrams that show each indexer node, server node, dashboard instance, load balancer, and the agent connection paths between them. Keep a certificate inventory listing each certificate, its issuer, the components that use it, its expiry date, and a named owner for renewal. Write a failover runbook covering how to remove a failed server node, recover an indexer node, fail over the dashboard, and verify that agents reconnect, along with who approves each step. Finally, list every customized rule and decoder with its owner and the test cases that prove it still fires after an upgrade, so the retest scope is known before each change.
Ongoing support and upgrade retainers are available from DeployOpen for teams that prefer not to carry this work alone. Scope is agreed in writing before work starts, so ask exactly what is included: monitoring setup, scheduled restore tests, upgrade windows, runbook and certificate inventory updates, and retesting of custom rules. Ask how often each activity is performed and who in your organization approves changes. Also ask how a patch release that affects a component you depend on is assessed, and what your team must provide during an incident. Confirm these points in the written scope and in your own change process before go-live, so that operating responsibilities are clear from the first day.
Questions teams ask before building a clustered Wazuh deployment
How much does a clustered Wazuh deployment cost to build and run?
The self-hosted Wazuh software has no license fee, so the cost sits in services, infrastructure and staff time. One-time costs usually include scoping, sizing, building the indexer, server and dashboard nodes, configuring certificates and the load balancer, failover testing, documentation and handover. Recurring costs include compute and storage for the indexer, backups, network capacity, patching and upgrades, and any support retainer you choose. The main cost drivers are node count, event volume, retention period, number of agents, number of sites and the integrations you need. When you request a quote, ask for an itemized scope, the environments included (for example, test and production), the deliverables for each phase, which cloud or hardware costs you pay directly, which items are one-time and which recur, and the volume and retention assumptions behind the sizing. No cost figure is given here because it depends on your environment.
How long does it take to build a clustered Wazuh setup?
Duration depends on scope, the number of environments, the integrations to connect and how much time your staff can give the project. Sizing and topology decisions often take longer than the installation itself, and failover testing needs change windows that may be spaced out. Environments that must be built and validated separately, such as a non-production copy before production, add phases. Integrations with identity providers, ticketing tools or existing log sources add discovery and testing work. Staff availability is often the factor that moves dates most, especially for network, certificate and change approval teams. No duration is given here because it varies with your environment. Ask for a phased timeline in the written scope, with the dependencies on your side listed as their own items. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
Can our own team build a Wazuh cluster without a partner?
Yes, if your team already has strong Linux administration skills, certificate management experience, load balancer configuration skills and time set aside for testing. The harder parts are the ones that only show up under failure: confirming that agents reconnect through the load balancer when a server node drops, that the indexer cluster stays healthy when a node is lost, and that configuration and rule updates stay consistent across nodes. A partner typically adds experience from earlier sequencing of these builds, a tested failover plan, hardening steps, runbooks your staff can follow after handover, and training for the people who will operate the cluster. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so you keep ownership of the systems. Check the version-specific steps in the Wazuh documentation for the release you deploy.
What does our team need to provide for a Wazuh high availability project?
Most delays come from missing access or missing decisions, so prepare these before work starts. Provide access to the infrastructure where the cluster will run, including cloud accounts, hypervisors or data center network paths, and the firewall rules that agents and nodes need. Book change windows for installation and failover tests. Name an owner for each area: security, network, platform or infrastructure, identity, and the team that runs the endpoints. Supply test endpoints covering the operating systems you use so enrollment and failover can be checked. Make the topology decisions early, including the number of server and indexer nodes, the load balancer design, the placement across sites or availability zones, retention periods and who may access the stored alert data. Confirm who signs off on each phase. A written scope lists these responsibilities so both sides know what is expected.
Is Wazuh Cloud a practical alternative to running our own cluster?
Wazuh Cloud is the vendor's managed, cloud-delivered XDR and SIEM service. The self-hosted software has no license fee, so the comparison is not about license cost. It is about operating cost and control. Self-hosting means you pay for infrastructure, storage, backups, staff time for upgrades and monitoring, and the support you choose, and you keep control over where data is stored and how the platform is configured. Wazuh Cloud is offered with a 14-day free trial that needs no credit card, and its plans come in Small, Medium, Large and Custom tiers. Every paid plan includes at least Standard support. Ask the vendor for current pricing, what each tier includes and where data is hosted, since those details are not covered here. A trial can help your team measure the operating effort before you commit to either path.
How should we test failover in a clustered Wazuh deployment?
Write test cases before the change window and record the expected result for each one. Typical cases include stopping one Wazuh server node and confirming that agents reconnect through the load balancer, stopping one indexer node and checking cluster health and shard status, and confirming that the dashboard stays reachable through the expected address. Check that configuration and rule updates reach every server node after a restart, and that new alerts continue to appear in the dashboard during and after each test. Record how long agents take to reconnect and whether any events were delayed or lost, and compare the results with the requirements your security team set. Repeat the tests after each upgrade and after any change to certificates or the load balancer. Confirm the exact commands and expected states against the Wazuh documentation for your release, and keep the results as evidence for the change record.
How DeployOpen scopes, builds and hands over a clustered Wazuh deployment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Wazuh high availability, that means a written scope that covers the server cluster, the indexer cluster, agent connection paths and the capacity assumptions behind them.
How we scope
- Review your event volume, endpoint count and growth expectations before agreeing on node counts for the server and indexer clusters.
- Confirm which components need redundancy, which can run as single instances and where the load balancer sits in your network.
- Agree deliverables, exclusions and timelines in writing, since most engagements are fixed-scope before any work starts.
How we build
- Deploy the Wazuh indexer cluster, Wazuh server cluster and dashboard inside your environment using the installation method your team has approved.
- Configure certificates between components and verify that agents can reach the load-balanced endpoint and fail over cleanly.
- Test node failure, restart and recovery scenarios in a staging environment before any production cutover is scheduled.
How we hand over
- Document the cluster topology, node roles, certificate locations, configuration files and the upgrade order across components.
- Provide runbooks for adding nodes, rotating certificates, checking cluster health and responding to a failed node.
- Walk your operations team through the build and failover tests so they can repeat the checks without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live, scoped separately from the build.
- Retainers can cover patch-level updates on the 4.14 line, with a plan for re-running failover tests after each upgrade.
- Ask any provider to confirm response expectations, scope boundaries and who performs changes to production clusters in writing.
