The deployment failed on the migrate service. Coolify rewrites a relative
bind mount to a path under its own application directory, and when that
resolves to an empty directory golang-migrate finds no migrations and
exits 1 - with nothing useful in the deployment log to say why.
A deployment that pulls its images has no business also depending on
files being at a particular path on the host. Both mounts are now baked
into images built from the repository root:
migrations - the schema, so migrate always has it
rspamd - actions.conf and ratelimit.conf
The Rspamd one mattered for a quieter reason: Rspamd starts happily with
an empty local.d, so a mount that resolved to nothing would have left the
rate limits and score thresholds unapplied. The defence would have looked
configured and done nothing.
Both images join the CI and release matrices, building from the root
context. Verified by building them, checking their contents, and bringing
the whole stack up - Rspamd reports its nine rate directives loaded from
the image.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The first deployments died building on the target: four images, and the
webmail build alone was enough to sink it on a small arm64 host - the
build step was killed with no BuildKit error, which is what an exhausted
or overloaded machine looks like from the outside.
The images already exist. CI publishes all four to GHCR for amd64 and
arm64 on every merge, and they are the ones the suite ran against, so
rebuilding them on the deploy target is slower, heavier and less
trustworthy than pulling them.
docker-compose.yaml therefore carries no build definitions, and
docker-compose.build.yaml is the overlay that adds them for local
development and for CI - which does have to exercise the branch rather
than the published images. Both paths were run before committing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
