# Versiones, vuelta atrás y dirección

> El historial de publicaciones de cada app, cómo volver a una versión anterior sin reconstruir, cómo repetir una publicación y cómo elegir tu dirección en dilosite.es.

Cada publicación crea una versión numerada de tu web o tu app. Las anteriores no se pierden: puedes ver el historial, volver a cualquiera de las recientes en segundos y cambiar la dirección pública cuando quieras.

## Ver el historial

<p class="prompt">Enséñame las últimas versiones de la web de la tienda.</p>

El agente usa `deploy.history`, que devuelve las **15 versiones más recientes**: número, estado, fecha, el mensaje con el que se publicó y cuál está en línea. Para el detalle de una (o de la última), `deploy.status`.

> [!TIP]
> Pide a tu agente que ponga un mensaje en cada publicación («nuevo menú de verano», «arreglo del formulario»). Queda en el historial y luego es mucho más fácil saber a qué versión volver.

## Volver a una versión anterior

<p class="prompt">La versión de hoy de la tienda falla. Vuelve a la anterior.</p>

El agente usa `deploy.rollback`. Sin número, vuelve a la anterior a la que está en línea; con `number`, a esa versión concreta.

- **No se reconstruye nada:** se reutiliza lo que ya se construyó para esa versión, así que tarda segundos.
- Solo se puede volver a versiones que llegaron a estar **en línea** (una que falló no). En las apps con servidor se guardan las **10 últimas** construidas.
- Se registra como una versión nueva en el historial, que indica de qué versión viene.
- No se puede si ya hay otra publicación en curso para esa app: hay que esperar a que termine.
- La vuelta atrás afecta al código. **No deshace cambios en la base de datos**: si una migración cambió tablas, para volver a los datos de antes hace falta [restaurar una copia](/docs/datos/copias).

## Volver a publicar la misma versión

<p class="prompt">Vuelve a publicar la app web de la tienda tal como está.</p>

`deploy.redeploy` vuelve a construir y publicar el mismo código de la última versión. Sirve, por ejemplo, después de un fallo pasajero durante el build. Cuenta como una publicación más en el límite diario de tu plan. Para aplicar un cambio de variables no hace falta: ya se aplican reiniciando la app. Ver [Variables y secretos](/docs/publicar/variables).

## Elegir tu dirección en dilosite.es

Por defecto, cada web tiene una dirección del tipo:

```text
https://<app>-<proyecto>-<cuenta>.dilosite.es
```

Puedes cambiarla por un nombre a tu gusto:

<p class="prompt">Quiero que la web de la tienda esté en tiendaana.dilosite.es.</p>

El agente usa `deploy.subdomain` y te pide confirmación, porque **la dirección anterior deja de funcionar** en cuanto se cambia. El cambio es inmediato y el HTTPS ya está cubierto.

### Reglas del nombre

- De **3 a 40** caracteres: minúsculas, números y guiones, sin guion al principio ni al final y sin dos seguidos.
- Tiene que estar **libre**: el primero que lo pide se lo queda mientras la app exista (también mientras está en la papelera).
- No se admiten nombres **reservados** (como `www`, `mail`, `api`, `admin`, `panel`, `login`, `docs`, `blog`, `soporte`…) ni nombres que imiten la forma de las direcciones por defecto.
- Para evitar suplantaciones, no se admiten **marcas ni palabras de engaño**: bancos, tiendas y servicios conocidos, o palabras como `login`, `verificar`, `secure` o `wallet`.

Para volver a la dirección de siempre y liberar el nombre:

<p class="prompt">Devuelve la web de la tienda a su dirección original.</p>

El agente lo hace con `subdomain="default"`, también con confirmación. El nombre queda libre igualmente si la app se borra para siempre.

> [!NOTE]
> Para usar un dominio tuyo, como `mitienda.es`, no cambies el subdominio: conecta el dominio. Ver [Comprar un dominio](/docs/dominios/comprar) o [Traer tu dominio](/docs/dominios/conectar).

## Relacionado

- [Formas de subir el código](/docs/publicar/subir-codigo)
- [Diagnóstico](/docs/publicar/diagnostico)
- [Copias de seguridad](/docs/datos/copias)
- [Confirmaciones](/docs/seguridad/confirmaciones)