Coolify 4.6.0 : pourquoi vos scripts ne peuvent plus supprimer avec un jeton d'écriture

Un script de déploiement appelle l'API de Coolify avec un jeton. Il crée, met à jour, et nettoie après lui. Après la mise à jour vers la version 4.6.0, publiée le 2 novembre 2026, la partie "nettoie" peut se mettre à échouer. Les notes de version l'annoncent comme un changement cassant, et il vaut mieux le savoir avant de cliquer sur "mettre à jour".

Qu'est-ce qui change pour les jetons d'API ?

Jusqu'ici, un jeton avec le droit write pouvait aussi supprimer. Ce n'est plus le cas : il faut désormais le droit delete (ou root) pour toute suppression, par l'API comme par le serveur MCP. Sont concernés les ressources, les variables d'environnement, les stockages, les sauvegardes, les tâches planifiées et les tags (y compris le fait de détacher un tag).

Cette règle s'inscrit dans un système de droits plus fin. Les membres comme les jetons peuvent être limités à certains projets, environnements ou ressources, avec les niveaux read, read sensitive, deploy, write, delete et root. Quatre préréglages sont proposés : viewer, developer, operator et full access.

Que disait la règle jusqu'ici ?

La page de documentation des jetons que nous avons lue décrit encore l'ancien modèle (elle n'a peut-être pas été mise à jour pour la 4.6) :

• read pour consulter, read:sensitive pour les secrets, journaux et variables d'environnement ;
• write pour créer, modifier et supprimer : il n'y avait pas de droit delete distinct ;
• deploy pour déclencher déploiements, redémarrages et arrêts ;
• root pour contourner les vérifications, réservé aux administrateurs de l'équipe.

Le seul périmètre documenté était l'équipe. La 4.6.0 ajoute la possibilité de restreindre un jeton ou un membre à des projets, des environnements ou des ressources.

Les bonnes pratiques de cette même page restent valables : traiter le jeton comme un mot de passe (gestionnaire de secrets, jamais dans le dépôt), choisir une expiration courte, et restreindre les appels à vos adresses IP avec le réglage "Allowed API IPs" quand elles sont connues. Pour faire tourner un jeton : créer le remplaçant, le tester, révoquer l'ancien, puis vérifier qu'il renvoie bien une erreur 401. Coolify peut aussi vous prévenir avant l'expiration d'un jeton.

Que faire de vos jetons avant la mise à jour ?

1. Faites l'inventaire de vos jetons (scripts de déploiement, intégration continue, assistants IA) et notez ce que chacun fait.
2. Repérez ceux qui suppriment quelque chose : nettoyage d'environnements de test, retrait d'une variable, suppression d'une sauvegarde.
3. Donnez le droit delete à ceux-là seulement. Les autres restent en deploy ou write.
4. Évitez root pour un usage courant : c'est le droit le plus large.

À notre avis, c'est surtout l'occasion de découper vos jetons par usage : un jeton qui déploie, un autre qui nettoie, plutôt qu'un seul jeton tout-puissant partagé par tous les scripts.

Que veut dire "durcissement de la CI" ?

Une partie de la version concerne la chaîne de fabrication de Coolify lui-même, et c'est instructif pour vos propres projets. D'après les notes de version :

• chaque action GitHub doit être épinglée à un identifiant de commit complet, et un réglage GitHub l'impose ;
• un fichier .github/workflows/actions.lock verrouille les actions et leurs dépendances ;
• chaque tâche reçoit les permissions minimales, et toute permission d'écriture doit être justifiée ;
• les identifiants Docker Hub et le jeton du CDN sont placés dans un environnement release ;
• les caches de la CI sont supprimés.

L'idée est de limiter ce qui peut arriver si une action tierce est compromise. Rien à faire de votre côté pour utiliser Coolify, mais c'est une bonne liste de contrôle pour vos propres workflows.

GitHub propose d'ailleurs lui-même, depuis août 2025, une politique qui permet d'exiger que chaque action soit référencée par un identifiant de commit complet (pour qu'un code malveillant ajouté à une branche ou à un tag ne soit pas utilisé automatiquement) et de bloquer une action ou une version précise en cas de problème. Elle se règle au niveau de l'entreprise, de l'organisation ou du dépôt.

Quels autres points surveiller avant de mettre à jour ?

L'image de Coolify est maintenant compressée en zstd : le téléchargement demande au moins Docker Engine 23.0, et Coolify exige désormais la version 24.0. Vérifiez la vôtre :

docker version --format '{{.Server.Version}}'

Parmi les autres changements cités : le support de Docker Desktop sous Windows est supprimé, les tags d'image next et sha-<commit> aussi, et l'API HTTP de Reverb n'est plus exposée sous /apps par Traefik et Caddy (seul le chemin WebSocket /app/ passe). Une correction bienvenue : les valeurs racine contenant des espaces sont maintenant correctement mises entre guillemets dans le fichier .env, ce qui évitait une erreur 500 sur toutes les pages.

Nous utilisons Coolify pour nos propres applications. Comme pour toute mise à jour d'outil d'hébergement, relisez les notes de version avant de lancer, et gardez une sauvegarde récente. Pour la partie hébergement, voir notre page hébergement et maintenance.

Questions fréquentes