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

# Workloads

> How IDYL workload resources fit together.

Workloads are the runnable resources IDYL manages. They describe desired work; IDYL schedules pods and reports observed runtime state when you inspect the resources.

| Workload   | Use it when                                                 | Creates or represents                                          |
| ---------- | ----------------------------------------------------------- | -------------------------------------------------------------- |
| Deployment | Software should keep running                                | ReplicaSets and pods                                           |
| Job        | Work should run to completion                               | Pods                                                           |
| CronJob    | Jobs should run on a schedule                               | Jobs, then pods                                                |
| Sandbox    | You need a disposable Linux environment with a required TTL | A Sandbox environment and associated pod status when available |
| Pod        | You need to run one pod spec directly                       | One pod                                                        |
| ReplicaSet | A fixed number of identical pods should run                 | Pods                                                           |

## How they relate

A Deployment, Job, CronJob, or ReplicaSet describes desired work. Pods are the runtime units created for that work. Builders usually create Deployments and Jobs, then inspect pods to see what is actually running.

## Shared settings

Every workload has `kind`, `metadata`, `spec`, and read-only `status` fields. Most workload types also share a pod spec, which is where container images, environment variables, resource requests, restart policy, GPU requirements, and host capability requirements are defined.

| Workload   | Pod spec path                         |
| ---------- | ------------------------------------- |
| Deployment | `spec.template.spec`                  |
| Job        | `spec.template.spec`                  |
| CronJob    | `spec.jobTemplate.spec.template.spec` |
| Sandbox    | `spec.template.spec`                  |
| Pod        | `spec`                                |
| ReplicaSet | `spec.template.spec`                  |

## Manifest reference

<Columns cols={2}>
  <Card title="Deployment reference" href="/resources/reference/generated/deployment">
    YAML fields for replicated, rolling application workloads.
  </Card>

  <Card title="Job reference" href="/resources/reference/generated/job">
    YAML fields for run-to-completion workloads.
  </Card>

  <Card title="CronJob reference" href="/resources/reference/generated/cronjob">
    YAML fields for scheduled jobs.
  </Card>

  <Card title="Sandbox reference" href="/resources/reference/generated/sandbox">
    YAML fields for disposable Linux environments.
  </Card>

  <Card title="Pod reference" href="/resources/reference/generated/pod">
    YAML fields for direct pod manifests.
  </Card>

  <Card title="ReplicaSet reference" href="/resources/reference/generated/replicaset">
    YAML fields for fixed-size pod sets.
  </Card>
</Columns>

Use [Use a manifest](/build/use-a-manifest) when you want to create or update workloads from YAML.