Managed Wazuh hosting

Engineering and securityOn-prem or sovereign site

Security monitoring with an agent on every server and workstation: logs, file changes, vulnerabilities and configuration checks, analysed and kept in Switzerland, the EU or your own datacentre. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Wazuh

Licence: GPL-2.0-only and Apache-2.0
Runs on: Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: wazuh.com

Running Wazuh in production: what it takes

Size the indexer, then deploy
Server, indexer and dashboard on one pinned version, because upstream requires all three to match. The indexer is sized for your endpoint count and retention, the certificates between components are issued for your deployment, and default passwords are replaced before anyone signs in.
Roll out agents by group
Agents are enrolled into groups such as servers, workstations and domain controllers, and each group gets its configuration pushed from the server.
Tune the rules and route the alerts
The first weeks of alerts show which rules are noise. We silence what you expect, raise what matters to you, and route alerts above an agreed level to your team or your SOC provider. Triage stays with them.
Back up keys, rules and indexer snapshots
Server configuration, agent keys, local rules, certificates and indexer snapshots go offsite daily, encrypted. In the monthly drill a scratch environment is rebuilt from them, and we search the restored alerts.
Upgrade in order, in your window
Indexer, server and dashboard move together, then agents in batches, never ahead of the server. The whole sequence is rehearsed on a copy first; after your approval the Pilae Agent applies it in your window and records it in the console.

What Wazuh is, and who runs it

Self-hosted Wazuh for endpoint security and compliance

Wazuh is a SIEM with an endpoint agent. The agent runs on each server and workstation, reads system and application logs, watches the files you name for changes, inventories installed software and checks configuration against hardening benchmarks. The server decodes what arrives, matches it against rules mapped to MITRE ATT&CK and to controls in PCI DSS, GDPR, HIPAA and NIST 800-53, and raises alerts. The indexer keeps them and the dashboard shows them. It grew out of OSSEC and covers what many teams use Splunk Enterprise Security or Microsoft Sentinel for.

It suits a CISO who needs evidence from every endpoint, not only the perimeter. Security telemetry describes your whole estate, including who logged in where, so it stays in the jurisdiction you picked: your own hardware, or dedicated machines in Zurich or another Pilae Cloud region you choose.

Wazuh in production: indexer sizing, rule tuning and alert routing

Three components run centrally, and an agent runs on every endpoint. The indexer is where the cost sits and where things fail. Its disk grows with every alert, so retention is set in an index policy from day one, and on a single node the backup is the only second copy of the index. Agents report over your private network, and the components talk to each other over TLS with certificates issued for your deployment. We watch the analysis queue for dropped events, probe every component every 60 seconds and alert an engineer when one fails.

The rules we tune with you are files in your repository, and alerts go to your team, your ticket queue or your SOC provider. We run the platform and do not triage your alerts: that stays with whoever receives them. Dashboard sign-in goes through Keycloak or your own identity provider, and upgrades go through the Pilae Agent: tested on a copy, approved by you, applied in your window.

Wazuh licence and editions

There is no licence fee per agent, so what grows with your estate is the indexer’s storage, not a licence bill. Pricing for our operation is on request. Talk to us about the estate you want to watch.

Wazuh has no paid edition. The server and agent are GPL-2.0, with a permission to link against OpenSSL, and the project states that the licence also covers the rules and decoders shipped with them. The indexer and dashboard are Apache-2.0 forks of OpenSearch and OpenSearch Dashboards, and the Wazuh plugins inside the dashboard are GPL-2.0-or-later. Single sign-on, vulnerability detection and compliance reporting are all in the free software. Wazuh Inc. sells Wazuh Cloud, professional support and training; if you want a support contract with them, it is held in your name. The Wazuh name and logo remain Wazuh Inc. trademarks.

Wazuh system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 8 vCPU · 8 GB, up to 100 agentsUpstream sizing for the server, indexer and dashboard on one machine. Past that the indexer moves to its own nodes, where upstream recommends 8 cores and 16 GB each.
Indexer storage: 1.5–7.4 GB per agent, 90 daysUpstream estimates 1.5 GB for a workstation, 3.7 GB for a server and 7.4 GB for a network device over 90 days of alerts. Retention is the main cost, so it is set in a policy and not left to fill the disk.
Agents: Linux, Windows, macOSOne agent per endpoint, never newer than the server. Devices that cannot run an agent send syslog to the server instead.
Network: TCP 1514, 1515 to the serverAgents report on 1514 and enrol on 1515, over the private network. The dashboard sits behind the Pilae gate on port 443, and the indexer API is never published.
Sign-in: SAML or LDAPThe dashboard signs people in through Keycloak, Microsoft Entra ID or another SAML provider, or through LDAP and Active Directory, with no paid edition needed.

Migrating from Splunk Enterprise Security to Wazuh

Wazuh does not run SPL, and its Splunk integration only sends data one way, from Wazuh into Splunk. So the move is a rebuild of detections, not a data migration. Detections written in SPL become Wazuh rules and decoders: XML that matches each event as it arrives and correlates repeats within a time window. Most endpoint and authentication detections carry across. Searches that join several sources over days need rethinking, and we list them before you commit. Universal forwarders give way to Wazuh agents, and network devices send syslog to the Wazuh server. History stays in Splunk, read-only, until your retention obligation lapses. Tuning takes longer than rewriting.

List what Splunk actually alerts on
Detections that fired in the last ninety days, the sources behind them, who acts on them, and how long you are obliged to keep the logs. That list decides what is rewritten and what is retired.
Enrol agents beside the forwarders
Wazuh agents go on in groups, servers first, next to the Splunk universal forwarders. Network devices send a copy of their syslog to the Wazuh server, so both systems see the same events.
Rewrite the detections as rules
Each detection becomes a rule in your repository, in the ID range upstream sets aside for custom rules, and is checked against the alerts Splunk raised for the same events.
Forward, compare, then switch
Wazuh alerts are forwarded into Splunk during the parallel run, so analysts work from one screen. Once both have raised the same alerts for a full cycle, the forwarders come off and Splunk is kept read-only for history.

Tuning Wazuh rules and routing its alerts

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="acme,">
  <!-- The weekly vulnerability scan tries users that do not exist. Expected. -->
  <rule id="100100" level="0">
    <if_sid>5710</if_sid>
    <srcip>10.20.4.15</srcip>
    <description>sshd: invalid user from the acme scanner, expected</description>
  </rule>

  <!-- A login accepted from outside the admin network is worth a person. -->
  <rule id="100110" level="12">
    <if_sid>5715</if_sid>
    <srcip negate="yes">10.20.0.0/16</srcip>
    <description>sshd: login accepted from outside the acme admin network</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

<!-- /var/ossec/etc/ossec.conf (excerpt) -->
<ossec_config>
  <integration>
    <name>custom-acme-queue</name>
    <hook_url>https://tickets.acme.internal/hooks/wazuh</hook_url>
    <level>10</level>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

An example from the tuning we keep in your repository: one rule silences a scan you expect, one raises a login you do not, and alerts at level 10 or above go to the queue your team works from, through a short script of the same name in the integrations directory. Local rules use the ID range upstream sets aside for them and live outside the ruleset directory that upgrades overwrite.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Wazuh

Pricing is on request: a fixed price for onboarding, then a monthly price for Wazuh, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Wazuh: common questions

Is Wazuh open source?

Yes. The server and agent are GPL-2.0, including the rules and decoders. The indexer and dashboard are Apache-2.0 forks of OpenSearch and OpenSearch Dashboards, with the Wazuh plugins under GPL-2.0-or-later. There is no paid edition: Wazuh Inc. sells a hosted service, support and training, not features.

Does Pilae watch the alerts for us?

No. Our monitoring watches Wazuh itself, not what Wazuh finds. We keep the platform up, sized, backed up and upgraded, tune the rules with you and route alerts to the people you name. We are not a security operations centre. Triage and response stay with your team or the SOC provider you choose, who can sign in to the dashboard.

Can Wazuh replace Splunk Enterprise Security?

For endpoint detection, file integrity monitoring, vulnerability detection, configuration assessment and compliance reporting, yes. It does not run SPL. Its rules match and correlate events as they arrive, so detections that search across several sources over days need rethinking. We list those during the inventory, before any rule is rewritten.

Where do our logs and alerts live?

In the indexer, on dedicated machines that your agents reach over the private network: your own hardware, or a Pilae region you choose, in ISO 27001-certified datacentres. Vulnerability detection downloads its CVE feed from Wazuh; for an isolated site we load an offline copy of the feed instead.

What happens to the agents when Wazuh is upgraded?

They are upgraded last, in batches, and keep reporting until their turn comes. Upstream supports agents at the same version as the server or older, never newer, so the indexer, server and dashboard go first, together. The server then sends each batch of agents a signed upgrade package.

Back to apps

Bring us your Wazuh. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing