Deployment
Remove a deployed environment from its server.
Syntax
$ vela destroy deployment $ vela destroy deployment -t staging $ vela destroy deployment -t preview:feature/maps This stops and removes the app’s systemd services, deletes its releases and withdraws its Caddy configuration, so the site stops being served. Other apps and other targets on the same server are untouched. A target the server has nothing for is reported as such and the command exits 0 — nothing is removed, and a pull request whose preview never deployed closes cleanly.
For a linked project the environment is also retired on velastack.dev, and any velastack.app hostname it had stops answering at the edge. This is how a finished preview is removed; a pull request closed through the GitHub Action does it automatically.
Options
-t, --target <target>- Which copy of the app to act on, defaults toproduction--server <ssh>- Server this target runs on, recorded on first use--purge- Also delete the database and uploaded files, after snapshotting them into the server’s trash-y, --yes- Skip the confirmation prompt. Not enough on its own for production, or for a purge of anything but a preview--confirm <app-name>- Confirm removing production, or a purge, by naming the app — what a terminal would ask you to type--lock-wait <seconds>- How long to wait for a deploy, rollback or restore of the same target to finish before giving up, defaults to300-i, --identity <file>- SSH private key to authenticate with--ssh-port <port>- SSH port--accept-host-keys- Trust an unknown host key on first connect (CI)
Confirming
Removing production, or purging anything but a preview, asks you to type the app’s name. Off a terminal — in CI — pass --confirm <app-name> instead. --yes alone is refused for both, so a workflow that passes --yes on every event cannot take production down by mistake; the GitHub Action exposes this as confirm-name. Previews need only --yes, purge included.
Purging data
Without --purge, the database and uploaded files are left on the server, so the environment can be deployed again onto its existing data. --purge deletes them — after packing them into /var/lib/vela/trash/<instance>-<time>.tar.gz on the server, readable by root only and kept for two weeks. Nothing older than that survives, and no backup is taken anywhere else.