chore(release): v1.4.34.2 — pull_policy: always on docker-compose

The v1.4.34.1 image published to GHCR successfully but never reached
production because Coolify's `docker compose up` kept reusing the
cached `:latest` digest on the apps-01 host. The default Docker pull
policy ("only pull if missing") skipped the registry round-trip and
restarted the container with the prior v1.4.34 image.

Declare `pull_policy: always` on the `app` service so compose-up
re-checks the registry digest on every `up` regardless of the local
cache. Bundle-release because the v1.4.34.1 work ships through the
same `:latest` tag — this is the deploy mechanic that makes v1.4.34.1
actually land.

CHANGELOG.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## [1.4.34.2] — 2026-05-16 — `pull_policy: always` so Coolify deploys actually pull
+
+Bundle-release hotfix for the v1.4.34.1 deploy stall. The GHCR image
+for v1.4.34.1 published successfully, but Coolify's `docker compose up`
+on the apps-01 host kept reusing the cached `:latest` digest because
+`docker-compose.yml` had no pull policy declared — Docker's default
+("only pull if missing") happily skipped the registry round-trip and
+restarted the container with the prior v1.4.34 image, completing each
+deploy in ~20 s without ever fetching the new manifest. Two consecutive
+force-rebuilds of v1.4.34.1 reproduced the pattern.
+
+### Changed
+
+- `docker-compose.yml` now declares `pull_policy: always` on the `app`
+  service. Compose-up re-checks the registry digest on every `up` and
+  pulls when GHCR has a newer manifest, regardless of the tag string.
+  The minor bandwidth cost per deploy is the price of correctness; the
+  alternative — pinning to a version tag per release — would require
+  every operator (self-host included) to bump the tag on every release.
+  v1.4.34.1's perf work ships in this image because all of it is on the
+  `:latest` tag the Coolify deploy will now actually pull.
+
 ## [1.4.34.1] — 2026-05-16 — Insights cold-mount perf hotfix + scatter-card sizing
 
 Hotfix on top of v1.4.34. The Insights page mount was paying ~29 s on

docker-compose.yml

@@ -4,12 +4,16 @@ services:
   # For horizontal scaling switch to the web/worker split below
   # (HEALTHLOG_PROCESS_TYPE=web on this service + uncomment app-worker).
   app:
-    # Pinned to GHCR :1.3.3 multi-arch image (gestern released, audit-tested).
-    # Production on apps-01 has been 503-ing since today's deploys; rolling back
-    # to the last release that's verifiably running on self-host installs to
-    # rule out runtime / Docker-network issues. No `build:` block on purpose:
-    # we want Coolify to PULL the prebuilt image, not build from source.
+    # Tracks the GHCR `:latest` multi-arch image. `pull_policy: always`
+    # is the load-bearing line — without it, Docker keeps a stale
+    # `:latest` digest cached on the host and skips the registry round-
+    # trip on `compose up`, which is what kept Coolify re-deploying the
+    # previous image after every tag push. With pull_policy=always the
+    # compose-up always re-checks the registry digest and pulls when
+    # GHCR has a fresher manifest. The small bandwidth cost on every
+    # `compose up` is the price of digest-correctness.
     image: ghcr.io/mbombeck/healthlog:latest
+    pull_policy: always
     container_name: healthlog-app
     ports:
       - "3000:3000"

package.json

@@ -1,6 +1,6 @@
 {
   "name": "healthlog",
-  "version": "1.4.34.1",
+  "version": "1.4.34.2",
   "description": "Self-hosted personal-health-tracking PWA with Withings integration, AI insights, and doctor-report PDF export.",
   "license": "AGPL-3.0-only",
   "homepage": "https://healthlog.dev",