Introduction to Fleet
Relevant source files
The following files were used as context for generating this wiki page:
Fleet is a single endpoint management platform designed for macOS, iOS, Android, Windows, Linux, ChromeOS, and cloud infrastructure. It provides infrastructure-as-code capabilities to device management, allowing IT and security teams to manage thousands of endpoints with precision through version-controlled YAML files and a specialized CLI tool.
The platform is built on top of osquery, an open-source security agent, and enables real-time visibility, automated patching, and policy enforcement across diverse operating systems. Fleet is utilized by over 1,300 organizations to maintain compliance, reduce costs, and streamline endpoint operations via both a web UI and programmatic interfaces.
Sources: handbook/marketing/README.md:25-30, cmd/fleetctl/fleetctl/templates/new/README.md:73-77, articles/understanding-the-intricacies-of-fleet-policies.md:8-12
Core Architecture and Components
Fleet employs a client-server architecture where a centralized Fleet server manages distributed agents (hosts) running osquery. The system relies on a backend stack comprising MySQL for persistent data storage and Redis for high-performance tasks like live queries.
System Components
| Component | Description |
|---|---|
| Fleet Server | The central management hub that serves the web UI and REST API. |
| osquery / Orbit | The agent running on endpoints; Orbit is a wrapper that manages osquery and provides auto-updates. |
| MySQL | Stores host records, policy definitions, query results, and configuration. |
| Redis | Used for real-time live report functionality and task queuing. |
| fleetctl | A CLI tool for interacting with the API and managing configuration as code. |
Sources: articles/understanding-the-intricacies-of-fleet-policies.md:27-31, articles/deploy-fleet-on-ubuntu-with-elastic.md:162-170, frontend/README.md:104-105
Deployment Logic
Fleet can be deployed in diverse environments, including on-premise, air-gapped, or major cloud providers. A typical production deployment utilizes a load balancer to distribute traffic across multiple Fleet server instances, all communicating with the shared MySQL database.
The diagram above shows the relationship between administrative users, the load-balanced server cluster, the backend data stores, and the distributed hosts.
Sources: articles/understanding-the-intricacies-of-fleet-policies.md:29-31, articles/deploy-fleet-on-ubuntu-with-elastic.md:14-19
Interface and Interaction Modes
Fleet offers multiple ways to interact with the system, catering to different operational styles:
Web UI (Frontend)
The Fleet frontend is a Single Page Application (SPA) built using React with TypeScript and Hooks. It allows administrators to visualize host status, create policies, and run queries graphically.
Sources: [frontend/README.md:3-5]
GitOps and CLI (fleetctl)
Fleet emphasizes a GitOps workflow where endpoint settings are defined in YAML files. The fleetctl tool is used to apply these configurations to the server. This enables teams to review changes via Pull Requests and maintain a history of all modifications.
Sources: cmd/fleetctl/fleetctl/templates/new/README.md:5-10
REST API
The server exposes a comprehensive REST API that facilitates integration with other tools and programmatic management of the fleet.
Sources: website/config/routes.js:1062-1100
Policy Management and Execution
Policies in Fleet are SQL queries that return a boolean (true/false) result to verify security standards.
Policy Execution Flow
- Creation: Policies are defined via UI,
fleetctl, or API and stored in the MySQLpoliciestable. - Distribution: Hosts check in every 10 seconds via the
/api/v1/osquery/distributed/readendpoint. - Execution: The host executes the SQL query.
- Result Reporting: The host writes results back to the server, which updates the
policy_membershiptable. - Aggregation: A background worker process aggregates counts once per hour into
policy_statsfor optimized UI performance.
This sequence diagram illustrates the polling mechanism used by hosts to retrieve and report policy status.
Sources: articles/understanding-the-intricacies-of-fleet-policies.md:25-54
Frontend Project Structure
The frontend application follows a modular directory structure to manage React components and state:
| Directory | Purpose |
|---|---|
components/ | Global React components rendered by pages. |
context/ | React Context API for global state like currentUser. |
pages/ | Components rendered by the router at specific URLs. |
services/ | CRUD functions that interface directly with the Fleet API. |
utilities/ | Reusable helper functions (e.g., CSV conversion, debouncing). |
Sources: frontend/README.md:38-76
Summary
Introduction to Fleet establishes the platform as a bridge between traditional device management and modern infrastructure-as-code practices. By leveraging osquery and a robust backend architecture, Fleet provides a scalable, transparent, and developer-friendly environment for securing diverse endpoint populations. Its multi-modal interface (Web UI, CLI, and API) ensures that both manual and automated workflows are supported natively within the system.
Sources: README.md, articles/gitops-mode-software.md:3-7