Wazuh central components upgrade

The indexer, server and dashboard must be upgraded in a fixed order because each component depends on the one beneath it to store, process and display security data. Wazuh has four components. The Wazuh indexer is a full-text search and analytics engine that stores alerts. The Wazuh server analyzes data from agents using decoders and rules, and it can run as a cluster to scale horizontally. The Wazuh dashboard is the web interface where analysts search and review alerts. Wazuh agents sit on endpoints and send their data to the server.

The dependencies explain the sequence. The server writes its output into the indexer, so the indexer has to accept the data the server will produce after its upgrade. The dashboard reads from the indexer and queries the server, so it goes last. If the dashboard moves first, it can point at a server still running the older release, and the views may fail or show incomplete results. Before the window opens, read the compatibility guidance for your target release and confirm which indexer, server and dashboard combinations Wazuh supports. Record the current versions of all three so you can reconstruct the starting state if a step fails.

The server also manages agent configuration and handles agent upgrades remotely. This makes it the control point for what endpoints receive. A server upgrade can change the configuration that agents pull and the versions they are permitted to move to, so the central plan has to account for the agent fleet even though agents are not upgraded in this step. Confirm which agent versions the target server supports, check how many endpoints are still on older releases, and decide whether agent work will wait until the central stack is stable. Agent upgrades are covered on the separate Wazuh agent upgrades page in this group.

In practice, the order gives each step a clear test. After the indexer is upgraded and its cluster reports healthy, confirm that it accepts new data and that existing indices are readable. After the server is upgraded, confirm that agents still check in, that decoders and rules load without errors, and that new alerts reach the indexer. After the dashboard is upgraded, confirm that saved searches, dashboards and alert views return data from the indexer. Assign one owner to each gate and agree in advance who can stop the work if a gate fails.

Restarting indexer nodes one at a time keeps the cluster searchable and protects alert data, but only if each step waits for the cluster to recover before the next node is touched. The Wazuh indexer is a full-text search and analytics engine that stores alerts, so a node restart is not a cosmetic event. Every primary shard on that node has to move or wait, and every replica that was on it has to be rebuilt somewhere else. The team's job is to control that movement so the cluster never has to guess which copy of a shard is authoritative.

During a node-by-node restart, teams commonly limit shard allocation to primaries. The reasoning is that when a node leaves, the cluster should not start copying replicas onto other nodes while the node is briefly absent and may return with its data intact. Restricting allocation keeps the cluster from creating large amounts of replica traffic on every restart and from reshuffling shards that would have recovered on their own. Confirm the exact allocation setting name, its accepted values and the command that sets and resets it in the Wazuh documentation for your target version. Do not copy it from an older runbook, and record the value you started with so you can restore it after the final node. Between nodes, health is checked against the cluster state rather than against the time elapsed. After a node rejoins, the team looks at cluster health, the count of unassigned shards and whether any recovery is still running. The indexer's own health reporting is the authority here. Agree in advance which status you will accept before the next restart, whether unassigned shards must be zero, and how long the team will wait before escalating. Those thresholds belong in the change record, not in someone's memory during the window. The rule that matters most is that the cluster must return to a healthy state before the next node is touched. Restarting a second node while shards are still recovering can leave a primary with no available copy, and that is the failure that turns a routine window into a restore from snapshot. If health does not recover within the agreed window, stop, keep the remaining nodes running, investigate the blocking shards and decide with the change owner whether to roll back the node already upgraded. Plan that rollback path before the first node restarts, and confirm snapshot availability first.

Write the acceptance criteria before the maintenance window opens, not during it. Each check should name the evidence that proves it passed. First, confirm that every agent in the inventory shows as active on the upgraded Wazuh server, and that agents disconnected before the window reconnect without manual re-registration. Second, generate a known test event on a monitored endpoint and confirm the resulting alert appears in the Wazuh indexer with a current timestamp. Third, replay a set of known test events through your custom decoders and rules, and confirm that each expected rule fires with its expected level and fields. Keep the test events and their expected outputs in version control so the same set runs after every upgrade.

Next, cover the user-facing and intelligence paths. Load the main dashboard views and each compliance dashboard your organization relies on, such as the PCI DSS, GDPR, HIPAA or NIST 800-53 views, and confirm that panels return data for the expected time range. If single sign-on is configured through SAML, test a login for each identity provider group and check that role mappings still apply. A broken federation can lock administrators out while the rest of the platform looks healthy, so test it deliberately. For vulnerability detection, confirm that the vulnerability data is updating from the Cyber Threat Intelligence platform or from your offline repository, whichever your environment uses, and that a test agent's software inventory is being correlated against it.

Decide in advance whether a failed check leads to rollback or fix-forward. The change owner should make that call, with the security operations lead providing the view of alert flow and a named approver for any service impact. Put the criteria in the change plan. A server that rejects agents or an indexer that stops receiving alerts usually justifies rollback, while a single broken dashboard panel or a non-blocking decoder warning usually justifies fixing forward within a time limit the plan sets. A rollback is an option only if snapshots were taken before the window and the restore path was tested. If neither exists, the team is committed to fix-forward, and the plan should state that openly so nobody discovers it mid-window.

Close the section by recording evidence. Save the test event identifiers, rule outputs, agent status export, dashboard check results and login results, each with a timestamp, in the change record. Set a monitoring period in the plan during which the security operations team compares alert volume against the baseline taken before the window, and agree who signs off the window when that period ends. Confirm with your own team and the Wazuh documentation which checks apply to your deployment type, including any offline installation, because the steps for vulnerability data differ there.