Velociraptor vs osquery: when to choose each
Choose osquery when your team needs continuous, SQL-based inventory of what is running on endpoints and can staff a fleet manager to schedule queries, collect results and handle alerting. Choose Velociraptor when your team needs to hunt across the environment, collect files and artifacts during an incident, or deploy a collector to hosts where no agent can be installed. The decision turns on two questions: whether you need continuous inventory queries, incident response collection and hunts, or both, and whether you can run a separate management layer alongside the agent. osquery ships as an agent with SQL tables compiled in, and it has no central management server of its own. Its README lists third-party fleet managers such as Fleet, Kolide, OSCTRL and Zentral, which the project does not endorse or test. Velociraptor includes its own server, web GUI and gRPC API in one deployment.
Before you commit, confirm what each option requires from your team. With osquery, budget for selecting, hosting and operating a fleet manager, and for maintaining the scheduled query packs that feed it. With Velociraptor, the server is typically deployed on a cloud VM and is fully supported only on Linux, and its data lives in files on that server rather than in a separate database. Velociraptor's own migration guide argues that VQL artifacts can be changed in the GUI without rebuilding clients or servers, while osquery adds capability by changing compiled code. That point matters most if your detection content changes often. Velociraptor also runs osquery through its Windows.OSQuery.Generic artifact, so a Velociraptor team can reach osquery tables without operating a second agent. Confirm whether that is enough for your inventory needs before you add osquery separately.
Licensing rarely decides this comparison by itself. osquery is available under Apache-2.0 or GPL-2.0-only, at your choice, while Velociraptor is licensed under AGPL-3.0. For most internal deployments, both are workable. The AGPL-3.0 terms matter if you plan to modify Velociraptor and make it available to users over a network, or to offer it as part of a hosted service, so have legal counsel review those plans before you choose. If you expect to modify the platform heavily, confirm your obligations under the license text in the Velociraptor LICENSE file and against your own hosting model.
Which scenario favors which tool
This table maps common endpoint scenarios to the tool that fits each one better, with the condition that would reverse the choice. Read each row as a starting point, then check the conditions against your own fleet, staffing and tooling before deciding.
| Scenario | Better fit and reason | Choose the other tool when |
|---|---|---|
| Continuous inventory across a fleet | osquery, because its SQL tables are scheduled through osqueryd to monitor operating system state across many hosts | You also need a central management layer, since osquery has no built-in server and relies on a third-party fleet manager |
| Incident response on a suspected compromise | Velociraptor, because its VQL artifacts and hunts collect files and host state across endpoints during an investigation | Your responders only need ad hoc process, network or hash lookups that a few SQL queries answer |
| Offline collection from hosts that cannot take an agent | Velociraptor, because offline collectors built from the GUI can run any artifact and write results to JSONL or CSV | Hosts can accept a persistent agent and you want continuous monitoring rather than one-time collection |
| Small team with no fleet manager budget | Velociraptor, because it ships as a single Go executable with a built-in server, so no separate fleet product is needed | Your team already runs or plans to run a fleet manager for osquery, or wants SQL as the primary query interface |
| Existing SIEM that needs endpoint data | osquery, because its results are standard query output that a SIEM pipeline can ingest, and Wazuh's osquery module can forward results to its manager | Your SIEM ingests Velociraptor output or you want Velociraptor to run osquery queries through its osquery artifact, confirmed in your environment |
| Teams that prefer SQL over artifacts | osquery, because its tables are queried directly in SQL and the osqueryi shell supports ad hoc exploration | Your analysts want reusable, reviewable artifacts that can be edited in the GUI without rebuilding clients or servers |
| Large network visibility beyond queries | Velociraptor, because its documentation states osquery by itself is not sufficient to monitor a large network | Your scale is modest and a fleet manager you already operate covers the inventory requirement |
How each platform is built and what that means for operations
Both tools run queries on endpoints, but they differ in what they ship and what you must build around them. osquery gives you tables and a scheduler, while Velociraptor gives you a server, a GUI and collection workflows in one package. The cards below cover what each design asks of your team day to day.
osquery compiled-in tables and osqueryd
osquery exposes operating system state as SQL tables built into the agent, so new data sources generally mean changing the C++ code rather than adding a query file. Ad hoc questions run in the osqueryi shell, while osqueryd runs scheduled queries across hosts. Your team owns the query packs, the schedule and the review of results. Check which tables your Linux, macOS and Windows fleet needs before you commit, because adding one is a development task.
No central server in osquery
osquery has no management server of its own. Configuration distribution, result collection, alert routing and host grouping must come from a third-party fleet manager, and the osquery project lists options such as Fleet, Kolide, OSCTRL and Zentral without endorsing or testing them. Choosing one is a separate decision with its own license, hosting and upkeep. Ask each candidate how it handles agent upgrades, authentication and result storage before you select it.
Single Go binary with built-in components
Velociraptor ships as one statically compiled Go executable that can act as client, frontend, web GUI and gRPC API endpoint. Administrators work in the GUI, and automation uses the API, so the server and its interface come from the same install. Your team must still run the server, usually on a cloud VM, and manage its TLS certificates, backups and version upgrades. Plan that operating work before you assume the server is included.
File-based server storage
The Velociraptor server keeps its data in files on its filesystem, so no separate database needs to be installed, patched or backed up. The documentation says this layout is compatible with distributed file systems such as Amazon EFS. Your team should size disk for collection output, test restores of that filesystem, and decide retention for hunt results, since large collections grow quickly on one volume.
Linux-only full server support
Velociraptor clients run on the endpoints you need to monitor, but the server is only fully supported on Linux. If your operations standard is Windows Server for infrastructure, the server platform is a design decision you must make early. Confirm with DeployOpen or the project which server configurations your environment can run and which parts of the feature set depend on that choice.
Offline collectors for hosts without a client
Offline collectors are built from the GUI for hosts where the Velociraptor client cannot be installed. They have the same capabilities as a normal client, can run any artifact, and write results to JSONL or CSV. This suits incident response on isolated or unmanaged machines, but results must be copied off the host and imported. Decide who transports the output, how chain of custody is recorded, and how collectors are versioned.
Side-by-side capabilities and effort
This table sets osquery's SQL tables and scheduled queries against Velociraptor's VQL artifacts, hunts and collection features, row by row. Read each row against your own question: continuous inventory across many hosts, or collecting evidence from a suspect host. The migration guide compares query languages only, so confirm fleet scalability and management GUIs separately before deciding.
| Capability | osquery | Velociraptor |
|---|---|---|
| Query language | SQL over tables that expose operating system state | VQL, a query language used inside artifacts that are stored as YAML files |
| Extension model | Tables are hard-coded and compiled into the agent, so new capability generally means writing C++ | Artifacts can be viewed, modified and added in the GUI without rebuilding clients or servers |
| Results handling | Result rows are queued in memory | Results stream, with active query cancellation and a default 10-minute timeout |
| Hunts across a fleet | Scheduled queries run on many hosts, but fleet management comes from a third-party manager | Hunts are built into the platform and run across endpoints from the server |
| File collection | Built around SQL queries such as file hashes and file metadata, not evidence retrieval | Targeted artifact collection of files and host data for incident response |
| Offline collectors | Not a native feature of osquery | Built from the GUI for hosts where a client cannot be installed, running any artifact and writing JSONL or CSV |
| Built-in server | No central management server, so a fleet manager such as Fleet or osquery's listed alternatives is required | Includes a frontend, web GUI and gRPC API, typically deployed on a cloud VM and fully supported on Linux |
| Windows.OSQuery.Generic integration | Runs natively as its own agent and daemon (osqueryd) | Pushes the osquery binary on demand and returns output as a VQL result set that can be filtered and enriched |
| License | Apache-2.0 OR GPL-2.0-only, user's choice | AGPL-3.0, which adds network-use source obligations for modified versions |
What each license allows and what is paid for
osquery is licensed under Apache-2.0 OR GPL-2.0-only, and the license file lets you choose which of the two terms applies to your use. Apache-2.0 is a permissive license with an explicit patent grant, and GPL-2.0-only is a copyleft license, so your choice affects what you must do if you distribute modified binaries. In the supplied facts, the project does not list a paid edition of osquery itself, so the agent and its shell and daemon carry no license fee. The cost question sits elsewhere, in the fleet manager you place around it.
- Dual license choice: You may adopt the Apache-2.0 terms or the GPL-2.0-only terms, which lets legal teams pick the one their internal policy already accepts.
- No paid osquery edition: The supplied facts list no commercial tier for the agent, so budget for the agent itself is effectively zero in license terms.
- Fleet managers have their own terms: The osquery README names Fleet (open core), Kolide (commercial) and OSCTRL and Zentral (open source). Fleet's paid features and Kolide's subscription are governed by those vendors' terms, not by osquery's license.
- Project does not endorse those managers: The README states the project does not endorse or test third-party fleet managers, so the support and compatibility burden for the manager falls on you.
- Distribution changes obligations: If you ship a modified osquery build to other organizations, the GPL-2.0-only path may require source availability for that build.
Before you select a fleet manager, ask its vendor for the written license, the list of paid features, and the support terms for your version of osquery.
Velociraptor is licensed under AGPL-3.0, which is a strong copyleft license with an extra obligation for software accessed over a network. Rapid7 announced its acquisition of Velociraptor on April 21, 2021, and said it would continue to build the open-source community and remained committed to supporting it. The supplied facts describe the project as open source and do not list a Velociraptor paid edition, so any commercial support or product terms need to be confirmed directly with Rapid7 before you rely on them.
- AGPL-3.0 core terms: You may use, study, modify and redistribute Velociraptor under AGPL-3.0, provided you meet its conditions for source availability and license notices.
- Network use clause: The AGPL's network interaction clause can require you to offer the source of a modified version to users who interact with it over a network, such as your analysts using a modified web GUI.
- Rapid7 ownership: The April 21, 2021 announcement states Rapid7 acquired the project, which matters if you need a vendor relationship for support or roadmap commitments.
- Confirm commercial terms: Ask Rapid7 in writing whether it offers paid support, indemnity or enterprise features, and under which agreement.
- Security releases: Velociraptor 0.77.3 was released on October 5, 2026, and the documentation asks users to update to address multiple CVEs, so include upgrade rights in any contract.
AGPL-3.0 network-use obligations matter most when you modify Velociraptor and expose the modified server or GUI to users outside your legal entity, such as contractors or a managed service provider. Have counsel confirm how the clause applies to your internal analysts and to your planned changes.
Both platforms let you change code, but the consequences differ. With osquery, changes to the agent are usually handled as C++ work under Apache-2.0 or GPL-2.0-only, while the supplied Velociraptor migration guide notes that Velociraptor's capabilities are written as VQL artifacts users can edit in the GUI. Many customizations therefore live in artifacts rather than in patched source, which often keeps them outside the scope of source distribution duties, but counsel should still review that reasoning for your case.
- Artifacts versus source: Velociraptor artifacts are YAML files stored on the server, so a site-specific artifact is configuration you author rather than a modified binary you distribute.
- Patched binaries: A patched Velociraptor server or client is a modified program, and AGPL-3.0 requires you to consider source availability when users interact with it over a network.
- Internal versus external users: Obligations depend on whether the people using the modified system are inside your organization or outside it, so map your user groups before deployment.
- Osquery distribution: Forking osquery to add tables brings the GPL-2.0-only path into play if you distribute the result.
- Documented decision: Record which license you rely on for each component and why, so auditors and procurement see a consistent position.
Have counsel confirm the position for your specific modifications, deployment model and user population before you ship any changed component.
What drives the running cost of each
Running cost for either tool is mostly staff time, infrastructure and the upkeep of the components around the agent. osquery leaves more of that stack to you, while Velociraptor concentrates it on one server and one binary, so the cards below show where each bill comes from and what to ask for in a quote.
Infrastructure footprint
Velociraptor runs its server on a Linux virtual machine, with data kept in files on that filesystem and no separate database. osquery has no server of its own, so a fleet manager, a database and a log destination must be hosted before any results are useful. Ask a quote to list every host, storage location and backup target it assumes, and whether those are one-time build costs or recurring hosting.
SQL versus VQL skills
osquery queries are SQL against tables that ship compiled into the agent, so analysts who already write SQL can start quickly. Velociraptor uses VQL inside YAML artifacts, which your team can read and edit in the GUI but which is a language to learn. Estimate training time for the people who will write and review queries, and ask the provider whether it covers both languages in handover.
Fleet manager choice and support
osquery needs a third-party fleet manager such as Fleet, Kolide, OSCTRL or Zentral, and the osquery project does not endorse or test those products. Fleet is open core and Kolide is commercial, so license and support contracts may be a recurring line item. Ask whether the quote covers selecting, hosting and supporting that manager, and who answers when it breaks.
Patch and release cadence
Velociraptor 0.77.3 was released on October 5, 2026, and its documentation asks users to update to that release to address multiple CVEs, so an urgent patch cycle is already on record. osquery plans minor releases roughly every two months, and each release needs testing across every fleet manager you run. Ask for the upgrade and patch work to be priced as a recurring retainer or per release, with the test environment included.
Custom artifacts and tables
Velociraptor lets your team add or change artifacts in the GUI without rebuilding clients or servers, so custom collection is mostly authoring and testing time. In osquery, a capability missing from its built-in tables generally means C++ development and a new agent build, which is a one-time cost that recurs with every upgrade. Ask a quote to separate artifact authoring, custom osquery table work and the ongoing maintenance of each.
Moving from osquery to Velociraptor, or the reverse
This sequence shows how a team can move its endpoint queries, hunts and alerting from osquery and its fleet manager to Velociraptor, or back, without losing validated detection logic. It ends with a documented cutover and a retired fleet manager.
Inventory existing osquery queries and schedules
The team that runs the fleet manager exports every saved query, scheduled pack, target group and alert rule into a single register. Each entry records the SQL text, the interval, the platforms it runs on and the consumer of its output, such as a SIEM index or an on-call channel. The step is done when every scheduled query has an owner and a documented purpose, and the team can state which ones are inventory and which ones drive alerts.
Map each query to a VQL artifact
An endpoint engineer translates each entry into either a native VQL artifact or a use of Windows.OSQuery.Generic that runs the existing SQL on the endpoint. Native artifacts suit queries that Velociraptor already covers, while the osquery wrapper keeps SQL that has no equivalent yet. The output is a mapping sheet with one row per query, the chosen approach and any table or column that has no direct counterpart, which becomes the list of items to confirm with the vendor documentation.
Stand up Velociraptor on a test group
The platform team deploys the Velociraptor server, which keeps its data in files and needs no separate database, and enrolls a small test group of endpoints covering each operating system in scope. The team confirms that the server runs on a supported Linux host and that its update path follows the current release guidance, including the 0.77.3 security update noted in the documentation. The step is complete when test endpoints check in and appear in the GUI.
Run both tools in parallel
For a defined period agreed by the team, osquery and Velociraptor run the same checks against the test group while the existing alerting stays on. Results from both sides are written to a shared location so an analyst can compare them without touching production alerts. The output is a comparison log per query that records matching rows, missing rows and timing differences, and the step closes only when the test group has produced results from both tools.
Validate output parity and result schemas
An analyst checks that field names, data types, null handling and row counts match between the two outputs, and that Velociraptor's streaming results and default query timeout do not truncate large reads. Where osquery output is wrapped by Windows.OSQuery.Generic, the team confirms it is filtered and enriched correctly. Any difference that changes an alert condition is logged and resolved before cutover. The step is done when every alerting query has a signed-off parity record.
Move hunts, collections and alert routing
The team rebuilds hunts and targeted collections as Velociraptor artifacts, then connects detection content to the existing SIEM or notification path, including any Sigma rules that the team wants to apply to event sources. Offline collectors are built for hosts that cannot run the client. The output is a tested alert path that fires on the same conditions as before, documented in the change record, and approved by the owner of the detection content.
Cut over and retire the fleet manager
Once parity is signed off, the team switches alert ownership to Velociraptor, keeps osquery on the endpoints only where a rule still depends on it, and then removes the third-party fleet manager and its database after a documented rollback window. Access to the old console is revoked and the removal is recorded. The step is complete when no alert depends on the retired manager, and the change record shows who approved the cutover.
Where implementation projects usually run long
Implementation effort for osquery concentrates in the fleet manager, because osquery itself has no central management server. Selecting one of the third-party options named in the osquery README (Fleet, Kolide, OSCTRL or Zentral) is the first decision that shapes everything after it, and the project does not endorse or test any of them. The team then has to package and deploy the osqueryd agent, write and tune query packs against real endpoint load, and wire scheduled results into a SIEM or data store. Each step needs endpoint inventory, a change window for agent rollout and sign-off from the people who own the endpoints. Confirm with each fleet manager vendor which license, support model and hosting footprint apply before you start the selection.
For Velociraptor, the server is the main build task. Plan to size and harden a single Linux server (the deployment documentation says Linux is the fully supported server platform), decide where the file-based data lives and how it is backed up, since there is no separate database to dump, and confirm that the chosen storage works with your backup tooling. Custom artifacts are the second long item: VQL artifacts are YAML files that can be changed in the GUI, which speeds iteration but needs a review path so that changes are tested before they reach production hunts. Hunt governance, meaning who may launch a hunt, against which label groups and with what result limits, should be written down before the first hunt runs. The usual places where projects overrun are fleet manager selection for osquery, data volume once results flow into a SIEM or store, custom artifact development and change control across both tools. Client inputs that decide the schedule include administrative access to the server and endpoints, written approvals for agent deployment and collection scope, and an endpoint inventory with operating system and location data. Ask any implementation partner to name these inputs in the written scope, with the approval owner for each, so that delays are visible before work starts.
Questions buyers ask before choosing an endpoint query tool
Can osquery handle incident response collection, or only inventory?
Partly. osquery answers SQL questions about live host state, such as running processes, loaded kernel modules, open network connections and file hashes, so it can support triage when you already know what to look for. It has no central server of its own, so collection across a fleet depends on a third-party fleet manager. The osquery README lists options such as Fleet, Kolide, OSCTRL and Zentral, and notes that the project does not endorse or test them. Velociraptor's migration guide also states that osquery's tables are hard-coded, so adding new collection logic generally means writing C++. For targeted artifact collection, file collection and hunts across many endpoints, Velociraptor is designed for that job. Confirm with your incident response lead which evidence types, retention periods and chain-of-custody steps your playbooks require, because neither tool replaces a documented forensic procedure.
Can Velociraptor run osquery queries through its own console?
Yes. The Windows.OSQuery.Generic artifact runs osquery on an endpoint, and Velociraptor pushes the osquery binary on demand, so osquery does not need to be installed in advance. The osquery output returns as a standard VQL result set that you can filter, enrich and combine with other artifacts. This matters if your team already writes osquery SQL and wants those results in the same console as hunts and file collection. Check that the artifact covers the operating systems in your estate, since the osquery README lists Linux, macOS and Windows, and confirm which artifacts your Velociraptor version ships. Velociraptor 0.77.3 was released on October 5, 2026, and its documentation asks users to update to that release to address multiple CVEs, so confirm your deployed version before you plan the rollout.
How much operating effort does each tool need after installation?
Effort depends on what you run around the agent, so compare the full stack rather than the agent alone. osquery runs as a daemon with scheduled queries, and continuous inventory across a fleet also needs a fleet manager, configuration management and an owner for the data destination. Velociraptor ships as a single statically compiled Go executable and its server stores data in files, so it needs no separate database. The server is typically deployed on a cloud VM and is only fully supported on Linux, and offline collectors cover hosts where the client cannot be installed. Neither set of sources publishes an effort figure for your environment. Ask any vendor or partner for a written breakdown covering installation, server sizing, artifact or query development, upgrades and out-of-hours response for each option.
What does an endpoint query tool deployment need from our team?
Three roles usually need named owners, whichever tool you choose:
- An endpoint owner who agrees the deployment method, change windows and which hosts receive the agent.
- A detection or incident response lead who writes and maintains queries or VQL artifacts and decides what triggers a hunt.
- A platform owner who runs the server, backs up its data, and applies releases on a schedule.
The skills differ. osquery work centers on SQL and fleet management, while Velociraptor work centers on VQL, YAML artifacts and endpoint forensics. Velociraptor artifacts are YAML files that users can view and change in the GUI without rebuilding clients or servers, which lowers the barrier for analysts who are new to the tool. Confirm which of these skills and roles you already have before you pick a tool.
Can an outside partner deliver an osquery or Velociraptor project alone?
A partner can plan, implement, customize, integrate, harden, document and support self-hosted open-source platforms inside your own infrastructure. DeployOpen works this way, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Some work still sits with your side: access to endpoints and cloud accounts, decisions about the evidence your incident response process needs, and ownership of the running system after handover. DeployOpen does not publish a price list, so a quote follows from the written scope. Before you sign, ask any partner which tasks sit outside its scope and who keeps your incident response procedures current.
Does the AGPL-3.0 license affect internal use of Velociraptor?
For internal use only, AGPL-3.0 generally creates no source-sharing duty, because you run the software inside your organization and do not distribute it. The network clause needs a close read. If you modify Velociraptor and let users outside your organization interact with the modified version over a network, you may have to offer those users the corresponding source. Distributing a modified client to customers or third parties is a separate trigger. Read the LICENSE file in the Velocidex/velociraptor repository as the primary text, and have counsel confirm how it applies to your plan, especially if you bundle custom artifacts into a product. osquery is licensed as Apache-2.0 OR GPL-2.0-only, and you may choose whichever license fits your policy.
Can our own team run Velociraptor or osquery without outside help?
Yes, if you have people who can run the stack and time to learn it. Both tools are open source and documented, so an internal team can deploy osquery with a fleet manager, or deploy the Velociraptor server, build artifacts and run an offline collector against a test host. The harder work is ongoing: keeping releases current, which matters now that Velociraptor 0.77.3 addresses multiple CVEs, tuning queries to control noise, and running hunts during a live incident. Start with one pilot segment, write down the decisions each tool must support, and measure the first deployment so you can estimate your own effort before you commit. A partner becomes useful when you need fixed-scope delivery or coverage outside your team's hours.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Velociraptor vs osquery, we start by working out whether your team needs continuous inventory queries, incident response collection, or both, and then build only the pieces that answer that question.
How we scope
- We agree the scope in writing before work starts, covering which endpoints, operating systems and query or collection use cases are included.
- The written scope names whether osquery needs a third-party fleet manager or whether Velociraptor's server and hunts will be the central tool.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and pricing follows from that scope rather than a published list.
How we build
- We deploy the chosen tool in your environment, including the Velociraptor server or the osquery and fleet manager stack, using your identity and network controls.
- We write or adapt Velociraptor artifacts or osquery query packs for your use cases, and test them against representative hosts before rollout.
- We confirm the AGPL-3.0 or Apache-2.0 or GPL-2.0 license obligations that apply to your planned use and document them for your legal team.
How we hand over
- You receive documentation of the deployed architecture, the artifacts or query packs, and the operating runbooks your administrators will use.
- We run a handover session so your security and platform staff can run hunts, collections or scheduled queries without us.
- Compliance evidence, such as configuration records and test results, is organized for your assessors, who issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so updates such as Velociraptor security releases can be applied on a schedule.
- Retainers can cover adding new artifacts or query packs as your inventory or incident response needs change over time.
- Ask us to confirm the support scope, upgrade responsibilities and change process in writing before you choose a retainer.
