CLI reference
Commands
| Area | Commands |
|---|---|
| VMs | vm add · list · ping · bootstrap · remove · vm runner [remove] (GitHub Actions runner, opt-in agent) |
| Stacks | stack add · list · remove · ps · logs · pull |
| Deploy | stack deploy (compose up) · stack release (sync → build → deploy) |
| Backups | stack backup · stack backups · stack restore --yes |
| Single container | deploy |
| Security | scan (OWASP ZAP baseline, passive) |
| Provision (experimental, billable) | vm provision · up (behind --dry-run) |
| Local | doctor [--fix] · version |
Generated command flags and examples: command reference. Operator workflows: USAGE.md.
stack release is config-driven
A JSON manifest in your repo describes what to sync + build + deploy. The CLI has
no app-specific logic. The compose dir (with its .env) is deliberately never
in the sync list, so --delete can't wipe your secrets.
verify is what stops a release calling itself done without asking the running
site anything. Point it at a check script the repo already has, or leave it out
and set healthUrl on the stack and a curl --fail probe is used instead.
{
"localRoot": "~/repos/app",
"remoteRoot": "/home/deploy/app",
"sync": ["api", "web"],
"exclude": ["bin", "obj", "node_modules", ".next", ".git"],
"builds": [
{ "image": "app-api:latest", "dockerfile": "deploy/Dockerfile.api", "context": "api" },
{ "image": "app-web:latest", "dockerfile": "deploy/Dockerfile.web", "context": "web",
"args": { "NEXT_PUBLIC_API_URL": "" } }
]
}