wazuh-dashboard-plugins is the UI layer of the Wazuh platform

A plugin set that only makes sense next to a Wazuh server

This repository contains a set of plugins for the Wazuh dashboard. That sentence is the whole scope, and it is worth being blunt about the consequence: nothing here works on its own.

Wazuh itself is described as a security detection, visibility and compliance project that gives deeper visibility into infrastructure by monitoring hosts at the operating system and application level. The dashboard is a separate project, and this repository supplies the plugins that plug into it. The relationship matters for anyone evaluating this code, because the install path is not a pip install or an npm install in this repository. The README points to an installation guide hosted in the Wazuh documentation site, and to the dashboard project itself.

The subject matter is what the plugins surface. The README shows the interface covering security events, integrity monitoring, vulnerability detection, regulatory compliance, an agents overview and an agent summary, each with a screenshot. Read together with the repository topics, that is a compliance and detection console: file integrity management, policy monitoring, vulnerability detection, log analysis, intrusion detection and incident response all appear as tagged concerns rather than as features you switch on.

The primary language is TypeScript, and the package manifest confirms the frontend nature of the project.

Repository layout: plugins/, scripts/, tools/ and a plugin directory per area

The top-level entries describe the structure better than the README does. There is a `plugins/` directory, which is where the plugin packages themselves live, alongside `scripts/`, `tools/`, `docs/`, `docker/`, `screenshots/` and a `CHANGELOG.md`, `CONTRIBUTING.md`, `STYLEGUIDE.md`, `SECURITY.md` and `RELEASING.md`.

Two directories deserve a second look. `tools/` is separate from `scripts/`, which usually means repository tooling (linters, generators, release helpers) is kept apart from build and CI scripts. `docker/` at the top level suggests the plugins are exercised against a containerised stack, which is a normal arrangement for a dashboard project that has to talk to a running server during development.

The repository is also a monorepo root in the tooling sense. It carries a `yarn.lock`, a `.nvmrc` pinning the Node version, a `tsconfig.json`, an `eslint.config.mjs` for flat-config ESLint, a `.prettierrc` with a matching `.prettierignore`, and a `.husky/` directory for Git hooks. The `plugins/` directory plus the single root manifest is the shape of a Yarn workspaces monorepo, which means each plugin is versioned and built inside one repository rather than across many.

There is also a `VERSION.json` at the root and a `CHANGELOG.md`, so the release version of the plugin set is recorded in the tree rather than only in Git tags.

The root manifest is tooling, not the plugin manifest

The `package.json` at the root is worth reading in full, because it is short and it tells you something about how the project is managed. It is marked private, so it is never published to a registry, and it declares only two scripts:

{
  "name": "wazuh-dashboard-plugins",
  "private": true,
  "scripts": {
    "prepare": "husky",
    "lint-staged": "lint-staged"
  },

The `prepare` script installs husky, so the Git hooks are set up automatically after an install. The `lint-staged` script runs Prettier in check mode over staged files:

  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,scss,json,md,yml,yaml}": [
      "prettier --check --ignore-unknown --config .prettierrc"
    ]
  }
}

Read that file list carefully if you plan to contribute. Markdown, YAML and JSON are formatted by the same Prettier run as the TypeScript and CSS, and the check is a check rather than a write, so a commit fails if your formatting is off rather than being fixed for you. The dev dependencies are correspondingly minimal: husky, lint-staged and Prettier, all pinned with caret ranges.

Note what is absent. There is no build script, no test script and no lint script in the root manifest. The actual build and test commands live in the Makefile and in the individual plugin packages under `plugins/`, which is why the root manifest reads as a housekeeping file rather than as the project's entry point.

Version numbers are generated, not hand-edited

The Makefile in the repository is small, and its one target explains how release versioning works. The target is called `prebuild`, it announces that it is updating the project's versions, and it calls a Node script:

prebuild:
	@echo "- Updating project's versions ..."
	@node scripts/generate-build-version

The comment above the target says to update the tag.py file before running the script, which tells you the version number is produced rather than typed. Combined with the `VERSION.json` file at the root and the `RELEASING.md` document, the picture is that release tags are generated automatically from a version source, and a maintainer updates the version input in one place rather than editing a version field in several plugin packages.

That matters for anyone building a fork or vendoring these plugins. If you change plugin sources and rebuild, the version stamping runs in `prebuild`, and `git describe` style information is not what drives it. The `scripts/` directory named in the Makefile is the place to look for how the version is derived.

The GitHub Actions workflow named in the README badge for documentation points to a `6_documentation_deploy-to-gh-pages.yml` workflow, which deploys the documentation to GitHub Pages, and the numbering in that filename suggests a larger numbered workflow set covering the rest of the build and release steps.

Licence, release cadence and the branch question

The project is licensed under the GNU General Public License v2.0, and the README reproduces the standard notice that you can redistribute and modify the program under the terms of the licence, either version 2 of the License or, at your option, any later version. Copyright is held by Wazuh, Inc.

GPL-2.0 is a real constraint for anyone thinking about shipping these plugins inside a proprietary product, and it is worth noting that the licence text grants the option of using a later version of the License, which is how the wording puts it. Read the LICENSE file for the terms themselves rather than relying on the summary in the README.

On cadence, the releases show a clear pattern of a stable line and a next major line running in parallel. The listed releases are v4.14.9 on 2026-10-14, v5.0.0-rc1 on 2026-10-05, and v4.14.8, tagged as Wazuh v4.14.8 Revision 02, on 2026-09-24. The repository is not archived and the last push was on 2026-10-20.

The consequence for users is that a release candidate for a new major version exists alongside a maintained 4.14 line. The README sends contributors to the branches and tags page of the project wiki, and that page is where the mapping between dashboard versions and plugin branches is defined. Picking the wrong branch is the most likely way to end up with a plugin that does not match your dashboard.

What a custom plugin actually costs you

Because the upstream repository is mostly plumbing, the practical question for a team that wants a custom view is how much of the surrounding discipline they inherit. The answer is visible in the file list: a STYLEGUIDE.md, a CONTRIBUTING.md, a SECURITY.md, a RELEASING.md, ESLint flat config, Prettier, husky hooks and lint-staged.

The screenshots in the repository show seven views: the general app screen, security events, integrity monitoring, vulnerability detection, regulatory compliance, agents overview and agent summary. If your requirement is a bespoke compliance report, the question is whether it belongs inside the dashboard at all, because a plugin has to be deployed into a Wazuh installation, follows the upstream style guide, and has to survive the upstream release cycle, where versions are regenerated from a single source and branches are maintained per version line.

There is a real alternative for the reporting use case. The Wazuh server indexes its own data in OpenSearch Dashboards, and the OpenSearch Dashboards platform itself supports its own plugin model. A team that needs a report or a visualisation, rather than a view that belongs inside the Wazuh console, can work in that layer instead of extending this plugin set, and avoid inheriting the version-locked deployment and release conventions here.

For a team that does want a native Wazuh dashboard view, the difference is that this route keeps your work inside the same console as the alerts, with the same visual language, at the cost of tying your code to the dashboard's plugin API and its release branches.

Editorial conclusion

Adopt wazuh-dashboard-plugins if you are running the Wazuh dashboard and need the standard views for security events, file integrity monitoring, vulnerability detection, regulatory compliance and agent management, or if you want to contribute an upstream plugin. Do not adopt it as a standalone monitoring product, since the plugins are useless without a Wazuh deployment behind them, and do not expect a self-contained setup guide here, because the installation guide lives in the Wazuh documentation site rather than in this repository. Before you build a custom plugin, check the branches and tags wiki page for the branch matching your dashboard version, and read STYLEGUIDE.md and CONTRIBUTING.md, since the pull request path runs through those rules.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. wazuh/wazuh-dashboard-plugins on GitHub