# Upstream sources — immich

| service | image | source repo | releases / changelog |
|---------|-------|-------------|----------------------|
| app | ghcr.io/immich-app/immich-server | https://github.com/immich-app/immich | https://github.com/immich-app/immich/releases |
| immich-machine-learning | ghcr.io/immich-app/immich-machine-learning | https://github.com/immich-app/immich | https://github.com/immich-app/immich/releases |
| redis | docker.io/valkey/valkey | https://github.com/valkey-io/valkey | https://github.com/valkey-io/valkey/releases |
| database | ghcr.io/immich-app/postgres | https://github.com/immich-app/base-images | https://github.com/immich-app/immich/blob/main/docker/docker-compose.yml |

## Standing notes

- **DB image is pinned BY immich-server, not bumped independently.** abra cannot survey/upgrade this
  recipe (`FATA … Docker references with both a tag and digest are currently not supported`) because
  `database` is pinned `image:tag@sha256:…`. Use the box-item-4 direct check: the authoritative source
  for the DB tag is **immich's own `docker/docker-compose.yml` at the immich-server release tag**
  (`https://raw.githubusercontent.com/immich-app/immich/<vX.Y.Z>/docker/docker-compose.yml`). Pin the
  recipe's `database` image to EXACTLY what that compose pins for the matching immich-server version —
  do NOT take the newest `ghcr.io/immich-app/postgres` tag. Newer tags (pg-15/16/17/18,
  vectorchord0.5.x, pgvectors0.3.0) exist but moving ahead of what immich-server ships forces a
  **pg-major data migration** and an unsupported extension combo.
- **immich-server v3.0.2 (latest, 2026-07-09) pins** (from its `docker/docker-compose.yml` at the
  v3.0.2 tag): `postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191…` and
  `valkey:9@sha256:4963247afc4cd33c7d3b2d2816b9f7f8eeebab148d29056c2ca4d7cbc966f2d9`.
  The recipe (origin/main, published `1.9.0+v3.0.1`) is AHEAD on
  `postgres:14-vectorchord0.4.3-pgvectors0.3.0@sha256:87c050465…` (pgvectors 0.2.0→0.3.0, backward-
  compatible — keep it, do NOT downgrade to immich's 0.2.0). Digest re-verified identical via
  `docker buildx imagetools inspect` on cc-ci (2026-07-13). The recipe's valkey pin
  `valkey:9@sha256:3b55fbaa…` was a STALE old digest for tag `9`; `valkey:9` now resolves to
  `sha256:4963247afc4cd…` (= immich v3.0.2's pin = `valkey:9.1.0`, the newest 9.x; no 9.1.1/9.2.x
  exists). Refreshed the digest to `4963247afc4cd…` in the 2026-07-13 upgrade (v3.0.1→v3.0.2).
- **Historical (v2.7.5, 2026-04-13):** immich-server v2.7.5 pinned
  `postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191…`. PR #2 bumped the recipe to
  `pgvectors0.3.0@sha256:87c050465…` (same PG14 + VectorChord 0.4.3, newer pgvectors 0.2.0→0.3.0).
- **Concurrent app+database restart needs `update_config: failure_action: continue` on the app service.**
  When the recipe version label changes (bumping `coop-cloud.${STACK_NAME}.version`) AND the database
  image changes in the same deploy, both services update simultaneously. The app container starts and
  immediately tries TypeORM migrations against a still-restarting database → TypeORM connection fails →
  app process crashes → task FAILED → Docker Swarm sets `UpdateStatus='paused'` (default
  `failure_action: pause`). Fix: set `update_config: failure_action: continue` on the app service.
  With `continue`, Docker Swarm records the update as `completed` and Docker's `restart_policy` retries
  the app container; the database finishes restarting in ~15-20s and the app connects successfully.
  This is also in the recipe as of PR #2.
- **VectorChord DB backup/restore needs the search_path sed.** A plain `pg_dump` of the
  VectorChord/pgvecto.rs DB emits `SELECT pg_catalog.set_config('search_path', '', false);`. Importing
  that as-is leaves the vector/vchord type + operator references unresolvable, so the first such
  statement errors. immich's official restore (docs.immich.app/administration/backup-and-restore) pipes
  the dump through:
  `sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g"`
  before `psql … --single-transaction --set ON_ERROR_STOP=on`. Omitting that sed (immich PR #1's
  `pg_backup.sh`) is why the single-transaction import aborted wholesale and `ci_marker` was lost on
  restore — fixed in the upgrade PR's `pg_backup.sh`.