Simplify deployment: unify dstack and meta-dstack workflows

[h4x3rotab]

Problem

Setting up dstack currently requires understanding two repositories with different workflows:

1. Two repos required for basic deployment

• meta-dstack: Config generation (build.sh hostcfg) and image download (build.sh dl)
• dstack: Components and deploy scripts (kms/dstack-app/deploy-*.sh)

New users must clone both repos and understand their relationship.

2. Inconsistent paths between dev and production

Task	Dev Deployment	Production Deployment
Get guest image	../build.sh dl 0.5.5	Direct GitHub release download
Generate configs	../build.sh hostcfg	Manual or embedded in compose
Deploy KMS	Run binary on host	kms/dstack-app/deploy-*.sh

Same artifacts, different acquisition paths.

3. Deploy scripts in unexpected location

• kms/dstack-app/deploy-simple.sh and deploy-to-vmm.sh deploy to VMM
• These aren't KMS-specific—they're general CVM deployment scripts
• Expected location would be top-level deploy/ or similar

4. Guest image acquisition differs

• Dev: Requires meta-dstack checkout, then ../build.sh dl
• Prod: Direct download from https://github.com/Dstack-TEE/meta-dstack/releases

Both get the same tarball via different paths.

Impact

• Steeper learning curve for new operators
• Documentation must explain two different workflows
• Easy to get confused about which repo/script to use
• Friction when switching between dev and production setups

Suggested Direction

• Single entry point for deployment (no meta-dstack required for normal use)
• Unified deploy/ directory structure in dstack repo
• meta-dstack becomes optional (only needed for building OS image from source)
• Config templates with sensible defaults

This is a tracking issue for discussion. Implementation would be a larger effort.