> ## Documentation Index
> Fetch the complete documentation index at: https://docs.internal.nscale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> What Fleet Manager is, how it is deployed, and where to start.

Fleet Manager is the control plane for nscale's bare-metal fleet. Its job is to turn each
rack into a self-healing, high-yield [GPU](./glossary#gpu) resource by fusing inventory truth, proactive
health checks, and automatic remediation — so [clusters](./glossary#cluster) stay performant and teams stay
focused on models, not maintenance.

It gives operators and developers a single place to:

* See and manage hardware inventory across sites
* Enrol new [devices](./glossary#node) into the fleet
* Run and observe provisioning, validation, and [burn-in](./glossary#burn-in) workflows
* Handle day-2 operations such as remediation and decommissioning

It coordinates these activities across the underlying infrastructure so operators don't
have to touch each system directly. [NetBox](./glossary#netbox) is the source of truth for inventory and
lifecycle state; provisioning and runtime state are reconciled separately from [Ironic](./glossary#ironic).

## What Fleet Manager manages

Fleet Manager coordinates work across several systems:

* NetBox for inventory and site metadata
* OpenStack services such as Ironic, [Nova](./glossary#nova), and [Placement](./glossary#placement)
* [DHCP](./glossary#dhcp) infrastructure used during provisioning
* [1Password](./glossary#1password) and related secret-management workflows
* [SLURM](./glossary#slurm) for hardware burn-in and validation workloads
* Prometheus, Grafana, and [Temporal](./glossary#temporal) for visibility into running systems

## How Fleet Manager is deployed

Fleet Manager is built around a hub/satellite topology:

* The **hub** exposes the main API and provides the global control-plane view
* Each **satellite** runs site-local agents and workflow workers close to the hardware it manages
* Background agents synchronise data from external systems into Fleet Manager's own database so the API can serve rich queries without depending on live fan-out calls

This layout mirrors the production trust boundaries and keeps site-specific credentials,
PKI, and workflow execution scoped to the right deployment.

## Audience

These published Fleet Manager docs are written for internal-public use by engineers and operators.
They intentionally include concrete operational commands, environment-specific checks, and rollout
steps needed to stand up and run Fleet Manager.

## Use These Docs

* Start with [Getting Access](./getting-access) for the access you need as an operator or user of Fleet Manager
* Keep the [Glossary](./glossary) to hand for the hardware, OpenStack, scheduling, and validation terms these docs assume
* Use the [Operator Guide](../operator-guide/overview) for day-to-day operational entrypoints
* Use the [Deployment Guide](../deployment-guide/overview) when standing up or validating a site
* Use the [Developer Guide](../developer-guide/overview) when working in the codebase, authoring workflows, or setting up a local development environment — see [Onboarding](../developer-guide/onboarding) for the team onboarding checklist and ownership map
* Use [Temporary Production Cluster Access](./temporary-production-cluster-access) for time-limited production Kubernetes access

## Current Scope

The published Fleet Manager docs are being populated incrementally from the repo's internal
runbooks and ADRs. The current focus is deployment, architecture, and developer onboarding,
with additional operator and API material to be added over time.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.