Crear es la parte fotogénica. El trabajo adulto comienza cuando cada artefacto recibe un plazo, un responsable, protección y una forma segura de salir de escena.

TL;DR

Automatizar la creación sin automatizar el ciclo de vida transfiere costo, riesgo y confusión al futuro. Las imágenes de contenedores, los previews, las ramas temporales de trabajo, los artefactos de compilación y las copias de seguridad no deberían existir para siempre solo porque nadie definió su final. Una limpieza segura no consiste en borrar todo lo que parece viejo: exige consultar una fuente de verdad, proteger producción, mantener un camino de vuelta a una versión que ya funcionaba — el rollback —, aplicar una política de retención, simular antes de eliminar, pedir evidencia de desuso y preservar una ruta de recuperación. Si la automatización no sabe distinguir memoria operativa de abandono, todavía no está completa.

Hoy volví a encontrar una escena que no tiene nada de rara en tecnología.

Una operación seguía pagando por almacenar imágenes de software que no se utilizaban desde hacía más de cinco años.

No porque alguien hubiera decidido preservar cinco años de historia. No porque existiera un requisito de auditoría, una ventana de recuperación o una versión antigua que todavía pudiera salvar producción.

Seguían allí porque nadie podía afirmar, con seguridad, qué se podía borrar.

Así que nadie borraba nada.

Es una forma curiosa de gobernanza: la duda se convierte en política de retención y la factura, en documentación.

La cadena de entrega se automatizó. El almacén, no

Somos muy buenos automatizando comienzos.

Un nuevo cambio versionado —un commit— dispara una compilación automatizada, o build. La compilación genera un paquete. El paquete se convierte en una imagen. La imagen recibe una etiqueta, o tag: un nombre como 1.4 o latest que referencia su manifest en el registro de imágenes. La versión temporal obtiene una dirección para evaluación, el preview. La prueba produce informe, registro de ejecución —el log—, copias temporales para acelerar la siguiente ejecución —la caché— y otros artefactos. Todo sucede en minutos, a veces en segundos.

Después el trabajo termina — para nosotros.

Para la infraestructura, apenas comenzó a ocupar espacio.

Cada ejecución exitosa deja algo atrás. Un solo sobrante parece irrelevante. Miles de ellos, acumulados durante años, empiezan a consumir almacenamiento, dificultar el inventario, conservar componentes que quizá deberían retirarse por seguridad y volver mucho más aterradora cualquier limpieza futura.

El problema aparece porque tratamos la creación como flujo y el descarte como una jornada de limpieza.

Pero la limpieza operativa, muchas veces llamada cleanup, no debería ser el operativo incómodo que organizamos cuando se llena el disco. Debería formar parte del mismo ciclo de vida que autorizó al artefacto a existir.

Si una automatización sabe crear diez versiones al día, pero no sabe cuándo nueve de ellas dejan de tener una función, no eliminó trabajo.

Mandó la factura al futuro, con intereses cobrados en contexto perdido.

Viejo no es sinónimo de inútil

La respuesta perezosa sería elegir una edad y borrar todo lo que la supere.

Sería rápido. También sería una manera eficiente de descubrir, demasiado tarde, que la versión “vieja” era la última versión funcional disponible para rollback, que una sucursal todavía dependía de ella o que la copia de seguridad guardada con tanto cariño no restauraba nada.

La edad es una señal. No es una decisión.

La retención puede ser necesaria por motivos diferentes:

• continuidad: conservar la versión en producción y algunas versiones que hayan demostrado servir para volver atrás;
• trazabilidad: preservar el artefacto vinculado a una entrega, un incidente o una decisión que todavía debe auditarse;
• obligación: cumplir una regla legal, contractual o interna con plazo y responsable definidos;
• recuperación: guardar datos y configuración mientras una restauración siga teniendo sentido;
• investigación: conservar evidencia mientras una falla o un incidente permanezcan abiertos.

Eso es retención.

Otra cosa es encontrar cientos de versiones sin consumidor conocido, responsable, fecha de vencimiento o prueba de que alguien podría utilizarlas.

Eso no es memoria institucional.

Es abandono con redundancia geográfica.

La imagen de un contenedor no es una caja aislada

Cuando hablo de imágenes, no me refiero a fotografías. Una imagen de contenedor es el paquete reproducible que permite iniciar una aplicación junto con sus dependencias y su configuración de sistema.

Tampoco es necesariamente un bloque independiente.

La especificación de Open Container Initiative (OCI) llama manifest al descriptor que apunta a la configuración de la imagen y a sus bloques reutilizables de contenido, llamados capas. Varias versiones pueden compartir capas idénticas. Por eso, eliminar una etiqueta no libera automáticamente todos los bytes que un panel parecía atribuirle a esa versión.

En un registro operado con Distribution —software abierto de la Cloud Native Computing Foundation (CNCF) para almacenar y distribuir imágenes de contenedores—, la recolección de objetos sin referencia (garbage collection) elimina bloques que ya no están vinculados a ningún manifest. La documentación oficial ofrece una simulación (dry-run) precisamente para mostrar qué sería elegible antes de eliminar datos.

Sin embargo, esa simulación no vuelve segura la ejecución real mientras el registro sigue recibiendo datos. Distribution exige que el registro esté en modo de solo lectura o completamente detenido durante la recolección: una carga concurrente puede perder capas por error y terminar como una imagen corrupta. Primero se interrumpen las escrituras; después se recolecta. Invertir el orden es hacer una copia de seguridad de la esperanza y llamarla procedimiento.

Esa diferencia técnica refuerza una idea mayor:

“Parece no tener uso” y “puede eliminarse con seguridad” no son la misma frase.

El propio Docker adopta una limpieza conservadora: los objetos sin uso no desaparecen automáticamente, y el alcance de los comandos de prune cambia según las opciones elegidas. La cautela de la herramienta no sustituye la política de la empresa. Solo evita que una configuración agresiva tome una decisión que la infraestructura no puede comprender por sí sola.

Escribir un comando con --force —que, en este comando de Docker, solo omite la confirmación— no crea contexto.

Solo elimina la última oportunidad de que la herramienta pregunte si alguien pensó antes.

La misma basura recibe nombres diferentes

Las imágenes de contenedores vuelven visible el problema porque el almacenamiento aparece en la factura. Pero la misma falta de ciclo de vida se extiende por toda la operación:

• previews de evaluación: cada versión candidata recibe una dirección temporal, incluso después de cerrar el cambio;
• ramas: versiones de trabajo separadas permanecen en el repositorio después de incorporar o abandonar una decisión;
• artefactos de compilación: paquetes, informes, registros y resultados intermedios sobreviven mucho más allá de su utilidad;
• cachés: aceleran el siguiente trabajo hasta convertirse en una colección costosa de pasados que nunca volverán;
• entornos temporales: nacen para una prueba de dos días y descubren la inmortalidad administrativa;
• copias de seguridad: acumulan copias sin clasificación, prueba de restauración, plazo o relación clara con el sistema actual.

GitHub permite definir períodos de retención para artefactos producidos por flujos automatizados (workflows) y borrar automáticamente ramas cuyos cambios ya fueron incorporados. Cloudflare Pages documenta cómo eliminar previews antiguos y preserva la implantación más reciente asociada a una rama.

Las herramientas ofrecen mecanismos.

Ninguna conoce por sí sola la política completa de tu operación.

Un preview antiguo puede ser basura. También puede ser el entorno de evaluación de un cambio todavía abierto y vinculado a una rama. Una rama asociada a un cambio cerrado puede ser descartable. También puede servir como base de otro cambio. La copia de seguridad de ayer puede ser suficiente. También puede haber copiado perfectamente la corrupción de anteayer.

Por eso, borrar por edad sin consultar el estado real es cambiar acumulación por ruleta rusa.

Primero encuentra la fuente de verdad

Antes de construir la escoba, necesito saber dónde vive la verdad operativa.

¿Qué imagen está realmente desplegada? ¿Qué versiones de producción existen? ¿Qué cambios o solicitudes de incorporación siguen abiertos y qué ramas están asociadas a ellos? ¿Qué preview representa a cada cambio? ¿Qué paquetes se publicaron como releases? ¿Cuáles de esas versiones todavía reciben soporte? ¿Qué restauración fue probada? ¿Existe una retención legal? ¿Hay un incidente preservando evidencia?

Esas respuestas rara vez viven en el mismo lugar.

El error común consiste en nombrar juez universal a un panel aislado. El registro de imágenes sabe qué versiones almacena, pero puede ignorar qué está ejecutándose en otro entorno. El proveedor de previews conoce las implantaciones (deployments), pero no necesariamente el estado de la evaluación. El repositorio conoce sus ramas, pero no a todos los consumidores de una imagen.

Una rutina segura necesita combinar esas fuentes.

Si no puede confirmar qué está activo, protegido o todavía en evaluación, debe fallar de forma segura: CWE-636 es una entrada de la Common Weakness Enumeration, el catálogo de MITRE para clasificar debilidades de software; en este contexto, el principio significa no borrar nada y explicar qué evidencia falta, en lugar de suponer que la ausencia de datos autoriza la eliminación.

La molestia de revisar un informe es menor que la elegancia de automatizar un desastre.

El contrato de una limpieza en la que confío

No confío en una rutina de cleanup porque tenga una programación automática —una tarea cron estandarizada por la familia POSIX (Portable Operating System Interface)— bonita o porque haya liberado mucho espacio en una prueba.

Confío cuando puede responder estas preguntas:

1. ¿Quién es responsable? Alguien responde por la política, las excepciones y la revisión periódica.
2. ¿Cuál es la fuente de verdad? Producción, versiones soportadas, cambios abiertos y retenciones obligatorias se descubren en sistemas definidos.
3. ¿Qué está protegido? Producción, la última versión funcional conocida, la configuración y los artefactos necesarios para volver a ella, las releases mantenidas y la evidencia retenida forman un conjunto que no depende solo de la edad.
4. ¿Cuál es la ventana de retención? Cada clase tiene su propio plazo. Un preview no necesita seguir la misma regla que una copia de seguridad; un log no necesita imitar una release.
5. ¿Existe evidencia de desuso? La ausencia de una referencia, una implantación, una rama existente o un consumidor pesa más que “hace tiempo”.
6. ¿La primera ejecución es una simulación? La rutina enumera qué eliminaría, según qué regla y con qué impacto estimado antes de tocar datos.
7. ¿El impacto está limitado? Cantidades máximas, edad mínima, ejecución por lotes y pausa ante divergencias evitan que una falla barra todo de una vez.
8. ¿Existe un camino de regreso? Cuando la plataforma ofrece restauración, la ventana debe conocerse. Cuando no la ofrece, el conjunto protegido debe bastar para reconstruir.
9. ¿Deja un rastro? La ejecución registra regla, identificador, motivo, horario y resultado sin volcar secretos en los logs.
10. ¿La política es reutilizable? Cuando varios proyectos comparten proveedor y protecciones, la lógica debería vivir en un flujo central, probado y versionado, en lugar de ganar copias divergentes.

GitHub llama a esa última capacidad workflow reutilizable: un flujo central puede ser llamado por varios repositorios, reduciendo duplicación y concentrando el mantenimiento. Reutilizar no significa fingir que todos los proyectos son iguales. Significa centralizar la lógica común y convertir las diferencias en entradas explícitas.

Una buena política también empieza con poco.

Primero, inventario. Después, simulación. Luego, la eliminación de una clase de bajo riesgo, la observación del resultado y solo entonces la ampliación del alcance.

Eso es menos cinematográfico que ejecutar “limpiar todo”.

También es bastante mejor para quien desea conservar su empleo a la mañana siguiente.

Una copia de seguridad sin ciclo de vida también puede convertirse en acumulación

Yo defiendo las copias de seguridad. Ya escribí que el backup es método y libertad para preservar opciones.

Pero “guardar todo para siempre” no es una estrategia de recuperación.

Un conjunto de copias de seguridad debe indicar:

• qué fue copiado;
• con qué frecuencia;
• cuánto tiempo permanece cada clase;
• dónde existe una copia independiente;
• cómo se prueban la integridad y la restauración;
• qué claves, configuración y documentación exige la recuperación;
• cuándo una retención especial impide el descarte normal.

Sin eso, las copias de seguridad pueden ocupar espacio indefinidamente y aun así fallar en el único momento que importa.

La distinción es simple: la retención preserva una capacidad conocida; la acumulación preserva una duda.

El ciclo de vida forma parte de la entrega

Durante mucho tiempo tratamos la eliminación como un tema secundario. El buen equipo sería el que pone cosas en producción. La retirada quedaría para cuando alguien tuviera tiempo, el almacenamiento se quejara o una auditoría preguntara por qué todavía existía aquello que todos juraban haber borrado.

Esa visión está incompleta.

Entregar un sistema también significa saber actualizar, observar, recuperar, retirar y eliminar sus artefactos. Haber recorrido la cadena completa —requisitos, arquitectura, implementación, infraestructura, monitoreo, seguridad, backup y continuidad— me enseñó a desconfiar de soluciones que solo muestran el nacimiento.

En i-9.ai, ese cuidado se convierte en contrato operativo: qué puede crear la automatización, cómo comprobamos que todavía cumple una función, quién decide su retención y bajo qué condiciones puede salir sin llevarse producción consigo.

No es una obsesión por borrar.

Es lo contrario: saber por qué cada cosa continúa existiendo.

Porque si toda cadena automatizada —todo pipeline— termina en “guardar para ver después”, el futuro deja de ser una dirección.

Se convierte en un almacén.

Y un almacén sin inventario es apenas una factura con pasillos.

Para profundizar

Documentación oficial consultada el 30 de agosto de 2026:

• Open Container Initiative — Image Manifest Specification: estructura técnica de manifests, configuración y capas de una imagen.
• Open Container Initiative — Distribution Specification: define cómo las tags con nombre referencian manifests en un registro; no determina la política de retención de una empresa.
• Git — git commit: cómo un cambio versionado registra el historial del repositorio.
• GitHub Actions — Dependency caching: diferencia entre cachés reutilizables y artefactos conservados después de una ejecución, incluidos binarios construidos y logs de build.
• Docker Docs — Prune unused Docker objects: mecanismos y diferencias de alcance para limpiar objetos Docker sin uso.
• Cloud Native Computing Foundation (CNCF) Distribution — Garbage collection: marcado de referencias, objetos elegibles, modo de simulación y la obligación de impedir escrituras durante la recolección para evitar imágenes corruptas.
• The Open Group — crontab: una especificación de la familia POSIX (Portable Operating System Interface), conjunto de estándares para interfaces portables de sistemas operativos, aplicada a trabajos periódicos en segundo plano.
• MITRE — CWE-636: Not Failing Securely: entrada 636 de la Common Weakness Enumeration (CWE), catálogo de debilidades de software mantenido por MITRE; explica el riesgo de que una falla lleve al sistema a un estado menos seguro.
• Ubuntu — Ciclo de versiones: ejemplo concreto de versiones publicadas con ventanas de soporte diferentes, mostrando por qué «publicada» y «todavía soportada» son estados separados.
• Amazon Web Services (AWS) CodeDeploy — Redeploy and roll back a deployment: un ejemplo concreto de regreso a una revisión de la aplicación que ya funcionaba.
• GitHub Docs — Reusing workflow configurations: cómo centralizar lógica repetible en workflows reutilizables.
• Cloudflare Pages — Preview deployments: ciclo de previews, direcciones vinculadas a ramas y eliminación de implantaciones antiguas.

Referencias y límites de uso

• La documentación de Docker sustenta que los objetos sin uso no se eliminan automáticamente y explica el alcance de los comandos de prune. No define qué retención es adecuada para una empresa específica.
• Las documentaciones de Git y GitHub Actions sustentan el vocabulario de commit, artefacto, log y caché en sus respectivos ecosistemas. No definen el ciclo de vida de todas las herramientas de construcción y publicación.
• La especificación OCI y la documentación de Distribution sustentan la relación entre manifests, capas referenciadas y recolección de objetos sin referencia en este software de registro, incluido el riesgo de corrupción durante cargas concurrentes. Otros registros pueden implementar eliminación, retención y restauración de manera diferente.
• La especificación POSIX sustenta el significado de una tarea cron; no vuelve seguro el trabajo programado.
• CWE-636 sustenta el principio general de no pasar a un estado menos seguro ante una falla. Aplicarlo al cleanup —rechazar la eliminación cuando falta evidencia— es la síntesis operativa del artículo.
• El ciclo de Ubuntu ilustra que publicación y soporte tienen fechas y estados diferentes. No define la política de ciclo de vida de todos los productos.
• La documentación de AWS CodeDeploy sustenta el ejemplo de volver a una revisión de la aplicación que ya funcionaba. No define un comportamiento universal: el alcance y la forma de recuperación varían según la plataforma.
• La documentación de GitHub sustenta la configuración de retención de artefactos, la eliminación automática de ramas asociadas a cambios incorporados y la reutilización de workflows. No demuestra ahorro ni garantiza que una regla genérica reconozca a todos los consumidores externos.
• La documentación de Cloudflare sustenta el comportamiento y la eliminación de previews de Pages. El ejemplo no autoriza borrar una evaluación cuya rama o función operativa siga activa.
• El caso de artefactos conservados durante más de cinco años es una percepción autoral anonimizada. Ilustra la ausencia de ciclo de vida; no demuestra costo promedio, desperdicio universal ni retorno financiero de una rutina de cleanup.

Seguir leyendo

• Especialista en IA desde anteayer
• Escribió, no leyó: la IA no firma por ti
• Tu empresa no necesita descubrir dónde poner IA