> ## 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.

# Subnets

> The governed compute environments where workloads are managed and capacity participates.

A subnet is a governed compute environment.

Builders deploy workloads to subnets. Operators manage subnets and decide who can use them. Providers connect nodes that supply capacity to subnets.

Subnets are regional in the control-plane sense. When an operator creates a subnet, they choose the region where the subnet's control plane is domiciled. Builders then deploy to the subnet; they do not choose the region again for each workload. Actual workload execution happens on admitted data-plane capacity and may be outside that region depending on the subnet's provider capacity and admission policy.

## What a subnet controls

A subnet is the governance boundary for workload placement decisions and connected capacity.

| User path | How the subnet is used                                        |
| --------- | ------------------------------------------------------------- |
| Build     | Choose the subnet that should manage and govern the workload. |
| Operate   | Manage the subnet, runtime policy, and admission rules.       |
| Provide   | Connect nodes that can provide capacity.                      |

## Slugs and display names

Every subnet has a globally unique slug. Commands and manifests use this slug
to identify the subnet.

An optional display name gives the subnet a user-friendly label in lists and
details. Display names do not need to be unique and cannot be used in place of
the slug.

## Regions

Create a subnet in a region:

```bash theme={null}
idyl subnet create --region us-east --display-name "Production"
```

Use `idyl region list` to see available regions. Use `idyl region enable <region>` when the account should allow new workload creation in approved subnets whose control plane is domiciled in that region.

## Admission

Subnet admission controls two kinds of participation:

| Admission type | Controls                                           |
| -------------- | -------------------------------------------------- |
| `developer`    | Which accounts may submit workloads to the subnet. |
| `provider`     | Which fleets or nodes may join as capacity.        |

Admission modes are `open`, `approval`, and `invite`. Admission grants can target developer accounts, provider fleets, or provider nodes.

## Runtime policy

Subnet runtime policy controls which workload isolation classes a subnet
accepts. For example, a subnet can allow only `microvm` workloads, require
workloads to state their isolation class explicitly, or provide a default
isolation class for workloads that omit one.

Runtime policy is separate from admission. A provider node can be admitted to a
subnet but still be incompatible with a workload's requested isolation class.
For the builder, operator, and provider model, see
[Workload isolation](/concepts/workload-isolation).

## Deploy approval

Deploy approval is separate from subnet admission.

Use deploy approval when an account should approve a subnet as a deployment target. Use admission when the subnet operator needs to control which developer accounts or provider capacity can use the subnet.

## Related guides

* [Manage a subnet](/operate/manage-a-subnet)
* [Global accounts and regions](/concepts/global-accounts-and-regions)
* [Sandboxes](/concepts/sandboxes)
* [Workload isolation](/concepts/workload-isolation)
* [Configure runtime policy](/operate/configure-runtime-policy)
* [Control admission](/operate/control-admission)
* [Approve deploy access](/operate/approve-deploy-access)
* [Subnets resource](/resources/subnets)