Simplify deployment: unify dstack and meta-dstack workflows

まず kms/dstack-app/deploy-simple.sh と deploy-to-vmm.sh を読み、次にそれらの入力を meta-dstack's build.sh の hostcfg および dl ワークフローと比較します。デプロイメントのエントリーポイント、ディレクトリレイアウト、ゲストイメージの取得、開発用および本番用のパスが説明どおりに統一され、OS イメージをソースからビルドすることは引き続き任意であれば完了です。

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

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.