dstackSAFE

A unified orchestration layer for heterogeneous AI compute. It standardizes how to manage compute and run training and inference on GPU clouds, Kubernetes, VMs, or bare-metal clusters.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: dstack
description: |
  dstack is an open-source control plane for GPU provisioning and orchestration across GPU clouds, Kubernetes, and on-prem clusters.
---

# dstack

## Overview

`dstack` provisions and orchestrates workloads across GPU clouds, Kubernetes, and on-prem via fleets.

**When to use this skill:**
- Running or managing dev environments, tasks, or services on dstack
- Creating, editing, or applying `*.dstack.yml` configurations
- Managing fleets, volumes, gateways, and checking available offers

## How it works

`dstack` operates through three core components:

1. `dstack` server - Can run locally, remotely, or via dstack Sky (managed)
2. `dstack` CLI - Applies configurations and manages or inspects fleets, runs,
   logs, events, volumes, gateways, and offers; it uses project configurations
   stored in `~/.dstack/config.yml`, which can be managed with `dstack project`
3. `dstack` configuration files - YAML files ending with `.dstack.yml`

`dstack apply` shows a plan and submits configuration changes. For run
configurations, it attaches when the run reaches `running` by default: it
configures SSH access, forwards declared ports, and streams logs. With `-d`, it
submits and exits.

## Quick agent flow (detached runs)

1) Show plan: `echo "n" | dstack apply -f <config>`
2) If plan is OK and user confirms, apply detached: `dstack apply -f <config> -y -d`
3) Check the run: `dstack run get <run-name> --json`
4) If dev-environment or task with ports and running: attach to surface IDE link/ports/SSH alias (agent runs attach in background); ask to open link
5) If attach fails in sandbox: request escalation; if not approved, ask the user to run `dstack attach` locally and share the output

**CRITICAL: Never propose `dstack` CLI commands or YAML syntaxes that don't exist.**
- Only use CLI commands and YAML syntax documented here or verified via `--help`
- If uncertain about a command or its syntax, check the links or use `--help`

**NEVER do the following:**
- Invent CLI flags not documented here or shown in `--help`
- Guess YAML property names - verify in configuration reference links
- Run `dstack apply` for runs without `-d` in automated contexts (blocks indefinitely)
- Retry failed commands without addressing the underlying error
- Summarize or reformat tabular CLI output - show it as-is
- Use `echo "y" |` when `-y` flag is available
- Assume a command succeeded without checking output for errors

## Agent execution guidelines

### Output accuracy
- **NEVER reformat, summarize, or paraphrase CLI output.** Display tables, status output, and error messages exactly as returned.
- When showing command results, use code blocks to preserve formatting.
- If output is truncated due to length, indicate this clearly (e.g., "Output truncated. Full output shows X entries.").

### Verification before execution
- **When uncertain about any CLI flag or YAML property, run `dstack <command> --help` first.**
- Never guess or invent flags. Example verification commands:
  ```bash
  dstack --help                               # List all commands
  dstack apply -h <configuration type>        # Flags for apply per configuration type (dev-environment, task, service, fleet, etc)
  dstack fleet --help                         # Fleet subcommands
  dstack ps --help                            # Flags for ps
  ```
- If a command or flag isn't documented, it doesn't exist.

### Command timing and confirmation handling

**Commands that stream indefinitely in the foreground:**
- `dstack attach`
- `dstack apply` without `-d` for runs
- `dstack ps -w`

Agents should avoid blocking: use `-d`, timeouts, or background attach. When attach is needed, run it in the background by default (`nohup ...`), but describe it to the user simply as "attach" unless they ask for a live foreground session.

When waiting programmatically for a specific run, use
`dstack run get <run-name> --json` and read its top-level `status`. Run statuses
are `pending`, `submitted`, `provisioning`, `running`, `terminating`,
`terminated`, `failed`, and `done`; the last three are terminal. Stop waiting
when the run reaches the state needed for the next action or a terminal status.
Never parse or grep human-readable `dstack ps` output; its status column may
display a job message such as `no offers`.

**All other commands:** Use 10-60s timeout. Most complete within this range. **While waiting, monitor the output** - it may contain errors, warnings, or prompts requiring attention.

**Confirmation handling:**
- `dstack apply`, `dstack stop`, `dstack fleet delete` require confirmation
- Use `-y` flag to auto-confirm when user has already approved
- For `dstack stop`, always use `-y` after the user confirms to avoid interactive prompts
- Use `echo "n" |` to preview `dstack apply` plan without executing (avoid `echo "y" |`, prefer `-y`)

**Best practices:**
- Prefer modifying configuration files over passing parameters to `dstack apply` (unless it's an exception)
- When user confirms deletion/stop operations, use `-y` flag to skip confirmation prompts

### Detached run follow-up (after `-d`)

After submitting a run with `-d` (dev-environment, task, service), first determine whether submission failed. If the apply output shows errors (validation, no offers, etc.), stop and surface the error.

If the run was submitted, check it with `dstack run get <run-name> --json`, then guide the user through relevant next steps:
If you need to prompt for next actions, be explicit about the dstack step and command (avoid vague questions). When speaking to the user, refer to the action as "attach" (not "background attach").
- **Monitor status:** Report the current status and offer to keep watching. If watching, poll `dstack run get <run-name> --json` every 10-20 seconds until it reaches the state needed for the next action or a terminal status.
- **Attach when running:** For agents, run attach in the background by default so the session does not block. Use it to c

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

[![ModelsAtlas audit: dstack](https://modelsatlas.com/skills/dstackai/dstack/badge.svg)](https://modelsatlas.com/skills/dstackai/dstack/)

Not your listing, or something out of date? Claim or update your listing.