// the find
dstackai/dstack
Vendor-agnostic orchestration for training, inference and agentic workloads across NVIDIA, AMD, TPU, and Tenstorrent on clouds, Kubernetes, and bare metal.
dstack is a self-hosted control plane for running GPU workloads across any combination of cloud providers, Kubernetes clusters, and bare-metal SSH fleets. You define Fleets, Tasks, Services, and Volumes in YAML files, run `dstack apply`, and it handles provisioning, job queuing, and failure recovery across backends. It's aimed at ML teams who need to avoid cloud lock-in without building their own orchestration layer.
The vendor-agnostic model actually holds up — it treats AWS, GCP, Lambda Labs, and SSH-accessible bare metal through the same abstraction layer, which is rarer than the marketing implies. Out-of-capacity error handling and automatic retry on spot preemption is built-in, not bolted on later. The contributing docs are unusually complete: separate architecture, autoscaling, backends, migrations, proxy, and runner docs that explain why things work the way they do. The plugin system (examples/plugins) lets you extend the server rather than fork it, which matters when you need a non-standard backend.
At 0.20.x, the API surface is still moving — the fleet-first UX was a major rework as recently as 0.20.0 in December 2025, which means anything you automate today might need updating next quarter. There's no cost guard: you can schedule a multi-node H100 fleet through a YAML file with no budget cap or spend alert, which is a real footgun when AI agents are submitting workloads on your behalf. The agentic orchestration angle (AI agents using the CLI via agent skills) is extremely new (0.20.8, February 2026) and amounts to letting Claude edit your YAML files and run `dstack apply` — the security model for that is unclear. The server is self-hosted with no managed offering surfaced in the repo, so you're taking on operational responsibility for the control plane itself.