2026-08-31

The Coolify buildkit freeze after a Docker upgrade, and the fix

A Docker upgrade broke every Dockerfile-pack deploy on my Coolify server. Here is the exact error, the workaround that kept shipping, and the fix that actually resolved it.

After upgrading Docker to 29.4 on my Coolify server, every application on the dockerfile build pack stopped deploying. Nixpacks apps and compose apps kept building fine. Anything on a raw Dockerfile died in the build_image step.

The error was:

DOCKER_BUILDKIT=1 docker build --network 'coolify' ...
# network mode coolify not supported by buildkit

Coolify was on 4.0.0 at the time (helper 1.0.13). The build template hardcodes --network coolify into the docker build command for dockerfile-pack apps, and that flag combination is not supported by buildkit under the newer Docker version. There is no env var override for it either: the envs API on this version rejects is_build_time, so you cannot quietly slip a workaround in through app config.

What still worked

A deploy would "succeed" if Coolify could skip the build step entirely, i.e. an image tagged <uuid>:<full-commit-sha> already existed on the host ("Build step skipped"). That gave me a real workaround for shipping urgent fixes while waiting on the proper fix: build the image myself, outside Coolify's broken build path, then let Coolify deploy the tag it already has.

git archive <sha> | ssh <your-server> docker build -t <uuid>:<sha> -

Note the missing --network flag: building it yourself sidesteps the broken template entirely. This only works while the app's config_hash matches the last successful deploy. If the config changes, Coolify decides "Configuration changed. Rebuilding image." and forces the broken path again, so this is a stopgap, not a fix.

One other thing broke at the same time: the custom_nginx_configuration field. The API validates that the value must be base64, but the build step writes the stored string into the config verbatim, so a real value there produces a garbage nginx config and a crash-looping container. Clearing it through the API is not possible either; both an empty string and null are rejected. The only way to clear it was a direct database update:

UPDATE applications SET custom_nginx_configuration = NULL WHERE ...;

The real fix: upgrade Coolify

The actual fix was upgrading Coolify itself, from 4.0.0 to 4.3.14 (helper 1.0.16, realtime 1.0.17). Later releases drop the hardcoded custom network under buildkit. I backed up first, since there is no VPS provider snapshot API available to me on this box, so the backup is data-level rather than a full VM snapshot: a pg_dumpall of the Coolify database (155MB) and a tarball of /data/coolify (12MB), plus the container spec and .env.

After the upgrade, a deploy on one of the previously-broken apps reached "finished", and a second app built all the way into its own Dockerfile before failing on its own build step (a rolldown native-binding lockfile issue, unrelated to Coolify). I checked the actual build log rather than assuming, and the buildkit network error is gone.

The upgrade itself did not cause any downtime. Traefik (coolify-proxy, v3.6) and every app container run separately from the Coolify control-plane container, so live sites kept serving HTTP 200 through the whole upgrade window; only the control plane restarted.

One more gotcha the upgrade introduced

On 4.3.x the REST API's /deploy endpoint changed from GET to POST. If you have any script hitting the deploy endpoint directly, a GET now returns a 405 with "This endpoint has changed to a POST request". Any tooling that shells the Coolify API needs the same change after upgrading past 4.0.0.

Versions

Have Emsden Studio fix it for you, from A$149

More guides

All guides