# Despliegue Elimina un entorno desplegado de su servidor. ### Sintaxis ``` $ vela destroy deployment ``` ``` $ vela destroy deployment -t staging ``` ``` $ vela destroy deployment -t preview:feature/maps ``` Esto detiene y elimina los servicios systemd de la aplicación, borra sus releases y retira su configuración de Caddy, con lo que el sitio deja de servirse. Otras aplicaciones y otros objetivos en el mismo servidor quedan intactos. Un objetivo del que el servidor no tiene nada se comunica como tal y el comando sale con 0 — no se elimina nada, y un pull request cuya previsualización nunca llegó a desplegarse se cierra limpiamente. En un proyecto [vinculado](/es/link) el entorno también se retira en velastack.dev, y cualquier nombre de host `velastack.app` que tuviera deja de responder en el borde. Así es como se elimina una [previsualización](/es/deploy/previews) terminada; un pull request cerrado a través de la [acción de GitHub](/es/helpers/github-action) lo hace automáticamente. ### Opciones - `-t, --target ` - Sobre qué copia de la aplicación actuar, por defecto `production` - `--server ` - Servidor en el que se ejecuta este objetivo, registrado en el primer uso - `--purge` - Borrar también la base de datos y los archivos subidos, tras guardar una instantánea en la papelera del servidor - `-y, --yes` - Omitir la confirmación. Por sí solo no basta para producción, ni para purgar cualquier cosa que no sea una previsualización - `--confirm ` - Confirmar la eliminación de producción, o una purga, nombrando la aplicación — lo que un terminal te pediría escribir - `--lock-wait ` - Cuánto esperar a que termine un despliegue, reversión o restauración del mismo objetivo antes de rendirse, por defecto `300` - `-i, --identity ` - Clave privada SSH con la que autenticarse - `--ssh-port ` - Puerto SSH - `--accept-host-keys` - Confiar en una clave de host desconocida en la primera conexión (CI) ### Confirmar Eliminar producción, o purgar cualquier cosa que no sea una previsualización, te pide escribir el nombre de la aplicación. Fuera de un terminal — en CI — pasa `--confirm ` en su lugar. `--yes` por sí solo se rechaza en ambos casos, así que un workflow que pase `--yes` en todos los eventos no puede tirar producción por error; la [acción de GitHub](/es/helpers/github-action) lo expone como `confirm-name`. Las previsualizaciones solo necesitan `--yes`, purga incluida. ### Purgar los datos Sin `--purge`, la base de datos y los archivos subidos se dejan en el servidor, de modo que el entorno puede desplegarse de nuevo sobre sus datos existentes. `--purge` los borra — después de empaquetarlos en `/var/lib/vela/trash/-.tar.gz` en el servidor, legible solo por root y conservado dos semanas. Nada más antiguo sobrevive, y no se hace ninguna otra copia de seguridad.