Coolify lanzó la versión 4.7.0 con varias novedades centradas en la lógica de despliegues, permisos de API y correcciones en la interfaz de equipos y servidores. La actualización modifica el comportamiento por defecto de las cancelaciones automáticas de despliegues originados por webhooks y añade controles para administradores sobre tokens y envíos de correo reenviado.
Qué cambia en los despliegues webhook
El cambio más relevante afecta a los despliegues iniciados por webhooks: por defecto, Coolify ahora cancela las ejecuciones anteriores en cola de despliegue de una aplicación cuando llega un nuevo push. La anulación se aplica por aplicación, por pull request y por servidor, y puede gestionarse desde la sección Advanced > Deployment o mediante la API de aplicaciones con el campo is_auto_cancel_queued_deployments_enabled.
Este comportamiento no afecta a despliegues iniciados manualmente, por API, reinicios (restart) ni a rollbacks: esos tipos de despliegue nunca son cancelados automáticamente. Además, existe una opción opt-in, is_auto_cancel_building_deployments_enabled en la API, que permite también cancelar despliegues webhook anteriores que ya estén en fase de construcción (building).
En la llamada a la API /api/v1/deploy se puede pasar el parámetro cancel_previous con valores none, queued o building para controlar el efecto sobre ejecuciones previas. La herramienta de despliegue MCP también responde a esta lógica y cancelará despliegues previos iniciados por webhook, API o por MCP cuando proceda. El valor por defecto del sistema para cancel_previous es none.
Permisos y límites en tokens de proveedores cloud
Coolify limita ahora el uso del API token de proveedores en la nube a administradores y propietarios del equipo; los demás miembros recibirán un 403 cuando intenten usar esas credenciales. Adicionalmente, se han aplicado los límites de tokens a más comprobaciones de permisos en la API y se muestra un mensaje explicativo cuando un límite de tokens impide realizar un cambio.
API y campos de reenvío de correo
Se movió el remitente de reenvío a nuevos campos resend_from_address y resend_from_name en la API; los clientes que integren Coolify deberán usar esos campos nuevos. Para evitar pérdida de valores, la actualización incluye una migración que copia los valores actuales a las nuevas propiedades.
Mejoras en la gestión de equipos y servidores
Coolify ajusta la construcción de enlaces de invitación a equipos: si no hay un dominio de instancia configurado, los enlaces ahora se generan a partir de la URL de la instancia en lugar del host de la petición. También hubo comprobaciones adicionales para garantizar que los miembros con permisos (access grants) realmente puedan usar el servidor y las credenciales del equipo seleccionadas.
Además, cuando se crea, clona o migra un recurso, la plataforma exige que exista un servidor que el miembro pueda usar; en el caso del servidor localhost, hace falta un administrador de instancia. Las listas de servidores que ve cada miembro se filtran para mostrar únicamente los servidores a los que el miembro tiene acceso.
Qué deben hacer los administradores y responsables de aplicaciones
- Revisar la configuración Advanced > Deployment de cada aplicación y la API para comprobar el valor de is_auto_cancel_queued_deployments_enabled y, si interesa, activar is_auto_cancel_building_deployments_enabled para evitar acumulación de builds.
- Actualizar integraciones y clientes que usen la API para leer/escribir resend_from_address y resend_from_name en lugar de los campos anteriores.
- Comprobar permisos de equipo: solo administradores y owners podrán manipular tokens de proveedores cloud; ajustar permisos de miembros si es necesario.
- Verificar que los miembros tienen acceso a los servidores necesarios antes de clonar o migrar recursos, y confirmar si el servidor localhost requiere un administrador de instancia.
La nota de la versión también incluye otras correcciones menores y comprobaciones adicionales en la API relacionadas con límites de tokens y uso de servidores por parte de miembros, pensadas para mejorar la coherencia de permisos y evitar errores durante operaciones administradas por equipos.
Lee también:
- CachyOS ya disponible en Windows Subsystem for Linux (WSL) con soporte oficial
- Pruebas iniciales de una alternativa local y gratuita a Claude Code muestran resultados prometedores
Fuente: Release notes from coolify
