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:
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.
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-shutdownwith--idle-timeoutto stop paying for an idle box.--install-roarto install roar as part of the managed bootstrap, so runs on that target capture lineage.--userdata-scriptfor anything else that needs to happen at startup.
You can watch what a target has launched:
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.
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:
name: train
secrets:
- WANDB_API_KEY
- HF_TOKEN
A secret that a workflow doesn't declare is not injected. See 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.