A home security operations center used to mean a lab VM running Snort and a text file of IPs. The modern open-source stack is closer to what a mid-market SOC ran five years ago: full XDR-grade telemetry, hunt-capable endpoint forensics, and visualization that doesn’t make you cry. Three projects do most of the work — Wazuh for continuous monitoring and alerting, Velociraptor for on-demand DFIR collection, and Grafana for dashboards that aggregate the rest of the lab. None of them cost anything. All of them are actively maintained: Wazuh shipped 4.14.4 on March 17, 2026 with 4.14.5 following on April 23, and Velociraptor 0.76 landed on March 10, 2026 with security backports through 0.76.3.
This guide walks the architecture, the install order that actually works, the integration points that catch people out, and the pitfalls worth knowing before you commit storage to a hot indexer cluster on your home lab box. The goal isn’t a production SOC — it’s a learning environment that produces real telemetry from your real network and teaches the workflow muscles you’d use on the job.
What Each Tool Actually Does
Treating Wazuh, Velociraptor, and Grafana as interchangeable would be a mistake. They occupy different layers and answer different questions.
Wazuh is a unified XDR/SIEM platform that runs lightweight agents on endpoints and ships log, file integrity, vulnerability, and configuration data back to a central manager. The manager parses incoming events through decoders and rules, generates alerts, and writes them to the Wazuh indexer (an OpenSearch fork). It answers “what is happening continuously across my fleet?” It’s the always-on sensor grid.
Velociraptor is a DFIR and threat-hunting tool, not a SIEM. It runs a small client on endpoints that executes VQL — the Velociraptor Query Language — to collect forensic artifacts on demand. Where Wazuh streams everything, Velociraptor surgically pulls what you ask for: $MFT records, registry hives, scheduled tasks, prefetch, raw memory ranges. Its scalable architecture makes it possible to hunt for forensic artifacts across large networks in minutes. It answers “something tripped an alert — what really happened on that box?”
Grafana doesn’t generate or store security data. It queries data sources you point it at and renders dashboards. In this stack it pulls from the Wazuh indexer (via the grafana-opensearch-datasource plugin) and any other lab telemetry you have — Prometheus metrics, OPNsense firewall logs in a separate index, etc. — to give one consolidated pane of glass that the native Wazuh dashboard alone won’t.
The three together cover the OODA loop: Wazuh observes and alerts, Grafana orients you across sources, and Velociraptor lets you decide and act on a specific host.
Sizing the Lab Before You Install Anything
The single most common home-SOC failure isn’t misconfiguration — it’s running out of disk. Wazuh’s indexer keeps every alert plus FIM and inventory deltas, and Velociraptor’s continuous client monitoring can write substantial event volume per host per day if you enable everything. For a starter lab covering 3–10 endpoints, plan a single host with at least 8 GB RAM and 100 GB of dedicated storage for the indexer; 16 GB and 250 GB is more comfortable. CPU is rarely the bottleneck; sustained write throughput on the indexer disk is.
Run Wazuh and Velociraptor on the same Linux box if resources are tight, but split them once you start hunting at scale — Velociraptor’s notebook post-processing can pin a CPU core during heavy parsing, and you don’t want that fighting the indexer. Grafana is light enough to colocate with either.
Installing Wazuh: Order Matters
Wazuh’s all-in-one installer handles indexer, manager, and dashboard in one shot, which is the right path for a home lab. Run it on Ubuntu 22.04 or 24.04 — 4.14.x agents now support Debian 13 and recent SCA policies cover Windows Server 2025 and macOS 26 Tahoe, which matters if you’re testing config baselining.
A few things that catch first-time installers:
The central components must match versions exactly. All central Wazuh components must have identical version numbers, including the patch level, for proper operation. Additionally, the Wazuh manager must always be the same version or newer than the Wazuh agents. Don’t mix 4.14.4 indexer with 4.14.5 manager. The Filebeat dependency is also pinned: Wazuh indexer 4.14.4 is specifically compatible with Filebeat-OSS 7.10.2. If you upgrade Filebeat blindly during a routine apt upgrade, the indexer pipeline silently breaks.
Wazuh 4.14 introduced architectural changes worth understanding. All Wazuh Server installations now run as a cluster node, removing the distinction between clustered and non-clustered deployments. The manager install path also moved — the Wazuh Manager installation path changed to /var/wazuh-manager (replacing /var/ossec) and agent ID 000 was removed, fully decoupling agent and manager processes on shared hosts. Old tutorials referencing /var/ossec on the manager are out of date. Several legacy daemons like ossec-authd, wazuh-agentlessd, wazuh-maild, and wazuh-dbd were removed in this release.
After install, deploy agents to your endpoints, enable FIM (file integrity monitoring) with whodata mode on Linux, turn on SCA (Security Configuration Assessment) for the OS baseline, and enable the vulnerability detector. That’s your core sensor coverage.
Adding Velociraptor for Hunt and Triage
Velociraptor’s deployment is dramatically simpler than Wazuh’s. The single static binary acts as server, client, or standalone GUI depending on flags. For the home SOC, run velociraptor --config server.config.yaml frontend on a server, generate an MSI/DEB client package from the GUI, and deploy it.
Critical: only run version 0.76.3 or later on the server side. Velociraptor versions before 0.76.3 contain a vulnerability in the query() plugin which allows access to all orgs with the user’s current ACL token, and Velociraptor versions before 0.76.3 improperly validated input in client message handler. This could lead to remote code execution on the server. The CVEs are tracked as CVE-2026-5329 and CVE-2026-6290. A home server reachable from infected endpoints is the worst place to ignore a server RCE.
Velociraptor’s value comes from VQL artifacts. Start with the built-in Windows.Sys.Users, Windows.Forensics.Prefetch, Windows.EventLogs.RDPAuth, and Generic.Detection.Yara.Process for Windows hosts. On Linux, Linux.Sys.Pslist, Linux.Forensics.Bash (history), and Linux.Detection.AnomalousFiles cover the basics. Sigma rules can run client-side, so triage doesn’t require shipping every event to the server.
The integration with Wazuh is workflow-based, not technical. A high-severity Wazuh alert on an endpoint becomes the trigger for a Velociraptor hunt scoped to that host or that asset group. Wazuh tells you something tripped; Velociraptor tells you what’s actually on the disk.
Wiring Grafana to the Wazuh Indexer
The native Wazuh dashboard is fine for triage, but it’s a single product view. Grafana lets you correlate Wazuh alerts with everything else — firewall flows, DNS queries, host CPU spikes — in one panel. The WAZUH SIEM XDR dashboard uses the grafana-opensearch-datasource data source to create a Grafana dashboard with gauge, piechart, stat, table and timeseries panels, and similar prebuilt dashboards exist on the Grafana community site.
Setup, in order:
Install Grafana on the same host or a separate VM. Install the grafana-opensearch-datasource plugin via grafana-cli plugins install grafana-opensearch-datasource. In OpenSearch (the Wazuh indexer), create a dedicated read-only role and user — never use the admin account for Grafana. Map the role to the wazuh-alerts-* and wazuh-archives-* index patterns.
In Grafana, add the datasource pointing at the indexer (typically https://<wazuh-host>:9200), supply the new credentials, and either skip TLS verification (lab only) or import the Wazuh indexer’s CA. Set the index pattern to wazuh-alerts-4.x* and the timestamp field to timestamp.
Once the datasource is healthy, import a community dashboard ID from grafana.com to bootstrap, then customize. The dashboards you’ll use most: a MITRE ATT&CK tactic distribution panel keyed off rule.mitre.tactic, an authentication failure heatmap, a vulnerability severity stat panel, and a top-talkers panel from your firewall logs alongside.
Reference: Core Configuration Surfaces
Pitfalls That Will Cost You a Weekend
The indexer eats disk faster than you expect. Default retention has no cap. Configure ISM (Index State Management) policies on the Wazuh indexer to roll over indices at 20 GB and delete after 30 days, or your home lab will fill up in a month of normal alerting.
Don’t run Velociraptor exposed to the internet. The two 2026 CVEs were both server-side. If you need remote agents from outside your LAN, put the Velociraptor frontend behind a Tailscale or WireGuard mesh, not a port forward. The whole point of a home SOC is to learn defense, not to become a CVE statistic.
Wazuh agent versions drift. The manager-newer-than-agent rule is enforced loosely; mismatched patch levels cause silent decoder failures, especially around new SCA policies. Pin agent versions in your config management and upgrade manager-first.
Grafana TLS is opt-in. The default install runs unencrypted on :3000. Generate a cert (a self-signed one is fine for the lab) and configure it in /etc/grafana/grafana.ini before you start adding panels — switching later means re-issuing all your shared dashboard links.
OpenSearch authentication for Grafana. Don’t use the indexer’s admin account. Create a dedicated grafana_ro user with read-only access scoped to wazuh-alerts-* indices. The reference architectures in community projects like MohamedNourDerbeli/SOC-SIEM get this right; some quick blog tutorials don’t.
FAQ
Do I really need Velociraptor if I have Wazuh? Yes, for hunt and deep triage. Wazuh tells you a process spawned cmd.exe from winword.exe. Velociraptor lets you pull the prefetch, the parent’s loaded modules, the registry run keys, and a memory dump of the suspicious child in one VQL artifact. Different jobs.
Can I run all three on a Raspberry Pi? No. The Wazuh indexer is the constraint — it’s a JVM-based OpenSearch fork and wants real RAM. A Pi 5 with 16 GB might handle 1–2 endpoints; for anything larger, use an old desktop or a small NUC.
Should I forward Wazuh logs to a separate Elastic or Splunk? Not for a home SOC. The Wazuh indexer is fine as primary storage. Forwarding makes sense when you want to mix Wazuh data with corporate SIEM ingestion paths you don’t own.
How do I trigger Velociraptor from a Wazuh alert automatically? Wazuh active response can call a script with alert context. That script can hit Velociraptor’s API to launch a hunt scoped to the host’s hostname or agent ID. It’s not turnkey — you’ll write the glue — but it’s the right pattern.
What This Build Actually Teaches
A home SOC isn’t a substitute for production experience, but this stack reproduces the exact tooling categories you’ll touch in a real role: SIEM rule writing, EDR/DFIR collection, dashboard engineering, alert tuning, and the awkward integration glue that nobody writes documentation for. Build it once on three endpoints, intentionally compromise one (Atomic Red Team is the cleanest way), and walk the alert from Wazuh through Grafana into Velociraptor. You’ll learn more in that one chain than from any course module on SIEM theory.
Open-source stacks aren’t shortcuts to enterprise SOC capability — they’re full-fat versions of the same primitives, with the configuration burden left in your lap. That burden is the lesson.
