feat: add CMS content sync on boot feature and update related documentation

apps/cms/.env.docker.example

@@ -32,6 +32,11 @@ CMS_PORT=3001
 # once SQL migrations are wired up so prod no longer mutates schema on boot.
 # PAYLOAD_DB_PUSH=true
 
+# Seed/refresh the CMS database from git content/ on every container boot.
+# Defaults to true. Set to "false" once editors manage content directly in
+# Admin and you don't want git content overwriting their changes on each boot.
+# CMS_SYNC_ON_BOOT=true
+
 # --- GitHub "Create PR" workflow (optional admin feature) --------------------
 GITHUB_OWNER=logos-co
 GITHUB_REPO=logos-web

apps/cms/README.md

@@ -154,6 +154,11 @@ pnpm --filter cms migrate          # apply pending migrations (run against the t
 
 The generated file under `src/migrations/` and the updated `src/migrations/index.ts` **must be committed** — production applies exactly what's in that directory.
 
+**Caveats:**
+
+- **A failed migration blocks the deploy.** The entrypoint runs under `set -e`, so if `payload migrate` exits non-zero the container stops before serving traffic. Test migrations against a staging database first.
+- **Single-instance assumption.** The entrypoint migrates on every container start. If you scale the CMS to more than one replica, run migrations as a separate one-shot step (or gate them behind a leader) so replicas don't migrate the same database concurrently — the bundled `docker-compose.prod.yml` runs a single `cms` service, so this is safe as-is.
+
 ### Health check
 
 The image exposes a health endpoint used by Docker's `HEALTHCHECK`:

apps/cms/docker-entrypoint.sh

@@ -13,5 +13,20 @@ set -e
 echo "[entrypoint] Applying Payload migrations..."
 PAYLOAD_CONFIG_PATH=payload.config.ts node_modules/.bin/payload migrate
 
-echo "[entrypoint] Migrations done. Starting server..."
+# Seed/refresh the CMS database from the repo's content/ fixtures. The repo's
+# model is "git content/ is the runtime source of truth" — this upserts that
+# content into Payload (created/updated/skipped). Disable with
+# CMS_SYNC_ON_BOOT=false (e.g. once editors manage content directly in Admin
+# and you don't want git content overwriting their changes on every boot).
+# Sync failure is non-fatal: the server still starts with whatever data exists.
+if [ "${CMS_SYNC_ON_BOOT:-true}" != "false" ]; then
+  echo "[entrypoint] Syncing content from content/ ..."
+  if PAYLOAD_CONFIG_PATH=payload.config.ts node --import tsx scripts/sync-from-content.ts; then
+    echo "[entrypoint] Content sync complete."
+  else
+    echo "[entrypoint] WARNING: content sync failed; starting with existing data. See logs above." >&2
+  fi
+fi
+
+echo "[entrypoint] Starting server..."
 exec "$@"

docker-compose.prod.yml

@@ -54,6 +54,9 @@ services:
       PAYLOAD_DB_SCHEMA: ${PAYLOAD_DB_SCHEMA:-payload}
       PAYLOAD_DB_PUSH: ${PAYLOAD_DB_PUSH:-true}
       PAYLOAD_DB_POOL_MAX: ${PAYLOAD_DB_POOL_MAX:-10}
+      # Seed/refresh DB from git content/ on every boot. Set false to stop git
+      # content from overwriting Admin-managed data.
+      CMS_SYNC_ON_BOOT: ${CMS_SYNC_ON_BOOT:-true}
       # GitHub "Create PR" workflow (optional — admin feature).
       GITHUB_OWNER: ${GITHUB_OWNER:-}
       GITHUB_REPO: ${GITHUB_REPO:-}