wazuh-docker deploys the Wazuh security platform as a set of containers

The whole platform, not just the agent

The wazuh/wazuh-docker repository provides resources to deploy the Wazuh cybersecurity platform using Docker containers, and the description is explicit that the setup covers the full stack rather than a single component.

That full stack is the Wazuh manager, the dashboard, which is based on OpenSearch Dashboards, and OpenSearch itself for indexing and search. Those three are the parts that have to be running together, and the parts that are awkward to install by hand, because OpenSearch wants specific memory settings and a specific ulimit, and a dashboard that points at the wrong index will start and then show nothing.

The implementation language for the repository is Shell, with the deployment described as Docker and docker compose resources rather than a library of any kind. The project is maintained by the Wazuh team, with active contributions from the community, and the site is wazuh.com.

The release history shows two lines running at once. v4.14.9 came on 2026-10-14, v4.14.8 on 2026-09-24, and v5.0.0-rc1 on 2026-10-05, so a 5.0 release candidate is in preparation alongside the maintained 4.14 line.

What the deployment gives you

The capabilities section is five bullets, and each one answers a question a person setting this up will have.

Full deployment of the Wazuh stack using Docker, which is the first and covers the manager, the dashboard and the index together. docker compose support for orchestration, so the whole thing comes up with a single command and the dependencies between the three services are expressed rather than scripted. Scalable architecture with multi-node support, which is the difference between a laptop and a deployment with more than one manager. Data persistence through configurable volumes, so the data survives a container being replaced. And ready-to-use configurations for production or testing environments, which is the sentence to read carefully, because it is a claim about the starting point rather than a guarantee.

That last point is worth a paragraph. A Wazuh deployment collects logs and alerts from every host you point an agent at, and the storage that implies is not trivial, and the compose files in this repository give you a working topology rather than a sized one. The number of events an environment produces, and the retention you need, determine the disk and the memory for the index, and that is a decision the operator has to make rather than a value the repository can pick for you.

The branch convention tells you which repository to trust

The Branch Convention section is short and it is one of the more useful things in the readme for anybody who pins a deployment.

The main branch is for developing and testing of new features. The X.Y.Z branches are version specific branches, with 5.1.0 and 4.14.0 given as the examples.

So the two lines are the moving development branch and the frozen line for a particular release, and a production deployment that tracks main is tracking whatever is being built next. That is the standard arrangement for a project that ships a matrix of versions, and it exists because the compose files reference specific image tags.

The releases make the same point in practice. With v4.14.9 and v4.14.8 on the 4.x line and a v5.0.0 release candidate on the 5.x line, a deployment has a choice of a maintained stable line or a candidate of the next major version, and the branch to use for either is named in the readme.

The branch naming also tells you how the versions line up with the platform, since the 4.14 branch is the one matching the 4.14.x image tags.

The repository layout, and what the directories are for

The top level listing is short and it separates the deployment shapes from the machinery.

There is single-node/ and multi-node/, which are the two compose layouts, and wazuh-agent/ for the side that runs on the machines you monitor. Then there is build-docker-images/ for the scripts that build the images, tools/ for the helper scripts, and docs/ for the internal documentation that the readme points at as an alternative to the official site.

Two files at the root are worth calling out. There is a.env file, which in a compose based deployment is the file that holds the configuration the containers read, and there is a VERSION.json, which records which version the files in that branch are for. A VERSION file next to a compose file is a good sign, because it lets a script check what it is about to deploy against what the branch believes it is.

The rest is the standard set. There is a.github/ directory, a CHANGELOG.md, a SECURITY.md, a LICENSE file and a.gitignore.

The multi-node directory is the one to look at if you are running anything serious, because a single node deployment of a log platform is a demonstration and a multi node one is a deployment.

The containers descend from two community Dockerfiles

The Authors and Maintainers section gives the ancestry, and it is worth knowing because it explains what the images are and are not.

The Docker containers are based on the deviantony dockerfiles, which can be found in the docker-elk repository, and the xetus-oss dockerfiles, which can be found in the docker-ossec-server repository.

So the lineage is a Docker image for the Elastic stack and a Docker image for an OSSEC server, both of which are community projects, combined into the Wazuh image set. The topic tags carry that history too, with ossec and loganalyzer among them, which are the two names the platform has been known by.

The project is maintained by the Wazuh team with active contributions from the community, and the readme thanks the contributors and links the full list.

There is a licence statement that is worth reading in full rather than skimming. It says Wazuh Docker Copyright (C) 2017, Wazuh Inc., with the licence GPLv2, which is different from the repository metadata that GitHub cannot classify, and it is a reminder that a container set for a security product is a product with a licence that a commercial user should read rather than infer.

Documentation, support and how to contribute

The documentation section points at the official deployment guide for Docker, with the URL for the current version, and then at the docs folder in the repository for the internal documentation.

The internal documentation being in the repository rather than only on the website is a good arrangement for a deployment project, because the thing you need when a deployment is broken is the version of the notes that matches the branch you are on, and a website that serves the current version of everything is not that.

Support comes in two forms, and both are community rather than contractual. There is a Slack badge pointing at the Wazuh community, and an email badge pointing at a Google group forum for Wazuh. The Getting Involved section lists the four routes, which are to fork the repository and create your own branches to add features or fix bugs, to open issues to report bugs or request features, to submit pull requests following the contributing guidelines, and to participate in discussions.

The fork instruction is the notable one. It says to create your own branches in your fork, which for a deployment repository is the right model, because a site that runs a security platform usually needs local changes, and a fork lets you carry them forward across upstream releases without a long lived pull request.

Editorial conclusion

Adopt wazuh-docker when you want to try Wazuh, or run a small deployment, without assembling the container set yourself, since the compose files cover the manager, the dashboard and the index. Do not adopt it blind for a production security deployment, because a security platform that indexes logs has real storage and network requirements that the compose files only get you started on. Verify first which branch you are on, since main is for development and the X.Y.Z branches are the version specific ones, that your volumes cover the data that has to survive an upgrade, and that the dashboard and index versions in your compose file match the manager version you are running.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wazuh/wazuh-docker on GitHub