Which open-source EDR and DFIR tool fits your situation
If your security team needs endpoint visibility, threat hunting or incident response without buying a commercial EDR, the core split is this: Velociraptor for artifact-driven collection and hunting, osquery for SQL-based host queries where you will need a separate fleet manager, and Wazuh for agent-based detection that feeds a SIEM-style alert pipeline. The three differ less in what they can see than in how you ask questions, how results reach analysts and how much infrastructure you run to get there. All three named platforms have OSI-approved licenses: Velociraptor under AGPL-3.0, Wazuh server and agent under GPL-2.0 with an OpenSSL linking exception, and osquery under Apache-2.0 OR GPL-2.0-only, at your choice.
Choose Velociraptor if your main work is incident response and forensic collection across many hosts, and your analysts think in terms of named artifacts they can read, change and rerun. Its offline collectors suit hosts where an agent cannot be installed, and the velociraptor gui command gives a local triage option on one machine. Choose osquery if you mainly need ad hoc or scheduled SQL questions about host state and already have, or will select, a fleet manager such as Fleet, OSCTRL or Zentral, since osquery has no central server of its own. Choose Wazuh if you need continuous detection, alert triage and compliance dashboards in one place, with the Wazuh indexer storing alerts and the dashboard providing prebuilt compliance views. GRR Rapid Response is named in this comparison, but this page has no supplied facts on it, so confirm its current status, license and features directly before shortlisting it.
Before you decide, confirm three things in your own environment: which operating systems and hosts must be covered (Velociraptor's server is only fully supported on Linux, and osquery and Wazuh agents differ by platform), whether you can accept a separate fleet manager or a larger detection stack, and who will own rule and artifact content after launch. Ask each vendor or implementation partner for a written scope covering agent deployment, server hosting, retention of collected data and the upgrade path, since Velociraptor 0.77.3 and Wazuh 4.14.9 both carried recent maintenance releases that you will need to track.
Open-source EDR options by scenario
This table maps common endpoint scenarios to the platform that fits best and the condition that makes it fit. Read each row as a starting point, then confirm the listed point in your own environment before choosing. The main takeaway is that Velociraptor leans toward hunting and collection, Wazuh toward alerting and compliance views, and osquery toward scheduled queries that a separate fleet manager consumes.
| Scenario | Best fit | Why and what to confirm |
|---|---|---|
| Incident responders needing fast triage and collection across hosts | Velociraptor | Artifacts run targeted collection and hunts across many endpoints, and the velociraptor gui command supports local triage on one machine. Confirm your server operating system, since the server is only fully supported on Linux, and that AGPL-3.0 terms fit how you distribute tooling. |
| Scheduled host queries with an existing fleet manager | osquery | osqueryd runs scheduled SQL queries, but osquery has no central server of its own. Confirm that your fleet manager (such as Fleet, OSCTRL or Zentral, none endorsed or tested by the project) meets your support and license needs. |
| SOC needing alerts mapped to MITRE ATT&CK with agents and dashboards | Wazuh | Agents feed a server with a ruleset that ships over 3,000 built-in rules and decoders and maps alerts to MITRE ATT&CK. Confirm the rule coverage for your operating systems and that you can run the indexer, server and dashboard as a supported deployment. |
| Air-gapped or offline environment | Wazuh (offline guide) or Velociraptor (offline collectors) | Wazuh documents an offline installation guide and an offline vulnerability repository in place of its online threat intelligence feed. Velociraptor offline collectors run any artifact and write JSONL or CSV. Confirm how you will update rules, content and vulnerability data without internet access. |
| Team that also needs compliance dashboards | Wazuh | The Wazuh dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. These views show monitoring coverage, not a certification. Confirm with your assessor which evidence they accept and whether the views map to your controls. |
| Team that wants hunting across endpoints with a single open-source toolchain | Velociraptor with osquery as a data source | Velociraptor draws on osquery and GRR in its history and supports Sigma rules and event sources such as ETW and eBPF. Confirm which event sources your endpoints support and how much detection content you must write yourself. |
Velociraptor, Wazuh and osquery in brief
Velociraptor, Wazuh and osquery approach endpoint visibility from different starting points: forensic collection, full detection platform and SQL over host state. Each card names the license and main role so you can narrow the shortlist before comparing agents, query languages and central management in detail.
Velociraptor
Velociraptor is licensed under AGPL-3.0 and is Rapid7's endpoint visibility and digital forensics platform, which Rapid7 acquired in April 2021. It ships as a single statically compiled Go executable, and its server stores data in files rather than a separate database. Offline collectors can run any artifact on hosts where a client cannot be installed, which matters for incident response on isolated systems. Check the AGPL-3.0 terms against how you plan to offer the platform internally, and confirm the current release guidance, since the documentation asks users to update to 0.77.3 for CVE fixes.
Wazuh
Wazuh is a full detection platform with a GPL-2.0 server and agent under an OpenSSL linking exception. Its four components are the indexer, server, dashboard and agents, and agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX. The indexer and dashboard are Apache-2.0, so confirm the license of each component before you package or redistribute it. Choose Wazuh when you need alerting, vulnerability detection and compliance dashboards on top of agent data, and budget for running the indexer and server as their own tier.
osquery
osquery exposes the operating system as a relational database, so SQL queries can read running processes, loaded kernel modules, open network connections and file hashes. It is licensed under Apache-2.0 OR GPL-2.0-only, and you may choose either license. osquery has no central management server of its own, so fleet management depends on a third-party manager such as Fleet, Kolide, OSCTRL or Zentral, none of which the project endorses or tests. Plan for that separate component, its operation and its support before you rely on scheduled queries across many hosts.
GRR Rapid Response
GRR Rapid Response is the Google project that Velociraptor draws its inspiration from, according to the Velociraptor history page. Its license and release activity are not covered by the facts used for this comparison. Confirm both directly with the project before you shortlist it, including whether it is still maintained for your operating systems. Treat it as a reference point for the design of remote live forensics rather than a settled alternative until those checks are complete.
How the options compare on capability
This table compares Velociraptor, Wazuh and osquery on the capabilities that decide fit for endpoint hunting, collection and incident response. Read each row for the platform's core role, then use the cells marked to confirm as questions for the vendor or your own test environment. Velociraptor and osquery are strongest as collection and query tools, while Wazuh is the option that ships alerting and compliance views out of the box.
| Capability | Velociraptor | Wazuh | osquery |
|---|---|---|---|
| License | AGPL-3.0 | GPL-2.0 with OpenSSL exception for server and agent; indexer and dashboard are Apache-2.0 | Apache-2.0 OR GPL-2.0-only, chosen by the user |
| Primary role | Hunting, targeted artifact collection, client monitoring and digital forensics | SIEM and XDR-style detection with alerts mapped to MITRE ATT&CK | Endpoint state queries; detection depends on scheduled queries and a manager or Wazuh module |
| Agent model | Client on each endpoint; offline collectors for hosts where a client cannot be installed | Agents on Linux, Windows, macOS, Solaris, AIX and HP-UX; agentless syslog and API collection for devices such as firewalls | osquery daemon or interactive shell on Linux, macOS and Windows |
| Query language | VQL, usually wrapped in YAML artifacts that can be edited in the GUI | Decoders and rules; the osquery module adds osquery results to alerting | SQL against tables describing processes, kernel modules, network connections and file hashes |
| Central management | Web GUI and gRPC API on the server | Server manages agent configuration and upgrades remotely and can run as a cluster | No central server; third-party fleet managers such as Fleet, Kolide, OSCTRL or Zentral, which the project does not endorse |
| Server storage and operating system | Data kept in files on the server filesystem with no separate database; fully supported on Linux only | Wazuh indexer stores alerts; server operating system support is not covered in supplied facts, so confirm it | No server component; confirm where results are routed in your chosen fleet manager |
| Offline or air-gapped support | Offline collectors can run any artifact and write JSONL or CSV output | Offline installation guide and an offline vulnerability repository instead of the CTI platform | Not covered in supplied facts; confirm packaging and update paths for isolated networks |
| Compliance dashboards | Not covered in supplied facts; confirm whether any framework mapping is available | Prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53 | None built in; compliance views depend on the fleet manager or a SIEM |
| Third-party or bundled SIEM features | Sigma rules in client monitoring; no bundled SIEM described in supplied facts | Bundled SIEM and alerting; the indexer is an OpenSearch fork | Wazuh osquery module sends results to the manager for alerting; Security Onion runs osquery through Elastic Agent |
What each tool needs to deploy and run
Velociraptor runs as a client on each endpoint, a frontend that the clients connect to, a web GUI for administrators and a gRPC API. The server is typically deployed on a cloud virtual machine, and the documentation describes it as fully supported only on Linux. It keeps its data in files on its filesystem rather than in a separate database, and the documentation says that layout is compatible with distributed file systems such as Amazon EFS. The single Go executable keeps the moving parts few, but the file-based store means your team owns filesystem sizing, backup and retention.
- Server placement: Plan for a Linux host, usually a cloud VM, with the frontend reachable by every client.
- Storage model: No database to patch, but the file store must be backed up and sized as collections grow.
- Offline collectors: Build them from the GUI for hosts where a client cannot be installed, then collect results as JSONL or CSV.
- Local triage: The
velociraptor guicommand runs the GUI, frontend and a local client on one machine for quick investigations. - Client rollout: Your own endpoint management tooling typically pushes the client, so confirm how it fits your change process.
Confirm with the vendor and your own team which Linux distribution and server sizing you will use, how the file store is backed up and restored, and who owns certificate handling for the frontend and clients.
Wazuh is a four-part stack: the Wazuh indexer stores alerts and provides full-text search and analytics, the Wazuh server decodes and analyzes agent data with rules, the Wazuh dashboard provides the web interface, and Wazuh agents run on endpoints. The server can run as a cluster for horizontal scaling and manages agent configuration and upgrades remotely. Wazuh documents several installation paths, which lets you match the build to your platform standards, but each path still leaves you with four components to upgrade and monitor.
- Deployment paths: All-in-one and step-by-step installs, a prebuilt OVA, an Amazon Machine Image, Docker, Kubernetes, an offline guide, installation from sources, and Ansible or Puppet.
- Offline operation: The offline guide covers systems without internet access, and vulnerability detection can use an offline repository instead of the Wazuh CTI platform.
- Scaling: The server can run as a cluster, so plan indexer and server capacity separately from the agent count.
- Agentless sources: Firewalls and similar devices can feed in through syslog and periodic API probing.
- Upgrade cadence: Wazuh shipped 4.14 patch releases roughly every one to two months in 2026, so budget recurring patch windows across four components.
Confirm with the vendor and your own team which deployment path fits your platform standards, how the indexer cluster will be sized and backed up, and how upgrades will be sequenced across the indexer, server, dashboard and agents.
osquery installs as a small agent on each host. Analysts run queries ad hoc in the osqueryi interactive shell, while the osqueryd daemon runs scheduled queries to monitor operating system state across many hosts. osquery has no central management server of its own. The README lists third-party fleet managers such as Fleet, Kolide, OSCTRL and Zentral, and the project does not endorse or test them, so central control is a separate component you must select, host and maintain.
- Ad hoc use:
osqueryigives analysts a shell for one-off questions on a single machine. - Scheduled use:
osquerydruns configured queries on every host and reports results. - Fleet management: A third-party manager, such as Fleet, Kolide, OSCTRL or Zentral, provides central configuration and results handling.
- Platform coverage: Linux, macOS and Windows are supported by the project.
- Wazuh integration: The Wazuh osquery module lets Wazuh agents manage osquery configuration and send results to the Wazuh manager for alerting.
Confirm with the vendor and your own team which fleet manager you will use, who supports it, how its license and hosting fit your environment, and how query packs will be reviewed and versioned as operating systems change.
Which licenses are OSI open source and what paid tiers add
All three platforms in this comparison use licenses the Open Source Initiative approves, but the obligations they place on you differ. Velociraptor is licensed under the GNU Affero General Public License version 3 (AGPL-3.0). Its network-use clause matters most when you modify Velociraptor and let people outside your organization interact with it over a network. In that case the AGPL may require you to offer those users the modified source. If you run an unmodified server for internal responders, the exposure is smaller, but your counsel should confirm how the clause applies to your deployment, including any managed service you plan to offer clients. The Velociraptor LICENSE file is the starting point for that review.
The Wazuh components carry two licenses. The Wazuh server and agent are under the GNU General Public License version 2 with an OpenSSL exception, while the Wazuh indexer and dashboard are under Apache-2.0. This split matters for an EDR team because the agent on every endpoint and the server that processes its data fall under the copyleft license. Any change you distribute to agents, such as a custom build deployed to hosts you do not control, triggers source-availability duties under GPL-2.0. The indexer is an open source fork of OpenSearch and uses the permissive Apache-2.0 terms. osquery offers a choice of Apache-2.0 or GPL-2.0-only. Pick the terms you rely on, record them in your third-party software inventory, and expect your legal team to ask which license applies to each binary on each host.
No supplied fact describes a paid tier for Velociraptor, Wazuh or osquery, so do not assume one exists or what it includes. Ask each vendor, in writing, which commercial support, hardening, single sign-on, hosted or feature terms they sell, what those cost, and whether any of them change the license of the code you deploy. Wazuh offers a separate hosted service through Wazuh Cloud, and its terms should be read on their own before you compare it with self-hosting. Rapid7 announced its acquisition of Velociraptor on April 21, 2021, and said it would continue to support the open-source community. Commercial ownership is a reason to check maintainer commitment: review the release history, the number of active maintainers outside the vendor, the governance and contribution terms, and how quickly security fixes ship, such as the 0.77.3 update that addressed multiple CVEs.
How to choose and pilot an open-source EDR tool
This sequence turns a shortlist of Velociraptor, Wazuh, osquery and GRR into a documented decision, backed by pilot evidence on your own hosts rather than vendor claims. Each step closes with an artifact your security, compliance and platform teams can review.
Define the questions each tool must answer
The security lead and incident responders write down the concrete questions they need answered: threat hunting across the fleet, triage of a single suspicious host, an alert pipeline that feeds a SOC, and evidence for compliance reviews. Separate hunting and collection needs from alerting needs, because Velociraptor is built around hunts and artifact collection, while Wazuh centers on rules and alerts and osquery centers on SQL queries. Done means a signed list of questions, each tagged with the team that will use the answer and the evidence format an auditor would accept.
Inventory operating systems and offline hosts
The platform team lists every operating system, version and host class in scope, including servers, workstations, and any systems that cannot run a persistent agent. Wazuh agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and Velociraptor offline collectors can run any artifact on hosts where a client cannot be installed, but you must confirm coverage for your exact versions with each project. Also record networks without internet access, since Wazuh documents an offline installation path and an offline vulnerability repository. Done means a host inventory with an agent-or-collector decision for each class.
Check licenses and maintainer activity against policy
Legal and procurement review the license of each candidate against your open-source policy and your distribution plans. Velociraptor is AGPL-3.0, Wazuh server and agents are GPL-2.0 with an OpenSSL exception while its indexer and dashboard are Apache-2.0, and osquery is offered under Apache-2.0 or GPL-2.0-only at your choice. Record the release cadence each project publishes, such as the osquery goal of minor releases roughly every two months, and the recent Velociraptor and Wazuh patch releases, then ask whether your policy treats security updates as a requirement. Done means a license memo and a maintenance calendar for each tool.
Pilot with one tool from each category
The detection engineering team deploys one candidate per function on a limited group of test hosts that reflects the operating systems in the inventory: Velociraptor for hunting and collection, Wazuh for rule-based alerting, and osquery for scheduled queries. Keep the pilot scope fixed in writing with a named owner, a host count and a stop date, and avoid production endpoints until the pilot results are reviewed. Confirm with each project how it expects to be deployed on your infrastructure, since Velociraptor is typically run on a cloud VM and is only fully supported on Linux for the server. Done means a pilot runbook and a deployment record showing which hosts report to which tool.
Measure query coverage and alert quality
Incident responders run the same set of test questions and hunts against every pilot host, then record which hosts returned complete results, how long collection took, and whether results arrived in a format your SIEM or case tool can ingest, such as JSONL or CSV. The detection team seeds known benign and known malicious activity, then counts true positives, false positives and missed events for Wazuh rules and Velociraptor artifacts, including Sigma-based detections where supported. Ask each vendor or project which MITRE ATT&CK mappings they ship and which ones you must write yourself. Done means a scored coverage matrix with query gaps listed by operating system.
Decide on central management and upgrade ownership
Architecture and operations leads decide who runs the central server, who approves agent upgrades and who owns patching when security releases appear. osquery has no central server of its own and relies on a third-party fleet manager that the project does not endorse or test, while Wazuh manages agent configuration and upgrades remotely and can run as a cluster. Velociraptor stores data in files on the server filesystem, so backup and retention need a named owner. Written confirmation is needed on support paths, because DeployOpen supports these platforms through scoped engagements and retainers rather than offering a vendor-backed support contract. Done means an ownership matrix and a signed decision record naming the tool, the owner and the upgrade cadence.
Questions buyers ask before choosing open-source EDR
How much does it cost to run open-source EDR and DFIR tools?
The licenses for Velociraptor, Wazuh and osquery carry no fee, so the cost sits in labor and infrastructure. Labor covers engineers who deploy the server, package and roll out agents, write or tune artifacts and rules, triage alerts and maintain upgrades. Infrastructure covers the server hosts, storage for collected results or alerts, and network paths to endpoints. Costs that recur include staff time, hosting and upgrades, while the initial build is mostly one-time. Costs rise with endpoint count, retention period and the number of hunts you run. Ask any implementation partner for a quote built from a written scope that lists servers, endpoint counts, data retention, integrations and the staff hours behind each item.
Can our team run these tools without outside help?
It depends on in-house query and detection skills more than on the software itself. Velociraptor depends on writing and reviewing VQL within artifacts, osquery depends on SQL against operating system tables and a fleet manager, and Wazuh depends on tuning decoders and rules and on running the indexer and dashboard. Check whether your staff can write and review these queries, operate a Linux server cluster, handle agent upgrades across mixed fleets and triage alerts on a schedule. If any of those skills are missing, confirm what training or outside support you will need before you commit to a tool.
How long does a pilot take to set up?
No researched duration applies to these tools in your environment, so set the pilot length from your own written scope. Time depends on how many endpoint types you need to cover, whether agents can be pushed through your existing software distribution, how many artifacts or rules you must write, and how much of the result you must validate against known activity. Define the pilot's exit criteria before it starts, such as the hosts covered, the queries or detections proven and the handover documents, and ask any partner to tie its timeline to those criteria in the signed scope.
Which tool suits incident response and which suits continuous detection?
Velociraptor is built first for hunting and collection during an investigation, with artifacts that pull specific host state on demand and offline collectors for hosts that cannot take a client. Wazuh is built first for continuous detection, because its agents send events to a server that applies a large built-in ruleset mapped to MITRE ATT&CK and stores alerts in its indexer. osquery is a query engine that suits scheduled host checks and ad hoc questions, and it needs a third-party fleet manager for central control. Many teams run a detection platform for steady monitoring and a collection tool for investigations, so test both against a realistic incident scenario from your own environment.
Do these tools work in air-gapped networks?
Yes for some parts of the stack, but confirm the exact setup for your network. Velociraptor offline collectors, built from the GUI, have all the capabilities of a normal client and can run any artifact, writing results to JSONL or CSV for hosts where a client cannot be installed. Wazuh documents an offline installation guide for systems without internet connectivity, and its vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Ask how updates, rule packages, vulnerability data and agent packages will reach the isolated network and who approves each transfer.
What should a quote for these tools include?
A useful quote lists each deliverable against the written scope rather than a single lump sum. Ask for the platforms and versions in scope, the number and type of endpoints, the server architecture and hosting location, the data retention and storage assumptions, the artifacts, queries or rules to be built and tested, the integrations with your SIEM or ticketing system, the handover and documentation package, and the upgrade and patch support after go-live. Check license terms in writing as well. For Velociraptor, confirm that the AGPL-3.0 terms fit how you plan to use and distribute it, and ask the partner to state which release it will deploy, given the 0.77.3 update that addresses multiple CVEs.
How DeployOpen scopes and supports EDR and DFIR selection
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For EDR and DFIR tooling, that means helping your team decide which of these platforms fits its telemetry, hunting and response needs, then building it in your cloud accounts, data centers or air-gapped network.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which endpoints, operating systems and response workflows the chosen tool must cover.
- We confirm license terms, edition needs and the hosting footprint with your team before any build begins.
How we build
- Deployment runs inside your own infrastructure, including the server, frontend and storage your chosen tool requires.
- Artifacts, queries or rules are customized to your environment and tested against representative hosts in your network.
- Agent rollout, access control and single sign-on integration are configured to match your identity and change processes.
How we hand over
- Handover includes architecture notes, runbooks, configuration records and the evidence your assessors may request.
- Your staff receive working knowledge of queries, collection workflows and central management tasks for daily use.
- Upgrade, backup and restore procedures are documented so your team can operate the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers agreed separately from the initial scope.
- Security testing of the deployed platform can be scoped separately to check its configuration and exposed interfaces.
- Ask any provider, including us, to confirm vendor security advisories and patch timelines for the exact versions you run.
