What a Wazuh 4.14 upgrade involves and when to start
If your Wazuh 4.x deployment has run for several years with custom rules, decoders and dashboards, you should know that 4.14 is the current Wazuh release line and that moving to it is a planned change, so it needs a project plan, not a quick patch window. The upgrade touches the Wazuh indexer, server and dashboard, and every custom artifact you built sits on top of those components. Before you choose a date, inventory your custom rule files, decoder files, dashboard objects, integrations, certificates and cluster topology so you know what has to be re-checked afterwards.
Teams upgrade for two main reasons. The first is to stay on a release line that still receives patch releases. The Wazuh release notes list 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months, with 4.14.9 as the most recent release in the supplied record. Older 4.x lines fall behind that cadence, which leaves security fixes and supportability questions to resolve on your own. The second reason is access to the changes added in 4.14, which you should read in the release notes against your custom content so you can see where your rules or decoders might be affected.
The supported path from each older 4.x version to 4.14 must be confirmed in the official Wazuh upgrade documentation. Do not assume a single direct hop from any starting point. The documentation sets the required order and may call for intermediate stops, and the steps can differ by deployment type, such as all-in-one, step-by-step, Docker, Kubernetes or an offline installation. If your environment has no internet connectivity, confirm the offline package sources and steps early, because they can change your schedule. Record the exact version of every component you run today so you can match it to the documented path.
Work backward from your change windows to decide when to start. A practical first step is a lab copy of your current environment, loaded with your custom rules, decoders and dashboards, where you can run the upgrade and compare alert output before and after. Choose the target patch release close to the date you will execute, because new patch releases appear every month or two, and confirm the latest release at that time. Agree a freeze on rule and decoder changes for the upgrade window, and assign owners for each custom artifact so validation is not left to chance. Ask any implementation partner for a fixed-scope quote that lists the lab work, the upgrade steps, validation and handover as separate lines. Self-hosted Wazuh has no license fee, so most of the cost is labor, test infrastructure and the time your SOC spends on validation.
This section covers planning only. The step-by-step work for the indexer, server and dashboard, including component order, indexer shard handling, snapshots and alert checks, is covered on the central components upgrade page. Agent upgrades, which follow the central components, are covered on the agent upgrades page. Read those pages before you finalize your plan, because the order of central and agent work determines which checks you need in your change record and who must approve each stage.
Which changes in the Wazuh 4.14 upgrade affect your rules, agents and dashboards
This table lists the change categories to review when moving to Wazuh 4.14, with the impact on rules, agents and dashboards and the action to take. Where the release notes list nothing for a category, confirm that against your own environment before scheduling the upgrade. The main takeaway is that the 4.14 line shipped six patch releases between 17 March and 14 October 2026, so the target patch matters as much as the minor line.
| Change category | Impact on your environment | Action needed |
|---|---|---|
| Patch releases on the 4.14 line | Six patch releases shipped from 17 March to 14 October 2026, with 4.14.9 the latest on 14 October 2026. Each patch can carry different fixes. | Choose a target patch, then read the notes for every patch between your current version and that target. |
| New features in 4.14 | The release notes describe new capabilities. New default content can change alert volume and dashboard panels. | Review the 4.14 feature list and decide which features you will enable before the upgrade. |
| Breaking changes | The release notes section for breaking changes is the first place to check. Any change to decoder or rule behavior affects alert output. | Confirm which breaking changes apply, then test custom decoders and rules with sample logs before and after the upgrade. |
| Deprecations | Deprecated options or API calls may still work in 4.14 but stop working in a later release. Scripts and integrations are most exposed. | Inventory scripts, SOAR playbooks and integrations that call the Wazuh API or use older configuration options. |
| Indexer, server and dashboard versions | The indexer, server and dashboard must run on compatible versions of the 4.14 line. Mismatched versions can block the upgrade. | Record current versions of all three components and confirm the compatible combinations in the release notes. |
| Agent versions | Agents on older versions may need to match the central components. The release notes state the supported agent versions. | Inventory agent versions and plan agent upgrades after the central components are upgraded. |
| Custom dashboards and saved searches | Dashboard changes can alter panels that your team uses. Prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53 may also change. | Export custom dashboards and saved objects before the upgrade, then compare them with the upgraded dashboard afterwards. |
| Custom rules and decoders | Upgraded default rules can overlap with local rule IDs in local_rules.xml. Changed default decoders can alter field extraction. | Check for rule ID collisions and rerun your decoder and rule tests against representative logs. |
How the Wazuh 4.14 patch cadence changes your target version
The 4.14 line has shipped patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months. That rhythm affects how you set the target version. A target chosen early in planning can be one or more patches behind by the time your maintenance window opens. Treat the target as a deliberate decision with a date attached, based on the newest patch you verify on the day the plan is frozen. At the time of writing, the two most recent releases are 4.14.8, published on 23 September 2026, and 4.14.9, published on 14 October 2026. Check the release notes page again before you record the version in the change request.
Choose a specific patch level at planning time, such as 4.14.9 if that is still the newest release when you freeze the plan, and record it alongside the version you are upgrading from. Then read every release note between the current and target versions, not only the newest one. Each note should be mapped to the components you run: the Wazuh indexer, the Wazuh server, the Wazuh dashboard and the agents. Pay particular attention to changes in decoders, rules, default configuration, API behavior and any upgrade notes that mention custom content. Record which notes affect your custom decoders, rules and dashboards, because those are the items you will test after the upgrade.
Reserve time in the plan to re-check the target if it moves before the window opens. A newer patch often appears between the freeze date and the change window, and the team needs a defined decision point for it. Review the release notes for every version released since the freeze, compare them with your existing mapping, and decide whether to adopt the newer patch or keep the original target and document the reason. If the newer patch changes a component in your path, repeat the staging upgrade and the custom content checks before approving it. Confirm with your change board who holds the authority to change the target and by what date that authority ends.
Before you engage a partner or sign a quote, ask whether the scope covers re-checking the target and repeating staging tests if the version changes. Ask how many release notes the quote assumes you will review, how the team will map each note to your custom content, and what happens to the schedule if a new patch is released during the window. Agree on a written cutoff date for target changes. Ask who is paid for which re-check work, and whether that work recurs for each patch in a retainer. The answers determine whether a late patch becomes a small planning update or a full repeat of the upgrade rehearsal.
What to back up and inventory before the Wazuh 4.14 upgrade
Each card below names one item to protect or inventory before the Wazuh 4.14 upgrade starts, and what the team must confirm before work begins. Together they give the upgrade a known rollback point, a copy of everything the team has customized, and a baseline for checking alerts afterwards.
Indexer snapshots, configuration and certificates
Snapshots of the Wazuh indexer hold the stored alerts and indices, so they are the rollback point if an upgrade step fails. Copy the server and dashboard configuration files and the certificates and keys used between components, since a replaced certificate can stop nodes from rejoining the cluster. Confirm that a snapshot repository is registered and reachable, that a test restore has been performed on a non-production copy, and that backups are stored outside the nodes being upgraded. Follow the backup procedure in the Wazuh 4.14 documentation for exact steps and file locations.
Custom rules, decoders and lists
Local rules, decoders and CDB lists written by your team are the first items an upgrade can overwrite or leave out of step. Build a complete inventory with file names, the rule IDs and decoder names they define, and the alerts or agent groups that depend on them. Confirm that each item has a named owner, that the files are under version control or in a backup, and that the inventory matches what is loaded on every server node in the cluster. This inventory becomes the test list for checks after the upgrade.
Dashboard objects and saved searches
Custom dashboards, visualizations, index patterns, saved searches and related dashboard settings are stored as saved objects. Export them before the upgrade so the team can compare each one against its behavior after the upgrade and restore any object that fails to load. Confirm which objects analysts use daily, who owns each one, and whether any refer to index patterns or fields that the new version may change. Take the export and re-import steps from the Wazuh documentation for the version you run.
Test environment that matches production
Run the full upgrade path on a copy of production first, using the same component versions, cluster layout, agent mix, custom content and data volume wherever possible. A test system with fewer nodes or no custom rules can pass while production fails. Confirm that the test copy was built from a recent backup, that its agents or simulated agents report in, that its access to update sources matches production, and that the team has time to repeat the run after fixing issues. Record every difference that remains between the two environments.
Agent version map
Record the Wazuh agent version on every endpoint, grouped by operating system and agent group, before the central components change. The map shows which hosts are behind the central version and need planning for the agent upgrade step. Confirm where the inventory comes from, whether agents that have been offline for a long period are included, and which agent configurations are assigned to each group. The agent upgrade work that follows should start from this map.
Maintenance window and rollback criteria
Agree a maintenance window with the teams that depend on alerts, and write the conditions that trigger a rollback before work starts. Criteria may include failed cluster health checks, indices that do not recover, dashboards that cannot load key views, or alerts that stop reaching their destinations. Confirm who has authority to call a rollback, how long the team will wait before deciding, and which snapshots and copies will be restored. Set the window length from timings measured during the test run, not from estimates.
Upgrade order for Wazuh central components, with checks and rollback points
This sequence moves the Wazuh indexer, server and dashboard to 4.14 in a fixed order, with a check and a rollback point at each step so the team can stop safely before agents are touched.
Confirm the supported upgrade path
Confirm the path from your current 4.x version to 4.14 in the Wazuh documentation, and read the release notes for every version you will pass through. Note deprecated settings, changed configuration keys and any pre-upgrade steps they require. The upgrade owner signs off on the path and the list of required actions before any system changes. Check: a written record that names the target version, the release notes reviewed and each action they require. Rollback point: none is needed yet, because no system has changed.
Rehearse the upgrade on a test environment
Build a test environment that matches production in component versions, cluster layout, custom content and integrations, then run the full sequence there. Record each command, error and observation, and note how long the indexer and server steps take so the production change window is based on what you measured. Confirm that agents in the test copy still report and that alerts still appear. Check: a rehearsal log with no unresolved errors. Rollback point: discard the test copy, fix the cause and repeat the rehearsal before production.
Take and verify snapshots and configuration backups
Create indexer snapshots in a registered repository and back up the configuration directories of the indexer, server and dashboard, plus any cluster node files. Store the copies outside the nodes being upgraded. Restore one sample index to a scratch location to prove the backup is usable. Check: the snapshot reports a successful state and the test restore returns the expected documents. Rollback point: this snapshot and configuration set is the restore point for every later step.
Freeze custom rules, decoders and dashboards
Export custom rules, decoders, lists, integration settings and dashboard saved objects into version control, then pause changes to them until verification is complete. Record checksums for each exported file. The content owner and the platform lead confirm the freeze together. Check: the exported files match the recorded checksums and match what the server currently loads. Rollback point: the exported copies can be restored to the original paths if a custom file or saved object fails after the upgrade.
Upgrade the indexer in documented order
Follow the documented order for indexer nodes, including the cluster state and shard allocation settings the documentation specifies for the rolling process. Before each restart, record cluster health, node membership and shard counts. Upgrade one node at a time, wait for it to rejoin, and restore allocation settings after the last node is back. Check: cluster health, node list and shard counts match the recorded pre-upgrade state. Rollback point: halt before the next node if health degrades, and restore from the verified snapshot if data is missing.
Upgrade the server and cluster nodes one at a time
Upgrade the primary or single server first, then each cluster node in turn, as the documentation describes. Confirm each node reconnects to the cluster before starting the next one. Run the configuration validation command and check the server logs for decoder and rule load errors. Check: every node reports the 4.14 version, the cluster lists all nodes as connected and rules load without errors. Rollback point: reinstall the previous package and restore the saved configuration on the affected node, after confirming in the release notes that the indexer state allows this.
Upgrade the dashboard and check custom content
Upgrade the dashboard, then sign in and check the overview, agent list and saved views. Reapply custom dashboard objects from the frozen export only where an import failed. Send a test event through a test agent or log source to confirm that it passes through the server, is indexed and appears in the dashboard, and that a custom rule fires on it. Check: the test alert is indexed and visible and the custom rule matches. Rollback point: restore the previous dashboard package and the saved objects from the export.
Verify services and alert flow before agents
Verify that all central services are running, that rule and decoder loading is clean and that alerts from known sources arrive as expected across the full path. Record the results in a signed verification record. Only after this sign-off do agent upgrades start, and they follow their own sequence and checks. Check: the signed verification record lists each check as passed. Rollback point: keep the central snapshots and configuration backups available until the record is signed, because agents are not upgraded until then.
Checks after the Wazuh 4.14 upgrade on custom rules, decoders and dashboards
Custom content is where a Wazuh upgrade fails quietly. Decoders, local rules and dashboards can all load without errors while still producing the wrong fields, levels or groups, so each custom element needs a test against known inputs before the upgrade is signed off. Start by building a log corpus for every custom decoder: representative samples from each source, plus malformed and edge-case lines that your team has seen in production. Record the fields each decoder extracts on your current version, then run the same corpus through the 4.14 server and compare the output. Before you begin, confirm which log test utility, procedure and sample format the 4.14 documentation describes, and use only those, so your results can be reproduced later.
Next, confirm that every custom rule still fires as expected. Export your local rules and list each rule ID, level and group. Replay the corpus and check that each ID triggers on the samples it should, at the same level, and carries the same groups that your dashboards, correlation logic and compliance mappings depend on. Review the rule override and ID range work in the same pass. Look for local rules that override a default rule, and confirm that the parent rule they depend on was not renumbered, reworded or re-levelled in 4.14. Check that no custom ID falls outside the range you reserved for local content, and that no two rule files define the same ID. A collision that loads without error can silently suppress one of the rules.
Dashboards come third. Open each saved search, visualization and index pattern that your team uses and confirm that it still resolves its fields. A field renamed or re-typed by a decoder change will show as empty data rather than as an error, so compare counts for a known time window against your pre-upgrade baseline. Then check the prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53. Confirm that each view loads, that the controls it shows still map to rules that fire, and that your custom rules tagged for those frameworks appear where expected. These views are technical evidence for your own review. They do not establish compliance, and your assessor will decide what they show.
The last group covers identity and integrations, which are often tested too late. If you use SAML single sign-on, confirm that a login works for each role your organization uses, that group-to-role mapping still assigns the correct permissions, and that the internal administrator account still works as a documented fallback. Then check each downstream consumer: alert forwarding, API clients, ticketing or SOAR playbooks and any other SIEM that reads Wazuh output. Confirm that each one receives the alert fields and formats it expects. Ask the vendor or your integration owner which of these behaviors 4.14 changed, and test those first.
Define pass criteria before the upgrade starts, and agree the rollback trigger with the owners of detection, identity and reporting. A reasonable starting set is: every corpus sample yields the same fields as the baseline, every custom rule fires at its documented level and groups, no rule ID collision or unexpected override exists, every saved search and compliance view loads with expected data, and every SSO role and downstream integration passes. Any failure that stops detection on an in-scope log source is a rollback trigger, as is an unresolved field change that breaks an alert consumer. Confirm the rollback steps the 4.14 documentation describes, and make sure they are tied to the backups and snapshots taken during the central components upgrade.
What makes a Wazuh 4.14 upgrade take longer
This table lists the factors that most often stretch a Wazuh 4.14 upgrade and explains why each one adds work. Read each row against your own environment to see which factors apply and where to spend planning time. The main takeaway is that effort usually comes from custom content, data volume and approvals, more than from the package upgrade itself.
| Driver | Why it adds effort | How teams reduce it |
|---|---|---|
| Custom rules and decoders | Each custom rule or decoder must be checked against changed behavior and may need edits or retesting. Older, undocumented content takes longer to trace. | Keep content in version control, record each item's owner and purpose, and retest a sample of alerts after the upgrade. |
| Cluster size | More server and indexer nodes mean more ordered steps, more health checks and more points where a node can fall out of sync. | Write down the node order, run health checks between nodes, and rehearse the sequence in a test cluster. |
| Deployment method | All-in-one, step-by-step, OVA, Docker, Kubernetes, Ansible, Puppet and offline installs each follow a different upgrade path and tooling. | Confirm the documented path for your method and keep configuration management code aligned with the target release. |
| Indexer data volume and snapshot time | Large indices lengthen snapshots, restore tests and the rebalancing each node performs during a rolling upgrade. | Check snapshot repository capacity and timing before the window, and confirm that a restore test has succeeded. |
| Customized dashboards | Each custom dashboard, saved search or visualization that uses changed fields must be reviewed and sometimes rebuilt. | Export dashboards as saved objects, list the fields each one uses and assign an owner to verify each dashboard. |
| SSO and downstream integrations | SAML settings, API clients, syslog forwarders and SOAR playbooks each depend on endpoints or fields that can change. | List every consumer, confirm its supported versions and test sign-in and forwarding in a staging environment. |
| Test environment availability | Without a staging copy of your data and content, problems surface in production and the rollback path stays untested. | Build staging from a recent backup that includes your content, integrations and agent configuration. |
| Change control requirements | Approval boards, freeze windows and evidence requirements add review cycles before and after the change window. | Submit the change package early, define success checks and rollback criteria, and attach test results. |
How much effort and time does a Wazuh 4.14 upgrade need?
What does a Wazuh 4.14 upgrade cost when the software is free?
The Wazuh software is open source under the GNU General Public License version 2 with no license fee, so the cost is labor, infrastructure and testing time. Labor covers planning, backups, the component upgrades, agent coordination and verification. Infrastructure covers any staging environment built to rehearse the upgrade and the storage needed for backups and snapshots. Testing time covers replaying sample events and checking custom content. Ask for a quote built from a written scope that lists the components and nodes in scope, the custom rules and decoders covered, and the environments included. Separate one-time upgrade work from any ongoing support or retainer you choose afterward.
What drives the time a Wazuh upgrade takes?
The main drivers are the size and shape of the deployment: how many indexer, server and dashboard nodes exist, whether the server runs as a cluster, and how many agents report to it. Customization adds work in proportion to the number of custom rules, decoders, dashboards, integrations and SSO configurations that need review after the move. Change control sets the pace too, including approval cycles, freeze periods and how many maintenance windows you can use. Offline or air-gapped placement adds packaging and transfer steps. Confirm in the release notes and upgrade documentation for your starting version whether intermediate steps apply before you agree a schedule.
What does our team need to provide for the upgrade?
Expect to provide administrative access to the indexer, server, dashboard and any hosts or load balancers in scope, plus access to the backup targets. Name an owner for each set of custom rules, decoders and dashboards, someone who can explain intent and approve behavior changes. Reserve a maintenance window for each stage and agree in advance who can call a rollback. Sign-off should come from a named security owner who confirms that alerts still fire, dashboards still load and integrations still deliver. Also provide your change calendar, identity contacts if SAML single sign-on is in use, and an inventory of agents and endpoint groups. Missing inputs are the most common reason scopes slip.
Can our own team upgrade Wazuh without an outside partner?
Many teams can upgrade in-house if they have Linux administration skills, experience running clustered search and analytics components, and a staging environment that resembles production. The risks of going alone are specific. Teams may skip the backup and snapshot steps the documentation calls for, mis-order component upgrades, mishandle indexer shard allocation during rolling steps, or miss breakage in custom rules and decoders. The most serious failures are often silent, with alerts that stop or degrade without an obvious error. Consider a partner when the team lacks capacity during the window, has no staging copy, or needs independent verification before sign-off. A fixed scope agreed in writing can cover part of the work.
How does the Wazuh patch cadence affect upgrade planning?
Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, roughly one every one to two months, according to the Wazuh release notes. The latest listed release is 4.14.9, published on 14 October 2026. Planning should treat the target version as a moving point. Decide early whether the project targets the latest patch at the time of the change window or a fixed patch level, and record that choice in the scope. Frequent patches mean repeated regression checks, so build a repeatable test pack. Review the release notes before each window and agree who approves patch application outside the project.
How do offline or air-gapped Wazuh upgrades differ?
Offline upgrades add packaging, transfer and verification steps. Wazuh documents an offline installation guide for systems without internet connectivity, and that guide should be your baseline for the target version. Vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform, so confirm which data source your environment uses and how content updates reach it. Plan how installation packages, repository content and any agent upgrade files cross your transfer boundary, and who approves each transfer. Test in an environment that matches the air-gapped one. Each transfer and approval adds a queue, so ask for the timeline to show those waits explicitly.
How much testing effort do custom rules and dashboards need?
Testing effort depends on how many custom rules, decoders, dashboards and integrations exist, and on how well each is documented. Start by building a baseline before the upgrade: sample events for each important log source, the alerts each should produce, and screenshots or exports of key dashboards. After the upgrade, replay the same events and compare the results. Differences in rule matching, decoded fields or dashboard queries need an owner to decide whether the change is intended. Ask any partner to show the test cases, the acceptance criteria and who signs off on each category before work starts.
How DeployOpen scopes and delivers the Wazuh 4.14 upgrade
DeployOpen scopes the Wazuh 4.14 upgrade as a fixed-scope engagement, with deliverables agreed in writing before work starts. The work runs in your own infrastructure, and custom rules, decoders and dashboards are checked after the move. Ongoing support is available as a retainer once the upgrade is complete.
How we scope
- The written scope names the source version, the 4.14 patch release chosen and the components in the upgrade.
- Custom rules, decoders, integrations and dashboards are inventoried so each one has a named check after upgrade.
- Deployment method is confirmed, whether step-by-step, Docker, Ansible, Puppet or offline, before any change is planned.
How we build
- Backups and snapshots are taken and restore is tested before any production component changes version.
- Components are upgraded in the order the Wazuh documentation sets, with cluster steps followed on the server.
- Custom rules, decoders and dashboards are tested against sample events from your environment in a staging copy.
How we hand over
- Written records cover the versions run before and after, the steps taken and the rollback path.
- Changed rules, decoders and dashboards are listed with their test results and owners named by your team.
- Your team walks through the post-upgrade checks so the runbook matches the running system.
How we support
- Patch releases after the upgrade are reviewed against your environment before any update is scheduled.
- Each later patch release is assessed for changes that affect your custom rules and dashboards.
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
