# Previsualizaciones Despliega una rama como una copia propia de la aplicación — su propio proceso, su propia base de datos, su propio nombre de host — y elimínala cuando la rama termine. ### Sintaxis ``` $ vela deploy -t preview ``` ``` $ vela deploy -t preview:feature/maps ``` `preview` a secas previsualiza la rama que está en el árbol de trabajo. `preview:` nombra una explícitamente, que es lo que necesitas con un HEAD separado o en CI. Solo `preview` admite un sufijo `:rama`; `-t staging:main` es un error. ### Qué es una previsualización Una previsualización es una instancia completa en el servidor, exactamente igual que producción o [staging](/es/deploy): su propio proceso de Node, su propia base de datos y archivos subidos de PocketBase, su propio puerto asignado internamente. No comparte nada con producción ni con otras previsualizaciones, así que una migración o un cambio de datos en una rama no puede tocar el sitio en vivo. Todos los comandos que aceptan un objetivo aceptan una previsualización: ``` $ vela status -t preview:feature/maps $ vela logs -t preview:feature/maps $ vela env set -t preview:feature/maps STRIPE_SECRET_KEY ``` ### Nombres de host Una previsualización recibe un nombre de host gratuito de velastack.dev, formado por el subdominio del proyecto y la rama: ``` --.velastack.app ``` `feature/maps` se convierte en `feature-maps-1a2b3c`: en minúsculas, todo lo que no sea letra o dígito reducido a un guion, y un hash corto del nombre completo de la rama siempre que eso haya cambiado algo, de modo que `feature/maps` y `feature-maps` nunca puedan compartir una instancia. Una rama que ya es letras minúsculas, dígitos y guiones conserva su nombre tal cual. El nombre se imprime al final del despliegue y está en línea en menos de un minuto. Consulta [Dominios](/es/deploy/domains) para saber cómo se eligen y se sirven estos nombres. Para ello el proyecto tiene que estar [vinculado](/es/link) y la CLI con sesión iniciada, con [`vela login`](/es/account/login) o `VELA_API_KEY` en el entorno. Una previsualización a la que nada enruta se detiene antes de compilar: ``` Nothing routes to this preview. Previews get a free velastack.app hostname from velastack.dev: `vela link` the project and `vela login` (or set VELA_API_KEY). Or pass `--domain ` with DNS of your own pointing at root@example.com. ``` Las previsualizaciones nunca heredan el dominio de producción — ese es solo de producción. Para servir también las previsualizaciones en tu propio dominio, añade una base de previsualización como `preview.example.com` en la página de Dominios del proyecto; cada rama se servirá entonces también en `.preview.example.com`. ### Servidor Todas las previsualizaciones de un proyecto se ejecutan en un mismo servidor. El primer `-t preview` pregunta cuál, y lo registra bajo `preview` en `.vela/project.json`, junto a `production` y los objetivos con nombre. Cada rama posterior aterriza en la misma máquina, así que sube el archivo al repositorio como de costumbre. Cada previsualización es una instancia completa, de modo que un servidor aloja tantas como memoria tenga. [`vela targets`](/es/targets) muestra esa vinculación compartida como una sola fila `preview` en lugar de una fila por rama. Para ver qué está ejecutándose realmente, pregúntale al servidor: ``` $ vela status --all ``` ### Eliminar una previsualización ``` $ vela destroy deployment -t preview:feature/maps ``` Esto detiene los servicios, borra las releases y retira el nombre de host, que deja de responder en el borde. La base de datos y los archivos subidos permanecen en el servidor salvo que pases `--purge`, que antes de borrarlos guarda una instantánea en la papelera del servidor durante dos semanas; una previsualización es el único objetivo para el que `--yes` basta para purgar. Un pull request cerrado a través de la acción purga. Consulta [`vela destroy deployment`](/es/destroy/deployment). Las previsualizaciones no se podan por antigüedad. Elimínalas a medida que terminen las ramas, o deja que un pull request lo haga por ti. ### Desde pull requests [`velastack/action`](/es/helpers/github-action) despliega `preview:` por cada pull request, mantiene un comentario en el pull request actualizado con la URL, y elimina la previsualización, datos incluidos, cuando el pull request se cierra: ```yaml on: push: branches: [main] pull_request: types: [opened, synchronize, reopened, closed] permissions: contents: read pull-requests: write jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: velastack/action@v1 with: server: root@your-server ssh-key: ${{ secrets.SSH_PRIVATE_KEY }} api-key: ${{ secrets.VELA_API_KEY }} domain: example.com ``` La acción deriva el objetivo del evento: un push a `main` despliega producción, un pull request despliega su rama. `VELA_API_KEY` es lo que da a las previsualizaciones su nombre de host; crea una en [velastack.dev/api-keys/new](https://velastack.dev/api-keys/new). Los pull requests de Dependabot o desde forks se ejecutan sin secretos, así que no reciben previsualización; la [página de la acción](/es/helpers/github-action) muestra cómo saltárselos, y cómo mantener la limpieza en marcha cuando las pruebas de una rama fallan. ### En velastack.dev Cada previsualización aparece en la página de Despliegues del proyecto con su rama, y en la página de Dominios bajo Previsualizaciones, con los nombres de host en los que se sirve. Las previsualizaciones eliminadas desaparecen de la página de Dominios y se conservan en el historial de despliegues.