From 6a5ad9d9dc9948cbeaaadf29a8a844e0774c6ff9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Sun, 13 Sep 2026 13:03:41 +0200 Subject: [PATCH] docs(ops): run the manual migration inside the stack The update runbook ran migrations with a plain docker run and an .env.production file. No setup guide creates that file, and a plain docker run starts outside the Compose network, where the database's service name does not resolve, so the step waited thirty seconds and gave up with a connection error. It uses docker compose run now, which starts the one-off container in the stack with the app's own environment. Refs #961 --- docs/ops/deploy.md | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/docs/ops/deploy.md b/docs/ops/deploy.md index 065ed1100..f716516d4 100644 --- a/docs/ops/deploy.md +++ b/docs/ops/deploy.md @@ -13,24 +13,26 @@ Migrations land **before** the new app container takes traffic. The canonical command sequence on a single-instance host: ```sh -# 1. Pull the new image. -docker pull ghcr.io/mbombeck/healthlog:vX.Y.Z +# 1. Pull the new image. If you pin a version with HEALTHLOG_IMAGE_REF, +# set it to the new one first. +docker compose pull app -# 2. Run migrations against the live DB using the new image. The -# production image strips pnpm/npm; use the entrypoint's node -# invocation of the bundled Prisma CLI instead. -docker run --rm --env-file .env.production \ - ghcr.io/mbombeck/healthlog:vX.Y.Z \ - sh -c 'NODE_PATH=/opt/prisma-cli/node_modules node /opt/prisma-cli/node_modules/prisma/build/index.js migrate deploy' +# 2. Run the migrations with the new image before it takes traffic. The +# one-off container starts inside the stack, so it reaches the database +# as `db` and gets the same environment as the app. Its entrypoint +# applies the migrations and exits; a failed migration stops here. +docker compose run --rm app sh -c 'exit 0' # 3. Recreate the app container so it picks up the new image. docker compose up -d app ``` -The entrypoint also runs `prisma migrate deploy` on container boot, so -step 2 is redundant in normal Coolify flow. It's listed explicitly for -the manual case so an operator can verify the migration result before -flipping traffic. +Use `docker compose run` rather than a plain `docker run` for step 2. A +plain `docker run` starts outside the stack's network, where `db` does not +resolve, and the entrypoint gives up after thirty seconds with "Database +not reachable". The entrypoint also runs the migrations on every boot, so +step 2 is optional; it is there for when you want to see the migration +result before the new container takes traffic. ### v1.11.0 notes