The playground
playground.fleet.wazuh.com is the Fleet console with its data layer replaced by fixtures. It is public, it signs nobody in, and it holds no connection to any Wazuh deployment. It exists so the whole product can be walked through before anything is installed on a machine.
It is not a separate application. The playground and
fleet.wazuh.com are the same source tree, built twice.
The playground build sets NEXT_PUBLIC_WAZUH_MOCK=1 and is given no Fleet API
URL at all, so the screens that would read the Fleet control plane read a session
fixture instead. The Overview, the Hosts table, a host's own page and the
services on it are the same code that runs against a real backend, on invented
data.
The browser tab says Wazuh Fleet Playground where the real console says Wazuh Fleet, so a tab strip with both open is readable. The last tile on the ecosystem rail is the crossing between them: Leave the playground here, Open the playground on the real console.
What is real
- The whole product, on sample data. Fleet's own screens: the Overview with its tiles and status chart, the Hosts table, a host's detail page with its connector and services, and Team. Nothing is stubbed out or hidden behind a demo flag.
- The controls, not only the views. Nothing above the data layer reads the mock flag, so a control that shapes a view behaves here as it does against a real deployment. One caveat, about which fields the filter builder can offer, is under Limits below.
- The derivations. The two status vocabularies, the status chart's grouping, the Overview's tiles, the de-duplication of detected environments against what is already in Fleet, and the Hosts table all run through the same pure modules the real console uses. A hand-written second copy for the demo is exactly what these pages avoid.
What is not real
The data. Every number is generated, and it is deterministic per host id: the generators are seeded from the id, so each host always renders the same connector version, heartbeat and services, and the totals on the Overview follow from them.
The starting fixture is a small fleet of machines with the names such a fleet has, managers, an indexer, dashboards and a couple of laptops, plus the hosts Wazuh Cloud runs for two connected environments. Between them they cover the states that are easy to get wrong: one offline, one that enrolled and has never beaten, and services that are running, degraded, unreadable or crash-looping. Only services whose plugin actually exists are named.
The sample Wazuh Cloud account holds more environments than are connected, so the rest are offered as Detected in Wazuh Cloud, one of them terminated with a card that says why it can never be connected.
What you can change
Adds and removes are not decorative. A control that reports success and changes nothing is the defect this site would demonstrate best, so the playground keeps a session registry of its own.
| Action | What happens in the playground |
|---|---|
| Add a host | The row appears immediately as Not connected, and a one-line installer is shown. The token in it is invented and enrolls nothing. See Add your first host |
| Remove a host | The row goes. Removing a connected Wazuh Cloud one puts it back under Detected, because the detected list is the sample account minus whatever is in the registry. See Remove a host |
| Invite, change a role, change grants | The Team table updates. A duplicate email is refused with the same message the real API's refusal produces, and so is removing the last admin |
| Allow or disallow a service, pin an update | The Services and update panels move, and each says on screen that its state is a sample |
| Connect a detected Wazuh Cloud environment | The card moves to Hosts in Fleet as Connecting and reads Connected a few seconds later, standing in for the connector Wazuh Cloud would deploy. Nothing is asked of anyone. See Wazuh Cloud environments |
Limits worth knowing before you judge it
The session registry is in memory and per tab. Hosts, team changes, service asks and update settings survive navigation, and they do not survive a reload. Every visitor starts from the same fixture list. That is deliberate: the playground has no backend, and a demo that pretended to be a control plane would be making a claim it cannot keep.
The "Open Wazuh XDR UI" links do not resolve. The detected environments are invented, so their dashboard hostnames are invented too and resolve to nothing. The link is built by the same derivation the real console uses rather than special-cased for the demo, which keeps that one piece of logic identical in both builds and costs a dead link here. The detected section says so on screen.
The credentials on a Wazuh Cloud environment's detail page are a sample. The
username is wazuh and the password begins sample-only-, derived from the id
so it is the same on every render. A warning above them says they are sample
values and that no Wazuh Cloud account was asked anything. The alternative,
refusing to show the panel at all, made the screen say Fleet could not fetch
credentials, which is a false claim about the real console.
Everything on the playground that looks like a secret is generated in the browser: the sample credentials from the id, the enrollment token in the installer line at random. There is no account behind either, nothing to sign in to, and no host they correspond to.
Nothing reaches a machine. The playground carries no API URL, and the deploy step refuses to publish a bundle whose exported page is not the playground one or whose bundle names the Fleet API host. There is no relay, no gateway and no connector in the path, so none of the data reads on these screens leave the browser. Links out of the console are still ordinary links: clicking through to the Wazuh Cloud console or to Wazuh documentation opens those sites normally.
When you are done touring
The real console needs a Wazuh ID, and that is all. Signing in with one sets your workspace up. If your organization already has a Fleet workspace you join that one rather than starting a second, as a member unless an invitation gave you more, and what you can open there is what an administrator has granted you; otherwise the workspace is new and you administer it. Start at Sign in, then add your first host and install the connector on the machine. For what the product does and does not do once it is talking to a real fleet, read What is Fleet and What Fleet can do.