[Feature]: Targon backend #4382

Problem

We run GPU workloads (video generation) across several marketplaces and use dstack to manage capacity. Vast.ai and RunPod already work through dstack, and Lium is in progress (#4377). Targon is the one provider we still manage with separate scripts.

Targon rents single-GPU VMs, including RTX PRO 6000 Blackwell (96 GB) at $1.69/h. That is among the lowest RTX PRO 6000 prices we see. Without a dstack backend, we cannot use one fleet/run configuration, price caps and cleanup across all of them.

Solution

Add a VM-based targon backend, with a targon online provider in gpuhunt first, per contributing/BACKENDS.md.

What the Targon API offers (https://docs.targon.com/api/workloads):

• Offers: public GET /tha/v3/inventory?type=vm&gpu=true, with price, CPU/RAM/disk, GPU model/count and available count. No regions for VMs.
• Lifecycle: POST /orgs/{org}/workloads (type VM, image, resource_name, SSH key UIDs) registers the VM, POST .../deploy starts it, GET .../state returns status, public_ip and ssh_port, and DELETE tears it down.
• SSH keys: POST /orgs/{org}/ssh-keys. The SSH user is ubuntu, and the SSH port is mapped per VM.
• Images: Ubuntu 24.04 with NVIDIA 595 drivers (ubuntu-24-04-lts-595).

Two gaps against the VM-based backend requirements:

1. No cloud-init.
2. No Docker or NVIDIA Container Toolkit in the images.

My proposed handling follows existing backends:

• Like Hot Aisle, update_provisioning_data waits for running, then starts the shim over SSH.
• Like Lambda, it installs Docker and the NVIDIA Container Toolkit over SSH first. Each step is skipped if already present, and a marker file makes a repeated launch a no-op.
• It skips the ufw setup, since the provider maps the SSH port at its edge.

Other proposed behavior:

• If deploy fails, the backend deletes the registered workload and raises NoCapacityError, so the next offer is tried.
• The project SSH key is registered once per org and reused.
• Config: creds.api_key, optional org_slug (auto-detected if the key has one org) and optional vm_image.

Prototype status. Both branches are local; I have not opened PRs:

• gpuhunt: provider, registration, unit tests, and an integrity test against the live public inventory.
• dstack: backend, docs and frontend type. Unit tests mock all Targon calls.
• ruff (0.12.7) and pyright are clean.
• Full test suites pass: dstack src/tests 4451 passed / 1410 skipped; gpuhunt 255 passed.
• Live E2E (2026-10-17): a nodes: 0..1 fleet plus a task on rtx6000b-small ran end to end.
  • About 3 min to running, about 1 min for the Docker install and shim start, then the job ran.
  • nvidia-smi showed an RTX PRO 6000 Blackwell Server Edition, 97887 MiB. The task exited 0.
  • The workload was deleted afterwards. About 6 min total.

Questions before I open PRs:

1. Is a Targon backend welcome?
2. Is installing Docker and the toolkit over SSH acceptable, or would you prefer a dstack-maintained image or asking Targon for one?

Workaround

Rent Targon VMs with our own scripts, then register them as an SSH fleet. This splits lifecycle, price caps and cleanup between two systems.

Would you like to help us implement this feature by sending a PR?

Yes