Threat Intelligence

Osquery Fleet Management: Running Osquery at Scale

Running osquery on one host is a shell session. Running it on ten thousand is a distributed system. The TLS protocol, the managers, the data pipeline, and the costs that decide the outcome.

Alex Gibson, Co-Founder and Principal at Artemes AI
Alex Gibson
Co-Founder, Principal
Jul 20, 2026 10 min read
Abstract visualization of osquery agents reporting to a central fleet management server over TLS

The agent is the easy part. Osquery fleet management is hard because the work is everything around the agent, not the agent itself.

Osquery fleet management means deploying the agent to thousands of endpoints, pushing configuration to all of them, running queries across the whole population, and collecting the results somewhere you can actually use them. One host is a shell session. Ten thousand hosts is a distributed system with a database, a message queue, a certificate story, and a log pipeline. The agent barely changes. Everything upstream and downstream does.

Teams underestimate this constantly. They pilot osquery on a few laptops, see how sharp it is, and assume the fleet version is the same thing times a thousand. It is not. The pilot answers "can osquery do this." The fleet answers "can we operate this," and those are different questions with different owners.

Infographic

What a fleet deployment actually looks like

The agent is one box on the left. The reason osquery at scale is hard is everything to its right.

Osquery fleet architecture from agents to analysisA left to right pipeline. On the left, many osquery agents on endpoints. They connect over TLS to a management server, which depends on a database and a cache and issues configuration and live queries back to the agents. The server forwards results to a log pipeline, which lands them in a data store for search and analysis. A label notes that collection is the easy part and analysis is the unsolved part.osquery agentosquery agentosquery agentthousands of hostsManagement serverconfig + enrollmentlive queriesDBcacheLog pipelinequeue / forwarderData storesearch + analysisTLSCollection is the solved problem. What the rows mean is the part that still needs a human or a model.

How does osquery run at scale?

Out of the box, osquery reads its config from a local file. That does not survive contact with a fleet, because you cannot hand edit a file on ten thousand machines. The answer built into osquery is the TLS remote API. Instead of a filesystem config, the daemon points at a server:

--config_plugin=tls
--logger_plugin=tls
--tls_hostname=fleet.example.com
--enroll_secret_path=/etc/osquery/enroll.secret
--tls_server_certs=/etc/osquery/server.pem

With those flags, three things move over one authenticated channel. The daemon enrolls with a shared secret and receives a node key. It pulls its schedule and packs from the server instead of a local file. It ships results back to the same server. The osquery remote settings documentation specifies the endpoints a compatible server has to implement. This is the contract every management platform is built against.

A fourth capability rides the same channel: distributed queries. The server can hand a one off query to a selected set of hosts and read the answers back within seconds. This is the live query feature people mean when they say they "asked the fleet a question," and it is what turns an incident response question from a day of work into a coffee break. If you have not set up the daemon side yet, our osquery installation guide covers the local pieces first.

What manages an osquery fleet?

You do not want to build the TLS server yourself. Several platforms implement the contract and add enrollment, query authoring, and dashboards on top.

Fleet, the open source manager, is the common starting point. By its own 2026 reporting it manages more than two million endpoints across over 1,300 customers, and it is designed to run from a startup's first ten Macs up to enterprises with several hundred thousand mixed hosts, per Fleet's own scale writeup. Kolide, Uptycs, and the Elastic osquery integration cover similar ground with different tradeoffs and pricing. The choice matters less than understanding what all of them are doing underneath, which is speaking the same osquery TLS protocol.

A production Fleet install is not a single binary. It runs a web server, a MySQL database for state, a Redis cache for the live query queue, and a certificate setup for the TLS enrollment. That is the real shape of osquery at scale, and it is worth internalizing before you promise anyone a rollout date. You are standing up a service, not installing a tool.

Where does the data actually go?

The management server is a router, not a warehouse. Results usually land in the server briefly, then get forwarded through a queue or shipper into a data store where you can search and alert: a SIEM, a data lake, or a log platform. This is where the cost hides, and where planning documents go quiet.

Do the arithmetic before you deploy. Five thousand hosts running a modest schedule of 30 queries is 150,000 query results every interval. Differential logging keeps that from being catastrophic, because osquery emits only what changed rather than the full result set each run. But "only what changed" on a busy fleet is still a steady river, and every gigabyte has to move, land, index, and retain somewhere with a monthly bill attached. Measure the volume on your pilot group and multiply. Do not guess.

Packs are how you keep this schedule maintainable across the fleet, because they let you ship and version detection content as units rather than editing a giant flat config. We cover the mechanics in osquery query packs. The daemon behavior that makes scheduled collection safe, including the watchdog and differential logging, is in osqueryi vs osqueryd.

What does managing an osquery fleet really cost?

The software can be free. The operation is not, and three costs decide whether a deployment thrives or rots.

Infrastructure is the visible one. The server, the database, the cache, the pipeline, and the storage are real systems that need patching, monitoring, and capacity planning. This is normal platform work, and it needs a normal platform owner.

Configuration drift is the sneaky one. A fleet is never uniform. Some hosts run old agents, some miss the enrollment, some sit behind a proxy that breaks TLS. Keeping the actual deployed state matching the intended state is ongoing, and a manager that reports 92 percent coverage is telling you 8 percent of your fleet is dark. Newer approaches treat the fleet config as code and reconcile it the way infrastructure teams reconcile servers, which is a real step forward for keeping that number honest.

Analysis is the one that sinks programs. A fleet generating millions of rows produces evidence, not answers. Someone, or something, still has to read the output and decide what matters. If your plan for the log stream is "an analyst will watch it," price that analyst's time against the volume and see if the plan survives contact with the number. This is the same wall teams hit with telemetry generally, which we get into in machine learning in endpoint telemetry.

A practical rollout path

Fleets fail when teams try to go from zero to everything. A sequence that works:

  • Stand up the manager and enroll one team's machines. Prove the TLS channel and enrollment end to end.
  • Ship a tiny schedule, five queries, and confirm the data lands where you expect and costs what you modeled.
  • Add packs one at a time, each with a discovery query, each slow rolled with the shard selector.
  • Wire the output into your data store and write the first alert before you add the next pack.
  • Only then expand host coverage. Broad and shallow beats narrow and deep for catching operational problems early.

Notice the order. Coverage comes last, not first. A fleet that collects everything and analyzes nothing is a cost center wearing a security badge.

This is also where the honest limit of osquery shows up. It collects beautifully and interprets nothing. Once the fleet is streaming, the unsolved problem is judgment: which of these findings is real on this host right now. That is the gap Artemes AI is built for, pairing deep endpoint context with AI driven analysis that reads system state to decide which findings actually matter rather than forwarding everything a query can list. Collection was never the hard part. Deciding was.

Frequently asked questions

Does osquery include a fleet manager?

No. Osquery ships the agent and a TLS remote protocol for talking to a server, but not the server itself. A separate platform such as Fleet, Kolide, Uptycs, or the Elastic integration implements that protocol and adds enrollment, scheduling, and dashboards.

How many endpoints can osquery scale to?

The agent is lightweight enough to run on hundreds of thousands of hosts. Fleet reports managing over two million endpoints across its customers. The practical ceiling is set by your management server, pipeline, and storage, not by the agent.

How do osquery agents authenticate to the server?

Agents enroll using a shared enroll secret over TLS and receive a per node key used for subsequent requests. The server validates the TLS certificate chain, and most deployments rotate enroll secrets and pin server certificates.

What is a distributed or live query?

A distributed query is an ad hoc query the server pushes to selected hosts for an immediate answer, rather than a scheduled query that runs on an interval. It is the mechanism behind fleet wide live questions during an investigation.

The takeaway

Before you commit to an osquery fleet, size the three things that actually decide the outcome: the infrastructure you will run, the data volume you will store, and the analysis you will do with what comes back. Stand up a manager, enroll one team, ship five queries, and watch the pipeline for a week. The agent will do its job. Whether the deployment earns its keep depends entirely on the part that is not the agent.

Artemes AI

See which of your findings actually matter

Artemes AI combines deep endpoint context with AI-driven analysis to show which findings are actually exploitable on your hosts—not just everything a scanner can list. We are onboarding early access teams now.

Alex Gibson, Co-Founder and Principal at Artemes AI

Alex Gibson

Co-Founder, Principal

Alex writes about configuration drift, operational security evidence, endpoint telemetry, AI-assisted triage, and the practical work of turning signals into better remediation decisions.

Osquery
Endpoint Telemetry
Security Automation
Found this useful? Share it.