Wazuh Docker vs Kubernetes vs packages: Which to run

Which Wazuh install method fits your team

If your team must pick one documented Wazuh install path, the deciding question is who will run the platform underneath it. Linux packages, installed with the installation assistant or the step-by-step guide, suit a team that manages hosts directly and wants the fewest moving parts. The official Docker single-node or multi-node stacks suit a team that already operates a container host and wants a pinned, repeatable stack. The Kubernetes manifests from the Wazuh Kubernetes repository suit a team that already runs and patches a cluster and can carry persistent storage for the indexer. Both container paths assume you operate that container host or cluster, including its patching, backups and host settings, so the Wazuh install is only one part of the work.

The Docker single-node stack runs one indexer, one manager and one dashboard container, and the documented host baseline is 4 CPU cores, 8 GB RAM and 50 GB of disk. The multi-node stack adds three indexer containers, a master and a worker manager, and an Nginx proxy that load balances agent traffic, with a documented baseline of 4 CPU cores, 16 GB RAM and 100 GB. Both require vm.max_map_count set to 262144 on the Docker host, a setting your platform team must own. Confirm the sizing against your expected agent count and retention before you commit, because the documented baselines are starting points, not capacity plans. The Wazuh 4.14 line is the current 4.x release line, with 4.14.9 released on October 14, 2026. A Wazuh 5.0.0 release candidate was published on GitHub on October 5, 2026, so treat it as pre-release for planning purposes and confirm its status and install documentation before any production decision. Kubernetes deploys the manager master and workers and the indexer as StatefulSets, and the dashboard as a Deployment, and it requires a running cluster with persistent volumes. On Amazon EKS for Kubernetes 1.23 and later, you also need an Amazon EBS CSI driver IAM role. Ask who will own cluster upgrades, etcd backups and Secrets handling before you choose this path, since Kubernetes stores Secrets unencrypted in etcd by default unless you configure encryption at rest.

Packages, Docker and Kubernetes side by side

This table compares the three documented ways to install Wazuh on what each deploys, the host or cluster it needs, how offline installs and upgrades work, and the platform skills each path assumes. Read each row as a question to answer for your own environment, since the Docker figures are the documented minimums and not a sizing recommendation.

Dimension	Linux packages	Docker stacks	Kubernetes manifests
What it deploys	Indexer, server, dashboard and agents installed as Linux packages, all-in-one or with components on separate hosts	Single-node: one indexer, one manager and one dashboard container. Multi-node: three indexer containers, a master and a worker manager, one dashboard and an Nginx proxy balancing agent traffic	Manager master and workers plus indexer as StatefulSets, dashboard as a Deployment; agent enrollment on the master service and agent events on workers
Documented host or cluster requirement	Per-component sizing in the installation guide; confirm the exact figures for your target endpoint count with Wazuh before you size hosts	Single-node: 4 CPU cores, 8 GB RAM, 50 GB disk. Multi-node: 4 CPU cores, 16 GB RAM, 100 GB disk. Set vm.max_map_count to 262144 on the Docker host	A running Kubernetes cluster is required; on Amazon EKS 1.23 and later, an Amazon EBS CSI driver IAM role is needed for persistent volumes
Component layout and high availability	Components can be split across hosts; the server can run as a cluster for horizontal scaling	Multi-node adds indexer and manager redundancy in containers on one Docker host unless you distribute them yourself; confirm host-level redundancy with your own design	Scheduling, storage classes and node placement are handled by your cluster; confirm how your cluster provides failure isolation for the StatefulSets
Offline install	Documented offline installation guide: components are downloaded on a connected system and installed without internet access	Confirm with Wazuh whether the Docker images can be mirrored into an internal registry and pinned for an air-gapped host	Confirm with Wazuh how images and manifests are mirrored; the cluster itself must also be reachable from a private registry
Upgrade mechanics	Package upgrades per component; confirm the upgrade order across indexer, server and dashboard in the release notes before each patch	Image tags are pinned in the examples (v4.14.9), so an upgrade means changing tags and redeploying; confirm the data migration steps for each release	Rolling changes to StatefulSets and Deployments, bounded by your cluster's Kubernetes version support window; confirm the Wazuh manifest versions you target
Platform skills assumed	Linux administration, service management, certificates and firewall rules	Docker host administration, kernel parameter tuning, container networking and volume backups	Kubernetes operations: StatefulSets, storage, RBAC, etcd backup, cluster upgrades and Secrets handling
Who runs the platform underneath	Your operating system team, typically on VMs or bare metal you already patch	Your team runs the Docker host and its patching; the stack itself is still a single-host dependency	Your platform team runs the cluster, control plane, etcd and node pools, so the SIEM inherits their upgrade and backup cadence

What each install path actually deploys

Wazuh on Docker vs Kubernetes vs packages is mostly a question of which components you run, how many hosts they span and who keeps the platform alive afterward. The four paths below deploy overlapping parts of the same Wazuh stack, so the differences show up in node count, traffic routing and the layer you must operate underneath.

Linux packages on hosts you manage

The package path uses the installation assistant or the step-by-step guide. The assisted route fits a single all-in-one host, while the step-by-step route can place the indexer, server, dashboard and agents on separate hosts. You patch the operating system, manage the host firewall and handle backups yourself. Ask which hosts your team will own after go-live, and confirm the offline steps if the network is air-gapped.

Docker single-node stack

The official single-node stack runs one indexer container, one manager container and one dashboard container. It suits a lab, a pilot or a small estate where one failed host is acceptable. The Docker host needs vm.max_map_count set to 262144, and the documented requirements are 4 CPU cores, 8 GB RAM and 50 GB of disk. Containers do not remove the need for a backup plan for the indexer data volume.

Docker multi-node stack

The multi-node stack runs three indexer containers, a master and a worker manager, one dashboard and an Nginx proxy that load balances agent traffic across the managers. It adds redundancy at each tier but still runs on Docker hosts you operate. Its documented baseline is 4 CPU cores, 16 GB RAM and 100 GB of disk. Confirm how your team will handle a Docker host failure and certificate rotation before choosing it.

Kubernetes manifests from the repository

The Kubernetes path deploys the manager master and workers and the indexer as StatefulSets, and the dashboard as a Deployment. Agents enroll through authd on port 1515, the Wazuh API listens on 55000 at the master service, and workers receive agent events on 1514. It requires a running cluster, and on Amazon EKS 1.23 and later, an EBS CSI driver IAM role for persistent volumes. Your platform team then owns the cluster, etcd and storage as well as Wazuh.

How the Docker stacks trade simplicity for host control

The Docker stacks are the fastest documented route to a running Wazuh deployment, but every container shares one Docker host, and that host becomes the single point of failure for the whole platform. The single-node stack runs one indexer, one manager and one dashboard container, and the Wazuh Docker deployment docs list 4 CPU cores, 8 GB RAM and 50 GB of disk for it. The multi-node stack, at 4 CPU cores, 16 GB RAM and 100 GB, spreads the indexer across three containers and adds a master and worker manager behind an Nginx proxy, but those containers still run on the same host unless you deliberately place them on separate machines. Ask your team whether a host outage would take down the indexer, manager and dashboard together, and whether that outage window is acceptable for your monitoring obligations.

Before the first docker compose up, check that the Docker host has vm.max_map_count set to 262144, because the indexer will not start correctly without it. The documented examples pin images to v4.14.9, which keeps the server, indexer and dashboard on matching versions. Treat that tag as a starting point, not a standing decision: confirm the current patch release in the Wazuh release notes before you deploy, and record the tag in your change management system so that upgrades are deliberate rather than accidental when someone pulls a newer image.

The Docker path is documented, not managed. Wazuh publishes the compose files and the instructions, but your team owns the host operating system patching, the Docker engine version, the storage volumes that hold indexed alerts and agent state, and the TLS certificates that secure agent enrollment and dashboard access. Backups of those volumes, certificate renewal and host hardening are your responsibility from day one. If your organization does not have an operator who can carry those tasks on a fixed schedule, a Docker single host is harder to justify than it appears in a quick start guide, and you should weigh the Kubernetes or package routes against that operating load before committing.

Which method fits which team

This path suits a SOC or IT group that manages Linux servers directly and has no container staff. Wazuh documents both an assisted installation and a step-by-step installation for each central component, and the step-by-step path supports an all-in-one host or components spread across separate hosts. The team installs the indexer, server, and dashboard on machines it already patches and monitors, using the same change process it uses for other services.

Familiar operations: Upgrades and rollbacks follow standard OS package and service practices, so existing runbooks usually apply.
Separate hosts when needed: Splitting the indexer, server, and dashboard across hosts is documented, but it means more machines to patch and back up.
Offline option: The offline installation guide covers hosts without internet access, which matters for segmented networks.
Less platform to learn: No container runtime or cluster layer sits between the team and the components.

Before choosing, confirm the host sizing for your endpoint count with the Wazuh documentation, and confirm who owns OS patching and certificate handling on each host.

This path suits a team that already runs Docker in production and wants a repeatable, containerized Wazuh deployment without operating an orchestrator. The official single-node stack runs one indexer, one manager, and one dashboard container. The multi-node stack adds three indexer containers, a master and a worker manager, one dashboard, and an Nginx proxy that load balances agent traffic across the managers. The team pins image versions and manages the Docker hosts themselves.

Single-node sizing: The Wazuh Docker deployment docs list 4 CPU cores, 8 GB RAM, and 50 GB of disk for the single-node stack.
Multi-node sizing: The same docs list 4 CPU cores, 16 GB RAM, and 100 GB for the multi-node stack, which is per host in your layout, so confirm how you map containers to hosts.
Host tuning: The Docker host needs vm.max_map_count set to 262144, a setting teams often miss until the indexer fails to start.
Version pinning: The examples pin images to v4.14.9, so upgrades become explicit image changes you must schedule.

Confirm that your Docker hosts are covered by your patching and backup process, and check the current Wazuh Docker deployment page before you pin any version.

Upgrades, backups and skills for each path

This table compares upgrade work, backup ownership, monitoring and skills across the package, Docker and Kubernetes paths for Wazuh. Read it as a responsibility map: the platform vendor documents the software, while your team owns the host, volumes or cluster underneath it.

Area	Packages (assisted or step-by-step)	Docker single-node or multi-node	Kubernetes manifests
Patch cadence to plan for	Wazuh shipped six 4.14 patch releases in 2026 (17 March to 14 October), so plan regular maintenance windows for the components you run	Same 4.14 cadence applies, and the Docker examples pin images to v4.14.9, so you must update the image tags yourself	Same 4.14 cadence applies, and manifest versions must be moved forward deliberately with the rest of the cluster
Host or platform upgrades	Your team upgrades the operating system and runs the package upgrades on each host	Your team upgrades the Docker host and its kernel settings, including vm.max_map_count of 262144	Your team upgrades Kubernetes itself, one minor version at a time under the version skew policy, before nodes
Backup responsibility	Your team backs up indexer data, server configuration and the dashboard configuration on each host, confirm the exact file list with Wazuh	Your team backs up Docker volumes holding indexer, manager and dashboard data, and the compose and certificate files	Your team backs up etcd (snapshots with etcdctl snapshot save, restores with etcdutl) plus the persistent volumes behind the indexer StatefulSets
Monitoring the stack	Standard host monitoring plus the Wazuh indexer and manager health checks, which you set up yourself	Container health, disk usage on the volumes and host memory, since the multi-node stack needs 16 GB RAM per the Docker docs	Cluster health, etcd health, PersistentVolume capacity and StatefulSet status, which requires cluster-level monitoring
Skills the team needs	Linux administration, package management and service configuration	Linux, Docker Compose, certificate handling and volume management	Kubernetes operations, etcd, RBAC, storage classes and CSI drivers, and a cluster upgrade process
Confirm before you commit	Confirm with Wazuh the supported upgrade path between 4.x minor lines and the offline upgrade steps	Confirm with Wazuh how to upgrade the official stack without losing indexer data, and whether 5.0 changes the layout	Confirm with Wazuh the supported Kubernetes versions and the upgrade order for manifests, and confirm your cluster's etcd backup schedule

Installing Wazuh without internet access

The documented offline installation guide is the path to choose when the target hosts cannot reach the internet, and it works on a simple model: components are downloaded on a connected system, then carried to and installed on a host without internet access. That sounds like a packaging step, but it sets the rest of the plan. The package-based route is the one the offline guide is written around, so a team with air-gapped hosts should confirm with the Wazuh installation guide which package set, checksums and dependency files its chosen version needs before anything crosses the network boundary. Docker and Kubernetes are different: their deployments pull images or manifests from registries and repositories, so an offline cluster needs a mirrored image set (for the indexer, server, dashboard and any Nginx proxy in the multi-node stack) and a copy of the Kubernetes manifests. The exact mirroring workflow is not something to assume, so confirm it with Wazuh's Docker and Kubernetes documentation before committing to either.

Vulnerability detection is the feature most affected by offline operation. Wazuh correlates the software inventory agents collect with vulnerability data from either the Wazuh Cyber Threat Intelligence (CTI) platform or an offline vulnerability repository. Choosing the offline repository means the team owns the feed: it must be exported on a connected system, transferred through the approved media process, imported on the Wazuh server, and refreshed on a schedule the team sets and documents. Ask the vendor how the offline repository is populated, how often it is updated, and what happens to alerts when the data is stale. Those answers determine whether vulnerability findings are trustworthy on the day they are read.

Plan the transfer and currency work as a recurring task, not a one-time install. Each Wazuh release needs its packages or images re-downloaded, hash-checked against the published values, transferred and tested in a staging enclave before production upgrades. Wazuh 4.14 patch releases arrived on six dates in 2026 (17 March, 23 April, 1 July, 29 July, 23 September and 14 October), so the update cadence is frequent enough to need a named owner and a change window. Keep the rule set, decoders and the vulnerability repository in the same transfer cycle as the software, so the server and its detection content stay in step. Confirm these steps and any support limits for disconnected installs with Wazuh before you rely on them.

Questions buyers ask before choosing an install path

What does it cost to run a Wazuh install?

The Wazuh server and agent are licensed under GPL-2.0 with an OpenSSL linking exception, and the indexer and dashboard are Apache-2.0, so no license fee applies to the open-source components themselves. The recurring costs sit in the hosts, storage, backups, staff time for upgrades and rule tuning, and any support retainer you buy. Hardware scales with endpoint count, retention and whether you run one host or several. The Docker docs list 4 CPU cores, 8 GB RAM and 50 GB of disk for the single-node stack and 4 CPU cores, 16 GB RAM and 100 GB for the multi-node stack, which are starting points, not sizing for your data. Ask any provider for a quote that separates one-time setup from recurring operations, and state the endpoint count, retention period and environment in the written scope.

How long does a Wazuh deployment take?

It depends on scope and environment, including the install path you choose, how many components sit on separate hosts, the number of agents to enroll, integrations with existing log sources, identity setup, hardening requirements and whether the network is offline. No duration can be given responsibly without that detail. Confirm the timeline in writing as part of a fixed-scope agreement, with the deliverables, the environment assumptions and the acceptance criteria listed. Ask whether the timeline covers agent rollout across your fleet or only the platform build.

Can our own team install Wazuh without outside help?

Yes, if your team already runs Linux servers and can manage certificates, storage and upgrades. The Wazuh installation guide offers an assisted path and a step-by-step path for each central component, and the step-by-step path supports both an all-in-one install and components on separate hosts. The harder part is ongoing operation: patching the four components, validating rules, tuning alerts and rolling agents forward. Be honest with yourselves about who will own those tasks after go-live, and whether they have time for them.

Do we need Kubernetes skills to run Wazuh on Docker?

No. The official Docker single-node and multi-node stacks run on a Docker host without a cluster scheduler. You do need Docker operation skills, including managing images pinned to a version such as v4.14.9, setting vm.max_map_count to 262144 on the host, handling persistent volumes and backing up the indexer data. Kubernetes becomes relevant when your platform team already operates clusters and wants Wazuh managed alongside other workloads. Note that the Kubernetes path needs a running cluster, and on Amazon EKS for Kubernetes 1.23 and later it needs an Amazon EBS CSI driver IAM role for persistent volumes.

Can we install Wazuh offline in an air-gapped network?

Wazuh documents an offline installation guide for systems without internet connectivity. The general pattern is to download the components on a connected system, transfer them into the isolated network and install them on hosts there. Vulnerability detection correlates agent software inventory with data from the Wazuh Cyber Threat Intelligence platform or an offline vulnerability repository, so an isolated network needs the offline repository instead. Confirm with Wazuh which offline steps apply to the install path you pick, and plan how you will refresh the offline content and apply patch releases.

What does the platform team own underneath Wazuh?

Whichever path you choose, someone owns the layers beneath the Wazuh components. For Linux packages, that is the host OS, disk, time sync, certificates and firewall rules. For Docker, it adds the container host, the Docker engine, image pulls and volume backups. For Kubernetes, it adds the cluster itself, which includes the control plane, etcd (where the Kubernetes documentation recommends a five-member cluster in production and a backup plan), the kubelets and the Kubernetes version upgrades. Kubernetes maintains only the three most recent minor releases, so you must plan regular cluster upgrades, and Secrets are stored unencrypted in etcd by default unless you configure encryption at rest. Get a written list of which layers the provider manages and which remain yours.

When should we move from a single-node to a multi-node Wazuh deployment?

Move to multi-node when a single host can no longer meet your availability or capacity needs, and not simply because the fleet has grown. The single-node Docker stack runs one indexer, one manager and one dashboard container, while the multi-node stack adds three indexer containers, a master and a worker manager, and an Nginx proxy that load balances agent traffic across the managers. The extra hosts add operating work, including indexer cluster health, load balancer configuration and more upgrade coordination. Assess your endpoint count, event rate, retention and required recovery targets first, and confirm the sizing with Wazuh before you commit to the topology.

How DeployOpen scopes and runs a Wazuh deployment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Wazuh. For Wazuh on Docker vs Kubernetes vs packages, we start by agreeing which installation path fits the environment, then build and document it in writing before handover.

How we scope

Written scope names the installation path chosen: packages, the Docker single-node or multi-node stack, or Kubernetes manifests.
We confirm host, CPU, memory and disk sizing against the documented requirements for the chosen path.
We agree whether offline installation is needed and which vulnerability data source the environment can reach.

How we build

We install the indexer, server, dashboard and agents on the agreed hosts, cluster or containers in your cloud account, data center or air-gapped network.
We configure the required host settings, such as vm.max_map_count for Docker hosts, and pin component versions as agreed.
We test agent enrollment, alert flow and dashboard access before the deliverables are accepted.

How we hand over

Handover documents the deployed architecture, upgrade steps and the component versions in use.
Your team receives runbooks for backups, certificate and credential changes, and agent rollout.
Where a Kubernetes path is chosen, we document the cluster prerequisites, storage classes and the platform ownership your team must keep.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover patch-release reviews across the Wazuh 4.14 line and the upgrade work that follows.
Engagements are fixed-scope, so any change in path or host count is re-scoped in writing before work starts.

Wazuh on Docker vs Kubernetes vs packages