What upgrades and support involve for Wazuh
Upgrading Wazuh is recurring work. The 4.14 line received six patch releases between 17 March and 14 October 2026, and each one requires a decision about whether and when to apply it. Wazuh has four components: the indexer, the server, the dashboard and the agents on endpoints. They must be upgraded in a planned sequence so that each component stays compatible with the others during the change. Confirm the required order and version compatibility for your target release in the Wazuh release notes before you schedule any work.
Four situations usually start an upgrade. A patch or minor release that fixes a security issue needs fast assessment, using the release notes to see which fixes it contains. A planned move to a newer line is a larger project because it can change decoders, rules and interfaces. A change in the environment, such as a new operating system version or a move to another cloud, can affect agent packages and enrollment. The last trigger is an agent fleet that has drifted across versions. Inventory agent versions before each upgrade cycle and treat any drift as a finding to close.
Teams with a Linux operations bench and a test environment that mirrors production can often handle patch upgrades in-house, provided one person owns the sequence and the rollback plan. Outsourcing becomes more attractive when staffing is thin, the agent fleet is large, or custom rules and decoders are heavily customized, because each upgrade then requires regression testing of local content. Whichever route you choose, request a written scope that names the components and agent groups covered, how custom rules are retested, who owns rollback, and what support hours apply.
What the work includes and what you receive
The upgrade engagement is a fixed body of work with defined deliverables. Ongoing support is a separate retainer, and its terms are set in the written scope.
Version inventory of every component
We record the running version of the Wazuh indexer, server, dashboard and every enrolled agent group, along with the OS, Java and plugin dependencies each one relies on. Mixed agent versions are the most common surprise during an upgrade, so this inventory sets the target for each component and shows which agents need their own update window.
Ordered upgrade runbook
The runbook sequences the upgrade across indexer, server, dashboard and agents, with a pre-check, action, and verification step for each stage. It states the order in which components move, what must stay compatible during the transition, and the go or no-go criteria at each gate. Your operations team can follow it without the implementation team present.
Staging upgrade rehearsal
We run the full upgrade path against a staging copy built from production configuration and representative data. The rehearsal exposes configuration drift, decoder breakage and timing problems before the production window. Ask the partner which production settings the staging environment does not reproduce, such as data volume, network paths and agent counts.
Regression tests for custom content
Custom decoders, rules, dashboards and SAML SSO settings are tested against known log samples and expected alerts after the upgrade. Tests compare alert levels, group membership and login flows with the pre-upgrade baseline. Any change in behavior is recorded and either fixed or accepted by your owner in writing.
Rollback plan with backup verification
The rollback plan defines how each component returns to its prior version, and the backup set is restored in staging to prove it works before production begins. Confirm which snapshot and index backups exist, where they are stored, and how long a restore takes in your environment, since indexer restores are often the longest step.
Production change window
The production window is planned with your change board, with named roles for each step, a communication plan for SOC analysts, and a fixed sequence for agent connectivity checks. Agreeing the window in advance avoids unplanned overlap with other changes and keeps alert handling staffed during the work.
Post-upgrade validation
After the change, we check agent connectivity across each enrolled group and confirm that events flow from endpoints through the server into the indexer and onto dashboards. Validation also confirms that test alerts fire as expected. Ask for the list of agent groups and log sources you want covered so nothing is skipped.
Change log of customizations
The change log lists each custom decoder, rule, dashboard, SSO setting and configuration file touched by the upgrade, with the before and after state. It gives your team a record for future upgrades and audits. Review it with your engineers so every customization has a named owner.
Handover notes and test record
The test record captures each regression and validation result with its evidence, and the handover notes describe the new versions, known issues, and the steps your team owns going forward. Together they let your operators run the next upgrade cycle and show reviewers how the change was verified.
What drives effort and how to keep it down
This table lists the factors that enlarge a Wazuh upgrade, why each one matters and how to limit its effect on the work.
| Driver | Why it matters | How to limit it |
|---|---|---|
| Agent count and operating systems | Linux, Windows, macOS, Solaris, AIX and HP-UX each need their own compatibility check before an agent upgrade. | Group agents by OS and version, pilot one host per platform, and roll out in waves through agent groups. |
| Indexer and server cluster nodes | Each node in the indexer and server cluster must move through the upgrade in order, and mixed-version states extend the work window. | Document node roles and upgrade order in advance, and capture a rollback point for each node before starting. |
| Custom decoders and rules | Each custom decoder or rule may depend on fields or behavior that changed in a newer release and needs retesting. | Keep customizations in version-controlled files, maintain a regression log set, and retire rules that duplicate built-in content. |
| SAML and other integrations | Each identity provider, ticketing system or API integration has its own settings and test steps after the server changes. | Limit integrations to those in use, document settings for each one, and test sign-in with a break-glass account. |
| Air-gapped operation with offline vulnerability repository | Offline hosts need packages and vulnerability data carried in by hand, which adds transfer and validation steps to each release. | Confirm the offline installation path for the target version, and refresh the offline repository alongside each patch cycle. |
| Number of test environments | Each environment needs its own upgrade rehearsal, so the environment count multiplies the testing effort. | Limit environments to a lab, a staging copy that mirrors production, and production, and script repeatable checks. |
| Compliance dashboards in use | PCI DSS, GDPR, HIPAA and NIST 800-53 views each need a review of mapped rules after an upgrade to confirm they still display correctly. | Enable only the frameworks your assessors use, and add a dashboard check for each enabled framework to the upgrade test plan. |
| Distance from current patch level | Wazuh shipped 4.14 patch releases on six dates in 2026, so a long gap means more changes to review in a single upgrade. | Schedule regular patch-level upgrades within the 4.14 line, and read the release notes for each step before booking the change. |
Upgrade and support phases
The sequence moves a Wazuh 4.14 deployment to a newer patch level with a documented plan, a rehearsed upgrade and checks that confirm detection still works after go-live.
Inventory versions, configuration and custom content
The partner records the running version of each Wazuh component, the agent versions across endpoint groups, the configuration files, custom decoders and rules, integrations and SSO settings. The output is a written inventory that lists every item the upgrade could touch, with owners marked for each integration.
Plan the sequence, change windows and rollback criteria
The team agrees the upgrade order across the indexer, server, dashboard and agents, sets change windows with your operations owners and defines the conditions that trigger rollback. The output is a written change plan with checkpoints, named approvers and backup points. Ask the partner for phase timing in the written scope, and confirm the upgrade order against the official Wazuh upgrade documentation for your exact versions.
Rehearse the full upgrade on a staging copy
The team runs the complete upgrade on a copy of production that holds the same configuration, custom rules and agent groups. Regression tests then confirm that custom decoders still parse sample events, rules still fire on test data and dashboards still load. The output is a rehearsal report listing each failed test and its fix, which becomes the input for the production runbook.
Upgrade production in order with checkpoints
The team upgrades the indexer first, then the server, then the dashboard, and then the agents, pausing at a checkpoint after each step. At every checkpoint they confirm cluster health, service status and log errors before continuing. The output is a signed change record with the version reached at each step and any deviation from the runbook.
Validate alert flow, agent check-in and access
After the upgrade, the team checks that events flow from agents through the server into the indexer and appear as alerts, that agents report back to the server within the expected interval, that dashboards show current data and that SAML or other SSO logins still work for each role. The output is a validation checklist signed by your security operations lead.
Hand over or onboard to a support retainer
The partner delivers an updated runbook, the inventory, the rehearsal and validation records, and a list of known open items, then walks your team through them. If you choose a retainer, the scope sets which patch releases are covered, how staging rehearsals recur and how issues are escalated. The output is an accepted handover record and, where applicable, an agreed retainer scope.
What goes wrong and how to prevent it
Most Wazuh upgrade incidents trace back to a small set of predictable gaps in sequencing, testing and recovery. Each card names the failure and the check that prevents it.
Agents upgraded ahead of the server
Agents are upgraded before the Wazuh server supports the newer agent version, so the server may not handle their data correctly or may reject their connections. Pin the upgrade order so the server and indexer move first, then agents in rings. Confirm agent and server compatibility for each target version in the release notes before scheduling any endpoint change.
Indexer and dashboard version mismatch
The indexer, server and dashboard are upgraded at different times, so the dashboard runs against an indexer version it does not match, and views or saved searches fail. Write one order for the change, normally indexer first, then server, then dashboard, and verify each step before starting the next. Check the release notes for each target version to confirm the required pairing.
Custom rules that stop firing silently
A custom rule or decoder that depended on a changed default, field name or rule ID can stop matching after an upgrade, and nothing reports the gap. Keep a regression test set of sample events with the alerts each one must produce, and run it on staging and again after every change. Review custom rule IDs against the release notes for the target version.
SAML settings that fail after a change
Certificates, entity IDs, callback URLs or group attribute mappings in the SAML configuration can break when the dashboard or its certificates change, and administrators can lose access. Test a full sign-in and role mapping for an administrator and a read-only user on staging before the window. Keep a documented local administrator recovery path, and confirm SAML behavior in the target version's release notes.
Rollback and restore never rehearsed
Teams write a rollback plan but never run it, and backups exist but have never been restored into a working indexer and server. Rehearse the rollback on a staging copy of the production configuration, and run a full restore test before each change window. Record every step that needed manual correction so the runbook reflects what actually works.
Agents left on mixed versions
Endpoints drift onto different agent versions over months, so detection behavior and troubleshooting differ from host to host, and gaps stay open unnoticed. Generate a fleet version report from the server each cycle, grouped by agent group and operating system. Use it to schedule the next upgrade wave and to confirm which hosts still need the target version.
Recurring costs after go-live
This table lists the recurring cost components of running Wazuh 4.14 yourself, who pays for each one, and what drives the amount up or down, noting that the self-hosted software carries no license fee.
| Cost component | Who pays or does the work | One-time or recurring | What drives it |
|---|---|---|---|
| Test environment infrastructure | Your platform team, through your cloud account or data center budget | Recurring | Node count, indexer storage and how long the test copy runs in each patch cycle |
| Backups of indexer and server data | Your platform or operations team | Recurring | Alert volume, index retention period and how often backups are tested for restore |
| Release monitoring and change approval | Your security operations and platform staff | Recurring | Six 4.14 patch releases shipped from 17 March to 14 October 2026, so review cycles arrive often |
| Patch cycle effort (retainer or internal hours) | A partner under a retainer, or your own staff hours | Recurring, per patch cycle | Number of components affected, custom rules to retest and whether a cycle crosses minor versions |
| Linux, indexer and certificate operations | Internal staff, or a partner if you outsource operations | Recurring as staff time | Number of indexer, server and dashboard hosts, cluster size and certificate rotation schedule |
| Rule and decoder maintenance | Internal security engineers or a partner | Recurring | Number of custom rules and decoders, and how many must be retested after each upgrade |
| Vendor support subscription (optional) | Wazuh, if you buy a plan | Recurring if you choose one | Confirm with Wazuh what support covers self-hosted deployments, since Standard support is documented for Wazuh Cloud plans |
| Wazuh Cloud subscription (separate option) | Wazuh, as a separate managed service | Recurring | Small, Medium, Large or Custom tier. Every paid plan includes at least Standard support. A 14-day free trial is available |
How the work differs by environment
Package installs on connected hosts follow the standard upgrade path and can pull feed updates directly. The plan centers on the order of component upgrades and the maintenance window for each.
- Update order: Plan the indexer, server, dashboard and agent sequence from the upgrade documentation for your exact target release in the 4.14 line.
- Patch cadence: Recent 4.14 patches have shipped roughly every one to two months, so schedule a recurring review of the release notes.
- Feed access: Confirm that the server can reach the Cyber Threat Intelligence platform outbound, and document any proxy settings.
- Rollback: Confirm with the vendor documentation which backups or snapshots restore each component.
In these models, the image, chart or appliance version sets the upgrade path. Upgrades usually mean deploying a new versioned artifact and migrating persistent data.
- Version pins: Pin the image tag, chart version or appliance build so an unplanned pull cannot change the running release.
- Persistent volumes: Confirm where indexer data, server configuration and certificates are stored, and back them up before any replacement.
- Appliance changes: For OVA and AMI deployments, confirm whether in-place package upgrades are supported or whether a new image is the documented path.
- Chart and image defaults: Review changed default values in each chart or image release before applying it.
Offline environments depend on the offline installation guide and an offline vulnerability repository in place of the Cyber Threat Intelligence platform. Feed updates must be carried in through a controlled process before the upgrade plan can rely on them.
- Package transfer: Stage component packages and dependencies through an approved transfer process, and record hash verification for each file.
- Repository refresh: Define who imports offline vulnerability data, how often it happens, and how each import is logged and reviewed.
- Staging enclave: Test each upgrade in a staging environment that mirrors the production package set.
- Confirm with vendor documentation: Which offline repository format and update steps apply to your target release.
Configuration management makes upgrades repeatable, but playbooks and modules carry their own version dependencies. Changes to component versions should move through the same test pipeline as application code.
- Version pins: Pin Wazuh package versions and role or module versions, so a routine run does not upgrade components unexpectedly.
- Idempotency tests: Run the upgrade against a test host, then run it again and confirm that the second run makes no changes.
- Restart order: Confirm that handlers restart or upgrade components in the order the upgrade guide requires.
- Module support: Confirm with the role or module maintainers that their version supports your target 4.14 release.
An install on an earlier 4.x release may need a multi-step path to 4.14, which changes the sequence and the number of change windows. The first task is to record the exact version of each component.
- Version inventory: Record the indexer, server, dashboard and agent versions separately, since they may not match.
- Intermediate stops: Confirm from the release notes whether an intermediate release is required before moving to 4.14.
- Customizations: Retest custom rules and decoders at each stop, because rule changes between releases can alter alert output.
- Agent compatibility: Confirm which agent versions the server supports during the transition, and schedule agent upgrades to match.
What you need to provide
Your team needs to provide the inputs below before a Wazuh upgrade or support scope can be priced and written. Administrative access comes first: root or equivalent on each indexer, server and dashboard host, admin credentials for the Wazuh API and dashboard, and access to the agent management interface. Add a current inventory of enrolled agents with their operating systems and installed agent versions, since the upgrade order depends on which agents are behind the server.
Provide copies of everything you have changed from the defaults: custom decoders, custom rules, saved dashboards, and integration configuration for ticketing, notification or SOAR tools. Include the SAML or other SSO settings for the dashboard, together with test accounts for each role you use, so access can be checked after the upgrade. Locate your backups and confirm that someone on your side can restore them, because a rollback plan is only as good as the restore access behind it.
Confirm whether a staging environment exists or whether you want one built as part of the work. It should mirror the production indexer, server and dashboard versions and carry a representative set of agents. Name a change window and an approver who can accept a rollback decision. Name the owners for security operations (who triages alerts and owns rules) and for infrastructure (who owns hosts, certificates and storage). Decide the support model now: a retainer, an internal team, or a vendor subscription. Each choice changes who answers the phone at 2 a.m.
A written scope signed before work starts is the basis for everything above. Access rules must be agreed up front: who from the partner gets which account, how credentials are issued and revoked, and where session records are kept. Agree how alert data is handled during testing, including whether production events may be copied to staging and how long any copy is retained. Ask your partner to confirm these terms in the statement of work.
Frequently asked questions
How much effort does a Wazuh 4.14 upgrade take and what drives it?
Effort depends mostly on what you run and how it is connected. The main drivers are the number of components to upgrade (indexer, server, dashboard and agents), whether the server runs as a cluster, how many endpoints need agent updates, and how much custom decoder and rule content must be retested. Air-gapped networks and change-control windows add steps. Ask for an effort estimate in the written scope, which should list each component, each test case and each change window.
Can our team upgrade Wazuh without outside help?
Yes, a capable team can. Wazuh is open source with no license fee, so the main cost is staff time and test capacity. Teams working alone usually need a staging copy of the stack, a tested rollback plan and someone who reads every release note before changing production. Outside help is most useful when the fleet is large, the rule set is heavily customized, or the upgrade must fit a tight change window in an isolated network. Teams that have not run a full cross-component upgrade before should weigh that experience heavily.
How long does a Wazuh upgrade take from start to finish?
Calendar time depends on fleet size, environment and the scope agreed in writing, so there is no fixed duration to quote here. A typical sequence covers scoping, a staging upgrade, rule retesting, the production upgrade in the agreed component order, the agent rollout and a monitoring period. Plan for repeat cycles as well: Wazuh shipped six 4.14 patch releases between 17 March and 14 October 2026, roughly one every one to two months.
Do custom Wazuh rules survive an upgrade?
They may carry over, but each custom rule and decoder must be retested after every upgrade before your team trusts it. Read the upgrade notes for the target version first, since changes to decoders, default fields or rule logic can alter how custom content behaves. Replay representative logs through the staging server, confirm alert levels, and check dashboards and any integrations that consume alerts. Keep custom files in version control so you can compare changes and roll back quickly.
Can a partner support an air-gapped Wazuh installation?
Yes. DeployOpen works inside the client's own infrastructure, including air-gapped networks. Wazuh documents an offline installation guide for systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository in place of the Cyber Threat Intelligence platform. Confirm the exact offline steps for your target 4.14 version, how packages and vulnerability data will be moved into the network, and how agents will receive updates without internet access before work is scoped.
How does a Wazuh support retainer differ from a one-off upgrade?
A one-off upgrade is a fixed-scope engagement with deliverables and a timeline agreed in writing before work starts, and it ends at handover. A retainer covers ongoing support, upgrades and testing over a period set by the agreement, which suits teams that must review each patch release as it arrives. Ask what the retainer includes for patch review, staging tests, rule retesting and response to issues, and how changes outside that scope are quoted.
How DeployOpen delivers Wazuh upgrades and support
DeployOpen plans and carries out Wazuh upgrades inside your own infrastructure, then supports the platform after go-live under a written scope. The work is fixed-scope for the upgrade itself, with ongoing support available as a retainer.
How we scope
- The written scope lists which Wazuh components move: indexer, server, dashboard and the agents in each group.
- Current version, target 4.14 patch release and agent population are recorded before any change is planned.
- Custom decoders, rules, integrations and SSO settings are inventoried so their upgrade risk is visible up front.
How we build
- The upgrade order is set in a runbook covering indexer, server, dashboard and agent sequencing with rollback points.
- Custom rules and decoders are re-tested against sample events on the target release before production changes.
- Upgrades run in a staging copy of your deployment first, using your own configuration and alert volumes where possible.
How we hand over
- You receive the runbook, the test results for custom rules, and a record of the versions running at each component.
- Operating notes explain how to check component versions and agent status after each patch release.
- Your team confirms acceptance in writing before the engagement closes and support begins.
How we support
- Ongoing support covers patch review against the 4.14 release notes and planning for upgrades when they are needed.
- Retainer terms set response expectations, which you should confirm in the written agreement before signing.
- Periodic checks re-run custom rule tests so that changes in the platform do not silently break detections.
