Asset & Installer Storage
Relevant source files
The following files were used as context for generating this wiki page:
Asset and Installer Storage refers to the management, generation, and delivery of software packages, MDM configuration profiles, and static documentation assets within the Fleet ecosystem. This system encompasses the infrastructure for Fleet-maintained apps (FMA), the automated build processes for static website content, and the storage of security compliance artifacts like CIS benchmarks.
The system ensures that IT and security teams have access to validated installers for multiple platforms (macOS, Windows, Linux) and provides a consistent mechanism for deploying these assets via GitOps workflows or the Fleet UI.
Software Installer Architecture
Fleet utilizes a structured approach to managing software installers, particularly through the Fleet-maintained apps (FMA) feature. This involves an ingestion process where metadata from package managers (Homebrew for macOS, Winget for Windows) is transformed into standardized Fleet manifests.
Installer Ingestion Flow
The ingestion process involves identifying application identifiers, installer formats (pkg, dmg, msi, exe), and required scripts for installation and uninstallation.
The generator script processes inputs to produce output data including version information, install/uninstall scripts, and platform-specific metadata.
Sources: ee/maintained-apps/README.md:14-38, ee/maintained-apps/README.md:92-114
Platform-Specific Installer Metadata
Each platform requires specific fields to ensure successful deployment and inventory matching.
| Field | Platform | Description |
|---|---|---|
token | macOS | Homebrew's unique identifier. |
installer_format | macOS | File format (zip, dmg, pkg). |
package_identifier | Windows | Winget PackageIdentifier. |
installer_type | Windows | File type (exe, msi, msix). |
unique_identifier | Both | Platform-specific ID (Bundle ID for macOS, DisplayName for Windows). |
Sources: ee/maintained-apps/README.md:46-64, ee/maintained-apps/README.md:120-138
Static Asset Generation
Fleet's website and internal documentation are served as static content compiled from Markdown and YAML source files. This process is managed by the build-static-content script, which generates HTML partials and configuration metadata.
Static Build Process
The build process scans specific directories in the repository to generate the documentation library, standard query library, and osquery schema tables.
This flow ensures that the website's documentation and libraries are automatically updated when changes are merged into the main branch.
Sources: website/scripts/build-static-content.js:19-50, handbook/engineering/website.md:27-44
Static Content Categories
The build script categorizes content into several structures within the Sails configuration:
- Queries: Parsed from
docs/queries.yml. - Policies: Parsed from
docs/01-Using-Fleet/standard-query-library/standard-query-library.yml. - Markdown Pages: Compiled documentation from
docs/,handbook/, andarticles/. - Schema Tables: Generated from the osquery schema combined with Fleet overrides.
Sources: website/scripts/build-static-content.js:52-120, website/scripts/build-static-content.js:630-710
MDM Configuration Profiles & CIS Benchmarks
MDM configuration profiles are stored as .mobileconfig (macOS) or .xml (Windows) assets. These are critical for enforcing security compliance, particularly for CIS (Center for Internet Security) benchmarks.
CIS Benchmark Artifacts
CIS benchmarks are stored in specific versioned directories (e.g., ee/cis/macos-15/) and include:
- Policy Queries: YAML files containing osquery SQL.
- Test Scripts: Shell scripts (
_pass.sh,_fail.sh) to verify compliance. - MDM Profiles: Configuration files that apply the required security settings.
Profile Implementation Patterns
Fleet enforces a strict UUID and identifier convention for MDM profiles to ensure reliability.
- Top-level UUID: Generated via
uuidgenfor the profile container. - Inner Payload UUID: Generated for the specific setting payload.
- PayloadIdentifier: Typically formatted as
com.fleetdm.cis-{cis_id}.
Sources: ee/cis/CIS-BENCHMARKS.md:217-250
Storage Management and Deployment
Deployment of assets is handled through a combination of Heroku for the website and GitHub Actions for CI/CD workflows.
Build and Deployment Flow
- Local Testing: Developers run
sails run build-static-contentandsails liftto preview documentation changes locally athttp://localhost:2024. - Production Deployment: Merging to the
mainbranch triggers a GitHub Action that redeploys the website and its associated assets. - Sitemap Generation: A dynamic sitemap is generated from
sails.config.builtStaticContent, including all dynamic reports, vitals, and software catalog pages.
Sources: handbook/engineering/website.md:46-52, website/api/controllers/download-sitemap.js:33-70
Security and Governance
Asset storage is governed by DRIs (Directly Responsible Individuals) assigned to specific paths in the repository.
| Path | DRI | Responsibility |
|---|---|---|
website/assets | eashaw | Website frontend code and images. |
ee/maintained-apps | allenhouchins | FMA installers and metadata. |
ee/cis | sharon-fdm | CIS benchmark policies and profiles. |
articles | mike-j-thomas | Marketing content and articles. |
Sources: website/config/custom.js:147-190
Summary
Asset & Installer Storage in Fleet is a distributed system that manages the lifecycle of software installers, MDM profiles, and static documentation. By leveraging automated build scripts and GitOps-friendly manifest files, Fleet ensures that technical assets are validated, versioned, and easily deployable across diverse endpoint environments. The use of structured YAML and JSON manifests allows for both human readability and programmatic consumption by the Fleet server and website.