A ransomware affiliate gets a foothold on a mid-size company’s network on a Friday night. By Monday, the incident response team needs answers from 400 endpoints: which machines talked to the command-and-control server, what persistence mechanisms got dropped, and whether the attacker touched the file server. Pulling that picture together with ad hoc scripts and local forensic tools takes days. With a fleet-wide query platform already deployed, it takes hours. That gap is why Velociraptor, the open-source digital forensics and incident response (DFIR) tool built by Velocidex and now backed by Rapid7, has become a staple in SOC and IR toolkits heading into late 2026.
This tutorial walks through a full Velociraptor deployment: downloading and verifying the binary, generating a server configuration, installing the server on Linux, enrolling Windows, Linux, and macOS clients, running your first hunt with VQL, building a custom artifact, and hardening the deployment so it doesn’t become the next thing an auditor flags. By the end you’ll have a working single-node Velociraptor server monitoring at least one endpoint, plus a repeatable triage hunt you can reuse during a real incident.
What Velociraptor Is and Why DFIR Teams Are Adopting It
Velociraptor is an open-source endpoint monitoring, forensic collection, and threat-hunting platform. It runs a lightweight agent on each endpoint and a central server that issues queries, collects evidence, and stores results. The project is maintained by Velocidex, the company Rapid7 acquired in 2021, and the source remains publicly available on GitHub. Unlike a traditional EDR agent that mostly streams telemetry for a vendor’s detection engine, Velociraptor hands the investigator a query language and lets them ask arbitrary questions of the fleet in near real time.
The engine behind that flexibility is VQL, the Velociraptor Query Language. VQL looks like SQL on the surface but drives collection, filtering, and enrichment across plugins that read processes, services, registry keys, event logs, network connections, and the filesystem. Reusable VQL packages, called artifacts, are distributed as YAML files so a team can standardize an investigation step once and run it against ten endpoints or ten thousand without rewriting anything. A hunt then takes an artifact and fans it out across a chosen subset of the client fleet, which is the mechanism investigators use to scope an incident quickly.
The current stable release as of this writing is Velociraptor 0.77.2, published on August 10, 2026. That release exists specifically to close 14 vulnerabilities: CVE-2026-18348, CVE-2026-17535 (multiple crashes in the NTFS parser with invalid volumes), CVE-2026-18635 (the query() plugin allows cross-organization impersonation), and CVE-2026-18860 (incorrect organization deletion permissions). If you’re running anything older than 0.77.2, upgrading is not optional — it’s the first pitfall covered later in this guide.
How the Velociraptor Architecture Fits Together
Before touching a terminal, it helps to understand the four pieces you’re about to assemble. The server is a single Go binary that runs the frontend (the endpoint clients connect to), the GUI and API (what analysts use), and the scheduler that dispatches hunts and monitoring flows. The datastore holds client metadata, collected evidence, hunt results, and artifact definitions — by default this is a filesystem-backed store, though larger deployments can point it at object storage or a dedicated database backend. The client is the same Go binary compiled for the endpoint’s OS, running as a background service that polls the frontend over an encrypted, mutually authenticated channel. And VQL plus artifacts form the logic layer: the query language and the reusable YAML packages that turn “ask a question” into “get an answer from every machine that matches.”
That four-piece model is why a single binary download in Step 1 below can build a server package, a client package, or run as a GUI — it’s the same codebase wearing different hats depending on the flags you pass it. It also explains why the configuration file generated in Step 2 is so sensitive: it’s the shared secret that lets the frontend, the GUI, and every client all agree they’re talking to the same trusted deployment. For a deeper architectural reference beyond this tutorial’s scope, Velocidex’s own official documentation site maintains the current deployment and VQL reference as the project evolves release to release.
Velociraptor vs osquery, GRR, and KAPE: Where It Actually Fits
Teams evaluating Velociraptor almost always have osquery, GRR Rapid Response, or KAPE already in the conversation. They solve overlapping but distinct problems, and most mature SOCs end up running more than one.
| Tool | Primary strength | How it differs from Velociraptor |
|---|---|---|
| Velociraptor | Interactive DFIR, VQL, artifacts, fleet-wide hunts | Broad investigation platform with a modern web console and remote evidence collection built in |
| osquery | SQL-style endpoint inventory and scheduled queries | Strong for structured state and telemetry, lighter on rich forensic acquisition and case management |
| GRR Rapid Response | Remote forensic collection, incident response | Similar DFIR mission with a different architecture; Velociraptor leans harder on VQL and artifacts |
| KAPE | Fast Windows artifact collection and processing | A point-in-time collection/processing utility, not a continuously connected agent-server platform |
In practice, these tools complement rather than replace each other. A SOC might run an EDR for continuous alerting, osquery for structured inventory queries, KAPE for a quick local Windows triage, and Velociraptor when an incident needs fleet-wide, investigator-driven collection that an EDR console wasn’t built to support. If your team already runs a SIEM like Wazuh or a network sensor stack built on Zeek, Velociraptor slots in as the endpoint-side answer when an alert needs a deeper look than log data alone can provide.
Mapping Velociraptor’s output to a shared reference framework also helps standardize how analysts document findings. Many teams tag artifact results with the relevant MITRE ATT&CK technique IDs — for example, a persistence-location artifact maps to ATT&CK’s persistence tactic, and the suspicious-process pattern used later in this guide maps roughly to defense evasion and execution techniques. That mapping isn’t something Velociraptor enforces automatically, but it’s a cheap habit to build into custom artifacts from day one, since it makes hunt results immediately legible to anyone else on the team or to an external incident responder reviewing your case notes.
Cost, Licensing, and Who Actually Maintains the Project
Velociraptor costs nothing to download, deploy, or scale — there’s no per-endpoint fee, no paywalled “enterprise” artifact pack, and no license server to phone home to. The entire codebase, including the server, client, and GUI, is published on the official GitHub releases page, where you can also audit exactly what changed between point releases before you upgrade a production deployment.
Rapid7 acquired Velocidex, the company founded by Velociraptor’s original author, in 2021. That acquisition gave Rapid7 commercial backing to fund ongoing development, but it didn’t pull the project behind a paywall — releases, source code, and the public artifact repository have all continued on the same open cadence since. If your organization needs a support contract, professional services, or integration work beyond what the open-source community provides, that’s where a commercial relationship with Rapid7 would come in; it’s not a requirement to run Velociraptor itself. Before committing to any specific license terms for a regulated environment, confirm the exact license text shipped with the release you’re deploying, since open-source license details can vary by component and by version.
Prerequisites and System Requirements
Velociraptor doesn’t publish rigid minimums for every platform, because sizing depends on client count, collection volume, and how many hunts run concurrently. The official quickstart gives one concrete anchor worth building a lab around: a small server with 8 GB of RAM is sufficient for at least 1,000 clients in a limited deployment. Use the table below as a starting point rather than a hard ceiling.
| Component | Lab / pilot (up to ~1,000 clients) | Notes |
|---|---|---|
| Server OS | Modern Debian or RPM-based Linux | The server component is officially supported only on Linux |
| Server RAM | 8 GB | Scale up with client count, concurrent hunts, and retention |
| Server CPU | 2-4 modern vCPUs | More cores help with concurrent VQL execution and compression |
| Server disk | SSD, sized for the datastore | Collected files, logs, indexes, and exports all live here |
| Network | TCP 8000 reachable from clients by default | Change the frontend port and lock it down with TLS and firewall rules in production |
| Client OS | Windows, Linux, macOS | Native packages ship for all three |
| Client privileges | Administrator/root for most artifacts | Many forensic sources require elevated access |
You’ll also need: a Linux host (bare metal or VM) for the server, outbound internet access on that host to reach GitHub during setup, an isolated lab network if you’re testing rather than deploying to production, and at least one Windows, Linux, or macOS machine to act as a test client. A synchronized system clock across server and clients matters more than it sounds — Velociraptor’s authentication relies on it, and a client with drifted time will fail to enroll in ways that look like a network problem.
Step 1-4: Download, Configure, Package, and Install the Server
Step 1: Download and verify the Velociraptor binary
Grab the Linux binary that matches your server’s architecture from the official GitHub releases page, not a third-party mirror. For a 64-bit x86 host running version 0.77.2:
wget -O velociraptor
https://github.com/Velocidex/velociraptor/releases/download/v0.77.2/velociraptor-v0.77.2-linux-amd64
chmod +x velociraptor
sudo install -m 0755 velociraptor /usr/local/bin/velociraptor
velociraptor versionCheck the published SHA256 checksum on the release page against your download before you install anything. A substituted binary on an endpoint-monitoring tool with root/admin-level collection capability is exactly the kind of supply-chain risk a DFIR deployment can’t afford to skip-check.
Step 2: Generate the server configuration
Run the interactive configuration generator and answer its prompts for datastore location, frontend hostname, and GUI bind address:
velociraptor config generate -iThis writes a server configuration file containing the frontend settings, datastore paths, GUI administrator account, and the cryptographic material clients will use to authenticate. Treat this file as a secret on the level of a private key — anyone who has it can mint a valid client identity. For a repeatable production rollout, keep a reviewed configuration template in version control rather than re-answering the interactive prompts by hand every time.
Step 3: Build the Linux server package
Use the binary you just downloaded to build an installable server package from the configuration file:
# Debian/Ubuntu
./velociraptor debian server --config ./server.config.yaml
# RHEL/CentOS/Fedora family — use the corresponding RPM server package command
# supported by your downloaded release binaryStep 4: Install the server and start the service
sudo dpkg -i velociraptor_server_0.77.2_amd64.deb
sudo systemctl enable --now velociraptor_server
sudo systemctl status velociraptor_server
sudo ss -lntp | grep 8000Expected output from the status check looks roughly like this:
● velociraptor_server.service - Velociraptor linux amd64
Loaded: loaded (/lib/systemd/system/velociraptor_server.service; enabled)
Active: active (running) since Sun 2026-10-04 09:12:41 UTC; 6s ago
Main PID: 18422 (velociraptor)
Tasks: 14
Memory: 312.4M
CPU: 1.802sIf the unit name generated by your package differs, confirm it before chasing a phantom problem:
systemctl list-unit-files | grep -i velociraptorStep 5-7: Secure the Admin GUI, Build Client Packages, and Harden the Frontend
Step 5: Log in to the admin GUI
Open the GUI address you configured in Step 2 and sign in with the administrator account created during config generation. Do not expose this interface directly to the public internet. At minimum, put it behind a VPN or a private management network, enforce TLS, and restrict source IPs with a firewall rule — the GUI has fleet-wide collection authority, which makes it a high-value target if it’s reachable from anywhere.
Step 6: Generate client installation packages
The server configuration you generated also contains client-side connection details. Use it to build installers for each target platform. For Linux endpoints:
# Debian/Ubuntu clients
sudo dpkg -i velociraptor_client_amd64.deb
# RHEL/CentOS/Fedora family clients
sudo rpm -Uvh velociraptor-client-0.77.2.x86_64.rpmFor Windows and macOS fleets, the admin GUI’s deployment screen lets you download pre-built installer packages generated from the same client configuration, which you then push out through your existing endpoint management tooling (Group Policy, Intune, Jamf, or whatever your org already uses). Don’t hand-carry a client config file to each machine manually once you’re past a handful of test endpoints — that doesn’t scale and it’s a good way to end up with silently stale configurations.
Step 7: Harden the frontend before you enroll real endpoints
Before pointing production machines at this server, lock down three things: restrict the frontend port to known client network ranges, confirm the GUI is not bound to a public interface, and set a patching cadence so you’re not three CVEs behind the day you need the tool most. Velocidex ships point releases specifically to close vulnerabilities — 0.77.2 is itself a security release — so “set it up once and forget it” is the wrong mental model for a tool with this much access to your fleet.
Step 8-10: Enroll Endpoints, Verify Connectivity, and Run Your First Query
Step 8: Enroll a test endpoint
After installing the client package, start the client service and watch for it to appear in the GUI’s client list:
sudo systemctl enable --now velociraptor_client
sudo systemctl status velociraptor_clientThe client initiates an outbound, authenticated connection to the frontend; there’s no separate manual “registration” step. The server recognizes the client by its cryptographic identity and lists it under Clients in the GUI, usually within a few seconds of the service starting on a healthy network path.
Step 9: Verify connectivity from the server side
From the GUI, search for the new client by hostname. A healthy enrollment shows a recent “last seen” timestamp and a green/active status indicator. If the client doesn’t show up within a minute or two, check that the frontend port is reachable from the endpoint’s network segment and that the client’s system clock isn’t drifted — both are far more common causes than anything exotic.
Step 10: Run your first VQL query
Open the Notebook or query console against your test client and run a basic process listing query:
SELECT Pid, Name, CommandLine, Username
FROM pslist()
WHERE Name =~ "svchost|powershell|bash"
ORDER BY PidExpected output is a results table with columns for process ID, name, full command line, and the executing user — confirmation that the client is live and responding to queries, not just appearing online in the GUI. This is the moment that tells you the deployment actually works end to end, not just that a service started.
Step 11-13: Build a Hunt, Write a Custom Artifact, and Set Up Monitoring
Step 11: Launch your first fleet-wide hunt
A hunt runs a chosen artifact against every client that matches a label or selection criteria, instead of one endpoint at a time. From the GUI, create a new hunt, pick a built-in artifact (a process listing or persistence-mechanism artifact is a reasonable first choice), select the target client group, and launch it. Hunts are how a two-person IR team scopes “is this everywhere, or just on the one box we already know about” across hundreds of endpoints without writing a single new script.
Keep hunts scoped deliberately. Broad recursive filesystem searches or full memory captures across a large fleet can generate meaningful load on both endpoints and the server’s datastore — design the hunt’s time window and target labels before you click launch, not after the server starts choking on collection traffic.
Step 12: Write a custom artifact
Built-in artifacts cover common cases, but the real payoff of Velociraptor comes from codifying your own investigation steps as reusable YAML. A minimal custom artifact looks like this:
name: Custom.Triage.SuspiciousProcesses
description: |
Flags running processes launched from temp directories or
with unusually long command lines, a common ransomware
staging pattern.
type: CLIENT
sources:
- query: |
SELECT Pid, Name, CommandLine, Exe
FROM pslist()
WHERE Exe =~ "(?i)temp"
OR len(CommandLine) > 400Upload this through the Artifacts section of the GUI, and it becomes available to run against a single client or as a hunt across the fleet, exactly like any built-in artifact. This is the habit that separates teams that get real leverage out of Velociraptor from teams that use it as a glorified remote shell: every recurring triage question your analysts ask by hand should eventually become an artifact.
Step 13: Set up continuous monitoring
Beyond one-off hunts, Velociraptor supports monitoring flows that run selected artifacts on a schedule or continuously, streaming results back as events happen rather than only when an analyst asks. Configure a monitoring artifact for something like new process creation or scheduled-task changes on a critical server group, and you get a standing tripwire instead of a point-in-time snapshot. This is also the point where it’s worth exporting results into a SIEM you already operate, so hunt and monitoring output doesn’t live in a silo separate from the rest of your detection data.
Complete Working Project: An Automated Ransomware Triage Hunt
Putting the pieces together, here’s a minimal but functional project: a triage package you can fire at an entire client group the moment a ransomware alert comes in, combining process inspection, persistence checks, and recent file-modification scanning in one hunt.
name: Custom.IR.RansomwareTriage
description: |
First-response triage artifact: suspicious processes,
common persistence locations, and recently modified
files matching known ransomware note patterns.
type: CLIENT
parameters:
- name: LookbackHours
default: "24"
sources:
- name: SuspiciousProcesses
query: |
SELECT Pid, Name, CommandLine, Exe
FROM pslist()
WHERE Exe =~ "(?i)temp|appdata\\local"
OR len(CommandLine) > 400
- name: RecentRansomNotes
query: |
LET cutoff cutoff
AND Name =~ "(?i)readme|decrypt|recover|how_to"Upload the artifact, launch it as a hunt against your “critical-servers” and “workstations” client labels, and let results stream in over the next few minutes. In a real incident, this single hunt answers two of the first questions every IR lead asks: is anything actively suspicious still running, and how far did file encryption or ransom notes already spread. Save the hunt configuration so the next incident starts from “launch” instead of “write a query under pressure.”
Walking Through a Real Incident Response Scenario
To see why the setup above matters in practice, walk through how a small IR team would actually use it. An EDR alert fires at 2 a.m. flagging unusual outbound traffic from a finance department workstation. The on-call analyst doesn’t have hands-on access to that machine, and by the time anyone physically reaches it, whatever was running may already be gone. Instead, they open the Velociraptor GUI, confirm the client is online, and run the Custom.Triage.SuspiciousProcesses artifact from Step 12 against that single endpoint. Within seconds, they have a live process list filtered down to exactly the kind of temp-directory execution and oversized command lines that ransomware droppers and post-exploitation frameworks tend to produce.
If that first query turns up something concrete — a process running from %AppData%LocalTemp with a base64-heavy command line, say — the analyst doesn’t have to guess how far it spread. They tag the affected machine’s department as a client label, pull in every other host with the same label, and launch the Custom.IR.RansomwareTriage hunt from the complete working project above across that group. Ten minutes later, instead of a single data point, they have a table showing exactly which machines in that department show the same suspicious process pattern and which ones have ransom-note-style files written in the last 24 hours. That’s the entire value proposition of a hunt in one sentence: it turns “check this one box” into “check every box like it,” without multiplying the analyst’s workload by the number of endpoints.
From there, the collected evidence — process trees, file paths, timestamps — feeds directly into whatever case management or ticketing system the SOC already uses, and the same hunt definition gets saved for next time. The next ransomware alert doesn’t start from a blank query editor; it starts from a button labeled “relaunch.” That reusability, more than any single feature, is what makes the up-front setup cost in this tutorial worth it.
5 Common Pitfalls When Deploying Velociraptor
- Running an outdated release. Anything before 0.77.2 ships with at least four known, fixed CVEs, including two permission-handling bugs in multi-org deployments. Pin your upgrade cadence to Velocidex’s release notes, not to “whenever someone remembers.”
- Exposing the admin GUI to the open internet. The console has fleet-wide collection authority. Treat it like a domain controller, not like a dashboard.
- Treating the server configuration file as disposable. It contains the cryptographic material that authenticates every client. Leaking it is equivalent to leaking a master credential for the whole deployment.
- Launching unscoped hunts on a large fleet. A recursive filesystem search or full memory capture across thousands of endpoints without a tight time window or label filter can overwhelm both endpoints and the server datastore at the worst possible moment — during an active incident.
- Skipping clock synchronization. Client authentication depends on time sync. A drifted clock produces enrollment failures that look like network or firewall issues, sending troubleshooting down the wrong path entirely.
Troubleshooting Guide
| Symptom | Likely cause | Fix |
|---|---|---|
| Client never appears in the GUI | Frontend port blocked or wrong address in client config | Confirm TCP 8000 (or your configured port) is reachable from the client’s subnet; recheck the frontend hostname in the config used to build the client package |
| Client appears, then drops offline repeatedly | Clock drift between client and server | Sync both to an NTP source and confirm with timedatectl or date |
dpkg -i fails with a dependency error |
Missing base packages on a minimal Linux install | Run sudo apt-get -f install to pull missing dependencies, then retry the package install |
| GUI login page won’t load | Service didn’t bind, or a firewall rule blocks the GUI port | Check systemctl status velociraptor_server and confirm the GUI bind address/port with ss -lntp |
| Hunt stays “stuck” at 0% progress | No clients currently match the selected label or OS filter | Verify your label assignments in the Clients view before relaunching the hunt |
| VQL query returns a syntax error | Unescaped backslashes or regex metacharacters in a WHERE clause |
Double-escape backslashes in Windows paths and test regex fragments in isolation first |
| Server CPU spikes during a hunt | Hunt scope too broad (full filesystem glob or memory capture at scale) | Narrow the hunt to specific directories, labels, or a smaller client batch and stagger reruns |
| Upgrade breaks existing client connections | Server and client running mismatched protocol-relevant versions | Upgrade server first, then roll client upgrades out in waves and monitor the Clients view for drops |
| Artifact upload is rejected | Malformed YAML indentation or a duplicate artifact name | Validate YAML syntax locally before upload and confirm the artifact name isn’t already in use |
Advanced Tips: Scaling, Offline Collection, and SIEM Integration
Once the basic deployment is stable, a few patterns separate a lab setup from a production-grade one. First, for environments where the server can’t reach every endpoint directly — air-gapped segments, field laptops, or acquisitions still being integrated — Velociraptor supports building standalone offline collector binaries that run a fixed set of artifacts and write results to local disk or removable media for later ingestion. This matters for exactly the kind of network an IR team gets handed mid-incident: segmented, partially instrumented, and not yet trusted enough to open a live connection to your main server.
Second, don’t let hunt and monitoring output live only inside Velociraptor’s own datastore. Forward results into whatever SIEM or log pipeline your SOC already relies on, whether that’s Wazuh, an ELK stack, or a commercial platform, so endpoint forensic data joins network and authentication logs in the same correlation surface instead of requiring an analyst to manually cross-reference two consoles during a fast-moving incident.
Third, as client counts grow past a single-node pilot, revisit datastore sizing and consider separating the GUI/API frontend load from heavy collection and storage I/O. The 8 GB / 1,000-client baseline from the official quickstart is a starting point for evaluation, not a production capacity plan — monitor server memory and disk I/O under real hunt load before you commit to a fleet-wide rollout timeline.
Fourth, build a label strategy before you need one in an emergency. Labels (department, OS, criticality tier, business unit) are what make a hunt useful instead of an all-or-nothing blast radius decision. Tag endpoints as they enroll rather than retroactively during an incident, when you’ll have far less patience for bulk-editing a client list under pressure. A reasonable baseline label set covers OS family, physical location or network segment, and a criticality tier (domain controllers and file servers differ enough from general workstations to warrant separate hunt scoping by default).
Fifth, periodically audit your own artifact library the same way you’d audit detection rules in a SIEM. Artifacts drift — a query written against last year’s ransomware patterns may miss this year’s. Treat the artifact repository as living detection content, not a one-time setup task, and review it on roughly the same cadence you’d review Sigma rules or EDR exclusion lists.
Security Hardening Checklist
- Pin the server and client versions, and track Velocidex’s GitHub release notes for new CVEs the way you’d track any other internet-facing security tool.
- Restrict the frontend and GUI ports with host and network firewalls; never bind the admin GUI to a public interface.
- Store the server configuration file with the same access controls you’d apply to a certificate authority’s private key.
- Enforce multi-factor authentication for GUI administrator accounts where your identity provider supports it.
- Audit who has hunt-launch and artifact-upload permissions; both can execute arbitrary collection logic across your entire fleet.
- Log and review server-side access the same way you’d review access to a domain controller or SIEM admin console.
Velociraptor Abuse by Attackers: What Defenders Should Know
Being open source and widely deployed cuts both ways. Security researchers have documented cases where ransomware affiliates installed legitimate DFIR and remote-administration tools, including Velociraptor, on compromised networks to establish persistence or move data — a pattern commonly described as dual-use tool abuse or living-off-the-land-style activity. That’s not evidence the software itself is compromised; it’s the same dynamic that affects any remote-access or administration tool with enough fleet-wide reach to be useful to an attacker who already has a foothold.
Practical defenses: alert on unexpected Velociraptor installations outside your known deployment inventory, flag unauthorized client-to-server relationships pointing at infrastructure you don’t control, and bake “unexpected forensic/remote-admin tool installation” into your detection rules the same way you’d flag an unexpected RMM tool. NIST’s SP 800-61 incident handling guide frames this exact class of problem well: attacker-introduced legitimate tooling should be scoped and contained with the same rigor as custom malware, not waved off because the binary itself has a GitHub page.
If your detection engineering already leans on Sigma rules for cross-platform threat detection, write one that flags unexpected Velociraptor client installation or an unfamiliar frontend address in outbound connections — it’s a cheap, high-value rule given how often legitimate DFIR tools end up repurposed by intruders.
Integrating Velociraptor Into a Broader DFIR Stack
Velociraptor rarely runs alone in a mature SOC. A typical stack pairs it with a SIEM for correlation and long-term retention, a network monitor for traffic-side visibility, and a vulnerability or case-management layer to track what’s actually been fixed after an investigation closes. If you’re also running Security Onion for network-side detection, Velociraptor becomes the endpoint half of the same investigation: Security Onion tells you something suspicious crossed the wire, Velociraptor tells you what actually happened on the box that sent or received it.
For malware triage specifically, exporting a suspicious binary collected through a Velociraptor artifact straight into a tool like CyberChef for quick decoding and string analysis shortens the gap between “we found something” and “we know what it does” — useful when a client isn’t a full malware analysis lab and the team needs a fast first read before escalating to a dedicated reverse engineer.
Frequently Asked Questions
Is Velociraptor free to use?
Yes. Velociraptor is distributed as open-source software with its code and releases published publicly on GitHub. There’s no per-endpoint licensing fee for the core platform itself.
Who maintains Velociraptor, and is it still independent?
Velociraptor is maintained by Velocidex, the company Rapid7 acquired in 2021. The project has stayed open source since that acquisition, with development and releases continuing publicly on GitHub rather than moving behind a closed, commercial-only license.
How many endpoints can a single Velociraptor server handle?
The official quickstart guidance states that a small server with 8 GB of RAM should be sufficient for at least 1,000 clients in a limited deployment. Production capacity beyond that depends heavily on hunt frequency, collection volume, and datastore retention, so test under realistic load before committing to a fleet-wide timeline.
Does Velociraptor replace an EDR product?
No. Velociraptor is an investigator-driven collection and hunting platform, not a continuous prevention and detection product with vendor-managed alerting. Most teams run it alongside an EDR, using Velociraptor for deep, on-demand forensic collection when an EDR alert needs a closer look.
What operating systems does Velociraptor support?
Clients are available for Windows, Linux, and macOS. The server component is officially supported only on Linux.
Can Velociraptor be used without a persistent server connection?
Yes, through standalone offline collector binaries that run a fixed set of artifacts and write results to local disk for later ingestion. This is useful for air-gapped segments or endpoints you can’t safely connect to a live server mid-investigation.
Is it safe to run the admin GUI on a public IP address?
No. The admin GUI has fleet-wide collection authority. It should sit behind a VPN, private management network, or equivalent access control, with TLS enforced and source IPs restricted by firewall rule.
What’s the difference between a hunt and a monitoring flow?
A hunt runs an artifact once against a chosen set of clients to answer a point-in-time question. A monitoring flow runs selected artifacts continuously or on a schedule, streaming results as events occur, which is better suited to standing detections than one-off investigations.
How does Velociraptor compare to buying a commercial EDR with forensic add-ons?
Commercial EDR suites with forensic modules bundle collection, alerting, and support into one license, which costs real money but reduces engineering overhead. Velociraptor costs nothing to license but requires your team to own deployment, hardening, artifact maintenance, and scaling decisions directly. Organizations with an established security engineering function often get more flexibility per dollar from Velociraptor; organizations without dedicated security engineering time may find the operational overhead outweighs the license savings.
What should I check immediately after a fresh install, before trusting the deployment?
Confirm four things: the server is running the current release (0.77.2 or later at the time of writing), the admin GUI is not reachable from outside your management network, at least one test client successfully enrolls and responds to a basic VQL query, and the server configuration file is stored with restricted file permissions rather than world-readable on disk. Those four checks catch the majority of real-world misconfigurations before they become incident-day surprises.