This guide shows how to build a Wazuh 4.14 cluster setup with a high availability design, with more than one manager node and more than one indexer node. If one server goes down, the rest keep working, so you do not lose security events or search access.
This is not a basic install guide. If you have not installed Wazuh before, start with the Wazuh SIEM setup guide for VPS infrastructure, which covers a single server. This guide covers many servers working as one cluster.
An all-in-one Wazuh install runs the manager, the indexer, and the dashboard on one machine. That machine is a single point of failure. One kernel panic, one disk full error, one bad update, and monitoring stops.
A Wazuh cluster setup splits the three roles onto separate machines and adds redundancy inside each role:
The whole point of this setup is horizontal scale and fault tolerance for environments with many monitored servers.
A real Wazuh 4.14 cluster setup with high availability deployment needs at least six machines. You need three indexer nodes, two manager nodes (one master, one worker), and one dashboard node. You can add more manager or indexer nodes later if you monitor more agents.
Note: Wazuh indexer clusters need an odd number of nodes, like 3, 5, or 7. This lets the cluster always pick one master node. It's a hard rule, not a tip; a two-node cluster can get stuck with no clear leader if the network splits.
Sizing depends on your agent count and events per second (EPS). Here are the safe options to start for a mid-size environment monitoring 200 to 500 agents:
Since each role runs on its own machine, this is a good time to use separate servers instead of one big and oversized server. PerLod's dedicated server hosting plans give you the isolated CPU, RAM, and NVMe storage that manager and indexer nodes need.
You must open these ports between the nodes before you install anything. Missing ports are the most common reason a Wazuh cluster fails to run.
Note: Only allow ports 1516 and 9300–9400 on your private network. These are internal cluster ports, so never open them to the public internet.
The steps below cover every stage of a working Wazuh 4.14 cluster setup in the right order. To build your cluster setup, follow the steps below:
You must set up the machines from the sizing table. Use the same Linux version on all of them, such as Ubuntu 22.04/24.04 or RHEL 8/9. Give each node a unique hostname, and make sure every node can reach every other node on the ports listed above.
Also, turn off auto-updates for the Wazuh repositories for now. You'll turn them back on later, on purpose, so every node stays on the same version. If managers drift to different versions, cluster sync breaks.
Remember to sync the clock on every node, since certificates and cluster communication are sensitive to time differences:
Wazuh 4.14 uses a single script, wazuh-certs-tool.sh, to generate a root CA and per-node certificates for the indexer, manager, and dashboard nodes in one pass. You must run this on any one machine, not on every node individually.
Download the tool and the sample config file with:
Now open config.yml for editing and replace its content with your own node list:
Paste this with your own names and IP addresses, then save and exit:
Generate all certificates in one run with the command below:
This creates a wazuh-certificates/ folder with a root CA, an admin certificate, and one certificate pair per node named after the name field you set in config.yml. Compress the folder and copy it to every node with scp:
Note: Keep the root CA files somewhere safe offline. You will need them again if you add a node later.
You must repeat this step on indexer-1, indexer-2, and indexer-3. First, add the Wazuh package repository. We assume you have a running Ubuntu OS:
The install creates a default opensearch.yml file. Open it for editing on each node:
On indexer-1, replace the relevant lines with:
Once you are done, save and exit. Repeat this on indexer-2 and indexer-3, only changing network.host and node.name to match each node. The cluster.initial_master_nodes, discovery.seed_hosts, and plugins.security.nodes_dn lists must be identical, with the same three entries, on all three nodes. This is exactly how the nodes discover and trust each other.
Deploy the certificates on each node; replace NODE_NAME per node:
Then, open the JVM options file and set the heap to about half the node's RAM:
Change these two lines, example for a 16 GB node:
Start the service on each of the three nodes:
This is the step people forget, and it is the difference between three separate indexer installs and one actual cluster. Run this command on only one of the three indexer nodes:
Confirm all three nodes joined correctly:
You should see three rows, one for each indexer node, with roles like data,ingest,master. If you only see one row, check discovery.seed_hosts and the firewall rules on ports 9300–9400. The rest of the Wazuh 4.14 cluster setup depends on this step working.
At this point, you must repeat the repository setup and package install on manager-1 and manager-2:
Generate a shared cluster encryption key once on the master node, and reuse the same value on every manager node:
Copy the output somewhere safe, then open the manager config file on manager-1 (the master):
Add this <cluster> block anywhere inside the <ossec_config> tags, then save and exit:
Now open the same file on manager-2 (the worker):
Use the same key and cluster name, but change the node identity and role:
The <nodes> tag always points to the master's IP, even in the master's own file. Wazuh only allows one master per cluster, so this list should have just that one address. Restart the manager service on both nodes:
Every manager node needs Filebeat to ship alerts to the indexer cluster. Install it and download a fresh config file on both manager-1 and manager-2:
Open the new file and point it at all three indexer nodes, not just one:
Set the output block like this, then save and exit:
You can store the indexer admin credentials in the Filebeat keystore instead of plain text:
Then, download the alert template and the Wazuh Filebeat module:
Create the certificate folder and copy the manager's own certificate into it, same pattern as the indexer step:
Repeat the certificate step with NODE_NAME=manager-2 on the second manager. Start Filebeat on both nodes and confirm the connection:
A working result ends with talk to server... OK.
On dashboard-1, you must install the package and set up its certificate folder the same way as before. Use NODE_NAME=dashboard-1, save to /etc/wazuh-dashboard/certs/, and rename the files to wazuh-dashboard.pem and wazuh-dashboard-key.pem.
Open the dashboard config file with the following command:
Point it at your indexer cluster with:
Save and exit, then open the Wazuh app config file:
Point it at your manager cluster's master node:
Start the dashboard and browse to https://10.0.0.31:
Agents can register with any manager node, but you want new agents spread evenly between manager-1 and manager-2, not stacked on just one. Wazuh 4.14 has a built-in load balancer for this, called the HAProxy helper. Open the master's config file again:
Add this block inside the existing <cluster> block on the master node:
This tells the master to talk to HAProxy and automatically move agents around whenever a worker has too many connections.
If you would rather not run HAProxy, just point agents at a round-robin DNS record or a Layer 4 load balancer that forwards TCP 1514/1515 to both managers. Both ways work for a Wazuh 4.14 cluster setup.
On each agent, open its config file:
List every manager node so the agent can fail over if one is unreachable:
Save, exit, and restart the agent service:
At this point, you can confirm both manager nodes see each other:
Expected output shows both nodes with a version and role:
Or from the dashboard, go to Server management > Dev Tools and run:
This shows each node's name, role, version, IP, and agent count.
A cluster you have not tested is not actually high availability; it is just a guess. Before putting real traffic on it, you must break it on purpose.
Stop the worker manager and watch agents reconnect to the master:
Run cluster_control -l from the master. The stopped worker should drop off the list within the frequency time you set earlier, 60 seconds by default. Agents that had both manager IPs should now show as connected to the surviving node in the dashboard's agent list.
Stop one indexer node and confirm the other two keep serving data:
Run the cluster health check again:
The status field should show yellow, which means one copy is missing, but data is still fully searchable. If it shows red, fix your indexer replication settings. Then, bring the stopped node back and check that status returns to green.
A full Wazuh 4.14 HA cluster build requires extra setup time, but you get something a single server can't provide. You can lose a manager or an indexer node and keep collecting security events with no gap.
Once the certificates, manager cluster block, and three-node indexer are working, adding more capacity later just means repeating steps 3 and 5 with a new node name and IP.
We hope you enjoy this guide. For more detailed information, you can check the Wazuh indexer cluster certificate deployment documentation.