Vercel CLI: proyectos que se autoborran al expirar

Vercel añadió a su CLI la capacidad de crear proyectos con fecha de caducidad: vercel deploy --delete-project-after 1d deja un proyecto programado para borrarse automáticamente al día siguiente. La función apunta a uno de los desórdenes más silenciosos del desarrollo moderno: los prototipos, demos y apps de prueba que nadie limpia a mano.

El detalle fino está en cuándo aplica y cuándo no. Si tu equipo despliega a diario desde un pipeline, esa distinción es la que decide si la función te sirve.

¿Qué hace exactamente el flag –delete-project-after?

Al ejecutar vercel deploy --delete-project-after 1d, el proyecto que se crea en ese despliegue queda marcado para eliminarse cuando se cumpla el plazo. La duración admite cinco formatos: 1h, 1d, 1w, 2w y 30d. Después del despliegue, la propia línea de comandos imprime la fecha y hora exactas de expiración, así que no hay ambigüedad sobre cuándo desaparecerá el entorno.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El punto crítico: el flag solo aplica cuando vercel deploy crea el proyecto. Si se ejecuta contra un proyecto que ya existe, su expiración no cambia y el CLI imprime una advertencia. No es una herramienta de limpieza retroactiva, sino una política que se define en el momento en que el proyecto nace.

Para revertirla existe un comando específico: vercel project keep mi-proyecto elimina la expiración. Es el caso típico del demo que pasó a ser producto: en lugar de recrear el proyecto, se lo marca como permanente. Todo esto requiere el CLI en la versión v65.12.0 o posterior (docs de Vercel, changelog de noviembre).

¿Por qué este problema merecía una función propia?

El desorden de proyectos es un clásico en equipos que despliegan seguido. Cada prueba técnica, cada demo comercial, cada experimento con una librería nueva termina como un proyecto más en la cuenta. Nadie los borra, porque borrar nunca entra en el sprint.

El costo de esa acumulación rara vez aparece como una factura grande y visible. Aparece como cuota consumida, como listas interminables en el dashboard y como ruido cuando hay que averiguar cuál es el proyecto que realmente atiende a los usuarios. En plataformas que cobran por uso, un entorno olvidado sigue vivo y sigue sumando al consumo hasta que alguien lo apaga.

Y hay un agravante: en muchos equipos la limpieza manual nunca ocurre porque el proyecto no lo creó una persona, lo creó un pipeline. Ahí es justamente donde una expiración definida en el momento del despliegue es la única política realista.

¿Qué cambia para un equipo que despliega desde CI/CD?

El flujo central de la plataforma sigue siendo el mismo que describe el repositorio oficial del proyecto: importar un proyecto, hacer git push y desplegar, con el CLI como vía alternativa que se instala con npm i -g vercel y que también se distribuye como binarios nativos. Eso significa que este flag se puede inyectar exactamente donde nace el desorden: en los scripts de despliegue.

La advertencia que imprime el CLI cuando el proyecto ya existe es más útil de lo que parece. Convierte un error silencioso en un mensaje explícito: si tu pipeline cree que está creando entornos efímeros y en realidad está redeployando un proyecto permanente, lo vas a ver en el log en lugar de descubrirlo meses después, cuando alguien pregunte por qué la cuenta tiene noventa proyectos.

También obliga a una decisión de arquitectura que muchos equipos postergan: qué es efímero y qué no lo es. Antes esa decisión se tomaba (o no se tomaba) después, con una limpieza manual que nadie hacía. Ahora se toma en el deploy.

¿Qué proyectos conviene dejar expirar automáticamente?

Demos comerciales con fecha conocida: un 1d o 1w cubre la reunión y las revisones posteriores sin dejar residuos.
Pruebas de concepto técnicas: cuando evalúas un framework, una librería o un proveedor, el 1d evita que el experimento se vuelva permanente por inercia.
Entornos de validación con cliente: 1w o 2w dan margen a la ronda de feedback sin comprometer el proyecto a largo plazo.
Sandboxes de agentes que escriben y despliegan código: cualquier flujo donde un agente de IA genere un despliegue necesita una caducidad corta por defecto, porque nadie va a revisar esa lista a mano.
Proyectos que sí importan: no los dejes al azar. Marca con vercel project keep los que deben vivir para siempre y reserva la expiración para todo lo demás.

¿Qué significa esto para tu startup?

La función es pequeña, pero resuelve algo que en equipos chicos se paga en tiempo y en claridad mental. Estas son las acciones que valen la pena esta semana:

Sube el CLI a v65.12.0 o superior y pínalo en tu pipeline. Si tu CI usa una versión anterior, el flag simplemente no existe y seguirás acumulando proyectos sin darte cuenta.
Estandariza la expiración en tus scripts de demo. Si tu equipo crea entornos temporales varias veces por semana, define la duración en el propio comando en lugar de confiar en que alguien recuerde borrarlos.
Define una política de retención por tipo de proyecto. Un día para experimentos, una semana para demos, dos semanas para validaciones con cliente. Escríbela y automatízala, no la dejes a criterio de cada persona.
No cuentes con el flag para limpiar lo que ya existe. Solo actúa sobre proyectos nuevos. Para el pasado, la limpieza sigue siendo manual o vía la API de la plataforma.

Conclusión

--delete-project-after es una de esas mejoras que no cambian lo que puedes construir, pero sí cómo se mantiene ordenado lo que ya construiste. La lección transferible a cualquier stack: si un recurso se crea de forma automática, su destrucción también tiene que ser automática. Dejarlo para después es lo que termina generando cuentas con decenas de entornos zombis que nadie se anima a borrar.

No se encontraron datos adicionales verificables de terceros sobre esta función en el research de esta ejecución; el resto de la información proviene del changelog oficial de Vercel y del repositorio del proyecto.