Coolify lanzó la actualización v4.5.1, que introduce varias modificaciones enfocadas en la estabilidad de eliminación de servicios, mejoras en la experiencia de administración y nuevas opciones visuales y de monitorización. La versión incluye tanto cambios que rompen compatibilidad en la API como funciones pensadas para despliegues self‑hosted y ajustes de usabilidad para administradores y desarrolladores.
Qué cambia y a quién afecta
Entre los cambios que afectan a la gestión de servicios, Coolify ha eliminado la opción «Remove from Coolify only» al borrar un servicio. Ahora, un borrado normal funcionará incluso si el servidor está inalcanzable; la API rechazará peticiones que intenten usar el parámetro delete_from_coolify_only con un error 422. Esto implica que integraciones o scripts que dependieran de la antigua opción necesitarán actualizarse para usar el flujo estándar de eliminación.
También se suprimió el servicio de log drain denominado Highlight, ya que el servicio terminó. Además, Coolify detiene los contenedores que estuvieran en ejecución al eliminar servicios, lo que puede cambiar el comportamiento esperado en entornos donde se contaba con procesos externos que seguían consumiendo recursos tras la eliminación.
Seguridad y control para equipos (self‑hosted)
Para instalaciones self‑hosted, la actualización introduce dos controles importantes: limitar la ventana de registro del primer usuario root a los diez minutos posteriores al arranque de Coolify y permitir que los propietarios y administradores de equipo exijan el uso de 2FA para todos los miembros del equipo. El primer cambio reduce la ventana de oportunidad para creación no autorizada del primer administrador tras un reinicio; para abrir otra ventana hay que reiniciar Coolify. El segundo ofrece una medida de seguridad adicional para organizaciones que gestionan proyectos y despliegues colaborativos.
Optimización de builds y directivas para desarrolladores
Coolify ahora omite la construcción (Compose image build) cuando las imágenes coinciden con las entradas de build, de modo que cambios que solo afectan al runtime no vuelven a desencadenar builds innecesarios. En la vista de variables de entorno para desarrolladores se añadieron directivas con la etiqueta # coolify: (literal, buildtime, runtime), que permiten marcar variables según su tratamiento en tiempo de construcción o ejecución. Estas mejoras reducen tiempo y recursos en pipelines y aclaran el propósito de cada variable.
Interfaz, temas y experiencia del administrador
La versión incorpora un diálogo de tema personalizado con cuatro colores, presets y códigos para compartir temas; un reordenado del dashboard; y la capacidad de arrastrar zonas de proyecto y servidor en los lienzos. En la tabla de servidores se muestra CPU y memoria en vivo, y las gráficas de métricas sincronizan tooltips entre sí, con opción de mostrar las horas en local o en UTC. También se añadió un conmutador de actualización en vivo para cada rango de métricas y analítica, y métricas de tráfico compactas con unidades de latencia escaladas.
Otros ajustes de usabilidad incluyen reemplazar los spinners numéricos nativos por un stepper con estilo propio, mover el selector de contenedor del explorador de archivos a un desplegable en el encabezado, y añadir una opción «Use path-style URLs» para almacenamientos S3 que requieren URLs con estilo path en lugar de virtual‑hosted.
Estabilidad en despliegues y mejoras operativas
La actualización busca reducir errores 502 durante actualizaciones rolling mediante reintentos en el proxy y un tiempo de drenaje configurable. También se registran mejoras en las métricas (por ejemplo, sincronización de tooltips y compactación de métricas de tráfico) y en la lógica de builds para evitar reconstrucciones innecesarias.
Qué deben hacer administradores y dueños de sitios
- Revisar y, si procede, adaptar integraciones o scripts que usen la opción delete_from_coolify_only, ya que la API la rechazará y el flujo de borrado ha cambiado.
- Si usan la integración Highlight para logs, buscar una alternativa: el servicio fue retirado.
- En instalaciones self‑hosted, planificar el reinicio de Coolify si es necesario permitir registrar el primer root account fuera de la ventana inicial de diez minutos.
- Valorar imponer 2FA para equipos si se requiere mayor seguridad operativa.
- Comprobar las políticas de build y las directivas # coolify: para optimizar pipelines y evitar builds innecesarios.
En resumen, v4.5.1 de Coolify aporta mejoras prácticas en monitorización, experiencia de administración y eficiencia de builds, además de ajustar comportamientos en la eliminación de servicios y opciones de seguridad para instalaciones self‑hosted. Los responsables de infraestructuras deberán revisar integraciones y políticas de seguridad para aprovechar los cambios y evitar interrupciones.
Lee también:
- RefreshOS 3.1: Debian 13.7, repositorio APT propio y soporte i386 para juegos
- KMSCON 10.1 añade configuraciones por monitor y mejoras para terminales DRM/KMS
Fuente: Release notes from coolify
