Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Kevin2523/nextAuditAi/llms.txt

Use this file to discover all available pages before exploring further.

FleetDM is the endpoint data layer of NextAudit AI. It enrolls hosts via osquery, continuously collects hardware and software inventory, evaluates policy posture, and runs scheduled vulnerability scans — all through a single API that n8n workflows and Flowise AI flows can query to drive audit decisions.

​
Service configuration

The fleet service uses the official fleetdm/fleet image and targets the linux/x86_64 platform. Before it starts, it runs fleet prepare db --no-prompt to apply any pending database migrations, then launches the server. 
fleet:
  image: fleetdm/fleet
  platform: linux/x86_64
  command: sh -c "/usr/bin/fleet prepare db --no-prompt && /usr/bin/fleet serve"
  ports:
    - "${FLEET_SERVER_PORT}:${FLEET_SERVER_PORT}"
  restart: unless-stopped

​
Startup dependencies

Fleet waits for three conditions before starting:
DependencyConditionPurpose
mysqlservice_healthySchema migrations require a live database
redisservice_healthySession and query caching must be available
fleet-initservice_completed_successfullyVolume ownership must be set before Fleet writes logs
depends_on:
  mysql:
    condition: service_healthy
  redis:
    condition: service_healthy
  fleet-init:
    condition: service_completed_successfully

​
fleet-init container

fleet-init is a one-shot Alpine container that runs before the main fleet service. Its sole job is to set the correct ownership on the three shared volumes so the Fleet process (which runs as UID 100 / GID 101) can write to them without permission errors. 
fleet-init:
  image: alpine:latest
  volumes:
    - logs:/logs
    - data:/data
    - vulndb:/vulndb
  command: sh -c "chown -R 100:101 /logs /data /vulndb"
fleet-init has no restart policy and runs exactly once per docker compose up. Docker Compose tracks its exit code; only a zero exit triggers the service_completed_successfully condition that unblocks fleet.

​
Environment variables

​
Server and TLS

- FLEET_SERVER_ADDRESS=${FLEET_SERVER_ADDRESS}:${FLEET_SERVER_PORT}
- FLEET_SERVER_TLS=${FLEET_SERVER_TLS}
- FLEET_SERVER_CERT=${FLEET_SERVER_CERT}
- FLEET_SERVER_KEY=${FLEET_SERVER_KEY}
- FLEET_SERVER_PRIVATE_KEY=${FLEET_SERVER_PRIVATE_KEY}
- FLEET_LICENSE_KEY=${FLEET_LICENSE_KEY}
FLEET_SERVER_TLS accepts true or false. When true, set FLEET_SERVER_CERT and FLEET_SERVER_KEY to the paths inside the container where the TLS certificate and key are mounted. Generate FLEET_SERVER_PRIVATE_KEY with: 
openssl rand -base64 32

​
Backend connections

- FLEET_MYSQL_ADDRESS=mysql:3306
- FLEET_MYSQL_DATABASE=${MYSQL_DATABASE}
- FLEET_MYSQL_USERNAME=${MYSQL_USER}
- FLEET_MYSQL_PASSWORD=${MYSQL_PASSWORD}
- FLEET_REDIS_ADDRESS=redis:6379
These use Docker service names (mysql, redis) as hostnames, so no host-level DNS is required.

​
Session and logging

- FLEET_SESSION_DURATION=${FLEET_SESSION_DURATION}
- FLEET_LOGGING_JSON=${FLEET_LOGGING_JSON}
- FLEET_OSQUERY_STATUS_LOG_PLUGIN=${FLEET_OSQUERY_STATUS_LOG_PLUGIN}
- FLEET_FILESYSTEM_STATUS_LOG_FILE=${FLEET_FILESYSTEM_STATUS_LOG_FILE}
- FLEET_FILESYSTEM_RESULT_LOG_FILE=${FLEET_FILESYSTEM_RESULT_LOG_FILE}
- FLEET_OSQUERY_LABEL_UPDATE_INTERVAL=${FLEET_OSQUERY_LABEL_UPDATE_INTERVAL}
FLEET_FILESYSTEM_STATUS_LOG_FILE and FLEET_FILESYSTEM_RESULT_LOG_FILE define the paths inside the /logs volume where osquery status events and query results are written. Set FLEET_OSQUERY_STATUS_LOG_PLUGIN to filesystem to activate file-based logging.

​
Volume mounts

volumes:
  - data:/fleet
  - logs:/logs
  - vulndb:${FLEET_VULNERABILITIES_DATABASES_PATH}
  - ./certs/fleet.crt:/fleet/fleet.crt:ro
  - ./certs/fleet.key:/fleet/fleet.key:ro
MountPurpose
data:/fleetFleet application state and persistent data
logs:/logsosquery status and result log files
vulndb:${FLEET_VULNERABILITIES_DATABASES_PATH}NVD vulnerability feed data
./certs/fleet.crtTLS certificate (read-only)
./certs/fleet.keyTLS private key (read-only)

​
Vulnerability database

Fleet downloads and periodically refreshes the NVD vulnerability feed into the vulndb volume. Three environment variables control this behavior: 
- FLEET_VULNERABILITIES_DATABASES_PATH=${FLEET_VULNERABILITIES_DATABASES_PATH}
- FLEET_VULNERABILITIES_PERIODICITY=${FLEET_VULNERABILITIES_PERIODICITY}
- FLEET_VULNERABILITIES_CURRENT_INSTANCE_CHECKS=${FLEET_VULNERABILITIES_CURRENT_INSTANCE_CHECKS}
FLEET_VULNERABILITIES_DATABASES_PATH must match the container-side mount point in the vulndb volume binding. FLEET_VULNERABILITIES_PERIODICITY is a duration string (e.g. 1h) that controls how often Fleet re-checks for updated vulnerability data.
Set FLEET_VULNERABILITIES_CURRENT_INSTANCE_CHECKS to auto so that only one Fleet instance downloads the feed in multi-replica deployments.

​
Health check

Fleet exposes a /healthz endpoint. The compose health check polls it every 10 seconds with up to 12 retries before marking the container unhealthy: 
healthcheck:
  test: ["CMD", "wget", "-qO-", "http://127.0.0.1:${FLEET_SERVER_PORT}/healthz"]
  interval: 10s
  timeout: 5s
  retries: 12

​
MySQL backend

MySQL 8 stores all Fleet application state: enrolled hosts, policies, queries, packs, and vulnerability results. See Database services for the full MySQL configuration.

​
Redis caching

Redis 6 provides distributed caching for Fleet sessions, live query fanout, and inter-process coordination. See Database services for the full Redis configuration.

Build docs developers (and LLMs) love

Get started for freeTalk to us