Write is not delete: Coolify just changed your API and MCP contract

If your Coolify token still has only write, it can no longer delete a backup, a variable or a resource. That is not a bug.

I run apps on Coolify, and I automate deploys. These two releases change the contract of that automation: 4.6.0 on 2 November 2026, and 4.7.0 on 9 November 2026. The later 4.7.1, 4.7.2 and 4.7.3 patches, also on 9 November, do not change these defaults.

This sits after the earlier posts in Self-Hosting SaaS with Coolify. You already have the control plane. Now the API and the MCP tools have stricter abilities, and the webhook queue behaves differently.

Write used to mean “do anything.” It does not anymore.

Coolify 4.6 is a breaking change for tokens.

The 4.6.0 release notes say it plainly: every delete through the API and the MCP server now requires the new delete ability, or root. A token with write alone can no longer delete resources, environment variables, storages, backups, scheduled tasks or tags, or detach a tag.

That is the point. A deploy bot should not be able to erase a backup.

The same release lets you limit a team member or an API token to selected projects, environments or resources. The access levels are read, read sensitive, deploy, write, delete and root. A higher level includes the lower ones. A token never gets more access than its owner, and it stops working when its owner loses that access.

So the useful split is now real. Give CI and an MCP client deploy if that is all they should do. Keep write for bots that change settings. Add delete only where a bot must actually delete something.

A newer push now cancels the older queued webhook deploy.

Coolify 4.7 changes the queue.

The 4.7.0 release notes say older queued webhook deployments of an application are cancelled by default when a newer push arrives, so only the latest commit is built. It works per application, pull request and server.

This is the new default for webhook deploys. You can turn it off under Advanced > Deployment, or with is_auto_cancel_queued_deployments_enabled in the applications API.

Manual, API, restart and rollback deployments are never cancelled by that default.

On /api/v1/deploy and the MCP deploy tool, there is a separate cancel_previous argument: none, queued or building. The default is none. So an API or MCP deploy does not auto-cancel older work unless you ask it to.

There is also an opt-in setting, is_auto_cancel_building_deployments_enabled in the API, that can stop an older webhook deploy that is still building. A deploy that has already started to replace containers always finishes.

One more MCP fix in the same notes: two deploys of one application, started from the MCP deploy tool or the MCP control start action, used to run at once and could stop the application. They now queue behind a deployment in progress, the same way the API and the Deploy button already did. A deploy of the same commit is skipped, and the response gives the UUID of the deployment in progress (issue 12442).

Scope the token, then roll it.

Once the abilities are right, 4.6 also gives you a safer way to replace a secret.

You can edit the description, permissions, access and expiry of an API token without changing its value. You can pause and resume a token: a paused token cannot authenticate to the API or the MCP server. You can roll a token to replace its secret and keep its description, permissions, access and expiry. A new or rolled token is shown in a modal until you close it. Expiry warnings now come 7 days ahead, or 1 day ahead if the token lives 7 days or less. All of that is in the 4.6.0 notes.

Which of your Coolify tokens still has write when all it does is deploy?