System Architecture Overview
Relevant source files
The following files were used as context for generating this wiki page:
Fleet is an open-core device management platform designed to manage and monitor Apple, Linux, Windows, and Android hosts. The system architecture is built around a centralized server that communicates with millions of endpoints via osquery and proprietary agents. It emphasizes a "GitOps-first" approach for configuration and a "wireframe-first" methodology for product development.
The project is divided into several major sub-systems: a React-based frontend SPA, a backend server (often referred to as the Fleet server), a static content generation engine for the website and documentation, and integrated automation tools like the Fleet Slackbot.
Sources: handbook/company/README.md, frontend/README.md:3-5
Frontend Architecture
The Fleet frontend is implemented as a Single Page Application (SPA) using React, TypeScript, and Hooks. It follows a structured directory pattern to ensure maintainability and scalability across various device management features.
Core Frontend Components
- Layouts: The application primarily uses a
CoreLayoutwhich manages persistent UI elements like the header and sidebar. - Context API: Global state management (e.g.,
currentUserinfo) is handled via React Context. - Services: These functions encapsulate CRUD operations that interact directly with the Fleet REST API.
- Router: React Router defines the mapping between URLs and specific page components.
Sources: frontend/README.md:46-107
Component Structure
Each component is encapsulated in its own directory containing the logic, styles, and tests.
Sources: frontend/README.md:37-44
GitOps and Configuration Management
Fleet utilizes a GitOps workflow where the state of the infrastructure is defined in YAML files within a specialized repository (typically it-and-security/). This repository serves as the authoritative source of truth for global settings, fleet-specific configurations, and reusable library components.
Repository Structure for GitOps
| Directory/File | Description |
|---|---|
default.yml | Global organization-wide settings. |
fleets/ | Contains specific YAML configs for groups like workstations, servers, or mobile devices. |
lib/ | Reusable library for scripts, policies, queries, and software packages. |
Sources: tools/fleet-slackbot/system-prompt.js:77-100
Configuration Flow
The following diagram illustrates how changes are proposed and applied within the GitOps framework.
Static Content Generation Engine
The website and documentation (fleetdm.com) are powered by a robust static content builder. This engine processes Markdown files, YAML libraries (queries, policies, rituals), and the osquery schema to generate HTML partials and application configuration.
Processing Pipeline
- YAML Parsing: Reads
queries.yml,mdm-commands.yml, andscripts.ymlto bake them into the Sails.js app configuration. - Markdown Compilation: Converts documentation, handbook pages, and articles into HTML using a "Mister Rogers" kind tone and radical honesty.
- Schema Merging: Extends the standard osquery schema with Fleet-specific overrides to generate documentation for every table and column.
- Metadata Extraction: Uses
<meta>tags embedded in Markdown to control page ordering, authorship, and navigation categories.
Sources: website/scripts/build-static-content.js:14-43, website/scripts/build-static-content.js:542-560, handbook/marketing/fleet-ai-writing-instructions.md:9-16
Data Flow for Static Content
Product Development Lifecycle
Fleet follows a "wireframe-first" development flow to ensure technical feasibility and user alignment before any UI code is written.
The "Wireframe-First" Path
- Unpacking the Why: Reviewing requests to synthesize the actual problem users are trying to solve.
- Drafting: Creating Figma wireframes and proposing API/YAML changes via Pull Requests to documentation release branches (e.g.,
docs-vX.X.X). - Design Review: Evaluating wireframes with engineering to assess technical costs.
- Implementation: Engineering starts implementation only after the user story is "Ready to spec" and estimated.
Sources: handbook/product-design/README.md:39-75, handbook/product-design/README.md:143-155
Conclusion
Fleet's architecture is a multi-layered system that balances open-source transparency with enterprise-grade management capabilities. By leveraging a React frontend, a GitOps-driven configuration model, and a sophisticated static content pipeline, Fleet enables IT and security teams to manage millions of devices with clarity and technical precision.
Sources: handbook/company/README.md, frontend/README.md