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

# Capacity

> How nodes and fleets provide compute capacity to subnets.

Capacity comes from nodes connected to subnets.

Providers run nodes on machines that can execute workloads. Operators inspect nodes to understand what capacity is connected to a subnet.

## Nodes

A node is a machine connected to IDYL as compute capacity.

Every node has an immutable node ID. The node ID is the canonical identifier
used for commands, API paths, admission, placement, authentication, and
scheduling.

A provider can also assign an optional display name such as `gpu-1`. The
display name is a mutable presentation label:

* It does not need to be unique.
* It is never accepted in place of the node ID.
* Renaming a node does not change its identity, admission, fleet membership, or
  workload placement.
* Interfaces show the node ID with the display name so duplicate names remain
  unambiguous.

A set display name contains between 1 and 255 Unicode code points and cannot
have leading or trailing whitespace. Spaces and punctuation are allowed.

The account that owns the provider node controls its display name. The label is
visible wherever the node is already visible, including fleet membership and
subnet runtime views. Do not include credentials, secrets, private URLs, or
other sensitive information in a node display name.

Node runtime state includes whether the node is connected or disconnected, the
subnet it is associated with, and reported capacity such as CPU, memory, GPU
count, and capabilities.

Use `idyl node get` to inspect nodes in a subnet.

## Fleets

A fleet is a provider-managed group of nodes.

Fleets are identified by fleet ID. The fleet display name is a label and can be changed.

Use fleets when capacity should be managed or admitted as a group. A provider admission grant can target a fleet, and nodes in that fleet can participate according to the grant.

## Capacity matching

Workload placement depends on the pod spec:

* Container CPU, memory, and disk requests.
* Pod-level GPU requirement.
* Host capability requirements.

Nodes that do not match the workload requirements cannot run that workload.

## Related guides

* [Connect a node](/provide/connect-a-node)
* [Manage fleets](/provide/manage-fleets)
* [Inspect nodes](/operate/inspect-nodes)
* [Pod specs and containers](/concepts/pod-specs)