# Compute targets

> Where training runs execute — dedicated machines, on-demand cloud instances, and the secrets they need.

::div{class="flex items-start gap-6"}
::div{class="shrink-0 flex items-center justify-center mt-1 size-24 rounded-4xl bg-dim-200"}
:u-icon{name="i-lucide-cpu" class="size-16 text-primary"}
::

A **compute target** is somewhere a training run can execute. Targets are configured at the organization level and shared across all of that organization's projects — you set up a GPU box or a cloud provider once, and every project can queue work onto it.
::

## Dedicated

A machine you already have — a workstation under a desk, a rack server, a long-lived cloud VM. You install the TReqs agent on it and register it against the target using a registration code:

```bash [TReqs CLI]
treqs compute targets create --name gpu-box
treqs compute targets registration-code create --target gpu-box
```

The agent polls TReqs for work. A dedicated target shows as **online** or **offline** depending on whether its agent has checked in recently. Nothing is provisioned or billed by TReqs — you own the machine and it's available whenever it's running.

## On-demand

TReqs launches an instance from a cloud provider when a run needs one, and shuts it down afterwards. Nothing runs — and nothing costs — between jobs.

```bash [TReqs CLI]
treqs compute targets create --kind on-demand --name burst \
    --type runpod --instance-type cpu3c
```

On-demand targets take an instance type and a region (or `any`). Useful extras:

- `--auto-shutdown` with `--idle-timeout` to stop paying for an idle box.
- `--install-roar` to install roar as part of the managed bootstrap, so runs on that target capture lineage.
- `--userdata-script` for anything else that needs to happen at startup.

You can watch what a target has launched:

```bash [TReqs CLI]
treqs compute targets instances gpu-burst
```

## Configuration

### Providers

On-demand targets currently support **AWS**, **GCP**, **Azure**, **RunPod**, and **Lambda**.

AWS takes the most configuration, because TReqs launches into *your* account and VPC:

- `--ami-id` — required for AWS launches. Omit it in an interactive session with a concrete region and you can pick from a live list.
- `--subnet-id` — repeatable. The first is primary; the rest are fallbacks tried when an availability zone reports a capacity error.
- `--security-group-id` — repeatable, optional.
- `--ssh-key-name` — an EC2 key pair to attach, if you want to be able to log in.

### Provider credentials

Before TReqs can launch anything, it needs permission in your cloud account. Add credentials under **Configure → Compute → Credentials**. Each provider is connected the way that provider prefers, rather than by pasting long-lived keys:

- **AWS** — you create a role that trusts the TReqs compute broker and grant it the permissions to launch instances.
- **GCP** — you grant the TReqs broker service account the ability to impersonate a service account in your project.
- **Azure** — you consent to the multi-tenant TReqs application in your tenant and give it resource-group-scoped roles.

The dashboard shows the exact principal to trust for each, and runs a connection test afterwards. Credentials report as **valid**, **invalid**, or **unknown**; an invalid credential means launches on that provider will fail, so fix it before queueing work.

### Secrets

Runs usually need credentials of their own — a Weights & Biases key, a Hugging Face token, an API key for something your training script calls. These are **compute target secrets**: set on a target, injected into the environment of runs that execute there.

```bash [TReqs CLI]
treqs compute secrets set --target gpu-box WANDB_API_KEY=abc123
treqs compute secrets set --target gpu-box HF_TOKEN=hf_x REGION=us
treqs compute secrets list --target gpu-box
treqs compute secrets delete --target gpu-box WANDB_API_KEY
```

`--target` accepts a target ID, a unique name, or a unique ID prefix from `treqs compute targets list`.

Listing secrets shows key names, never values — once set, a secret cannot be read back out of TReqs. To rotate one, set it again with the new value.

A workflow has to declare which secrets it wants before they're exposed to its stages:

```yaml
name: train
secrets:
  - WANDB_API_KEY
  - HF_TOKEN
```

A secret that a workflow doesn't declare is not injected. See [Workflows](/docs/workflows).

Because secrets live on the compute target, every project in the organization that runs on that target gets them. If a key should not be that widely available, put it on a separate target.