Sync the self-hosting stack

docker-compose.yml

@@ -23,9 +23,8 @@
 #
 # UPGRADING: `docker compose pull && docker compose up -d`. Every Jarvis image here tracks `stable` by
 # default, so that is the whole upgrade. Postgres and Redis are not on a Jarvis channel — they follow
-# their own upstream tags. Schema changes apply themselves when the api starts, and they are ONE-WAY:
-# there is no migration history, so pulling an older api image does not put the schema back. Take a
-# dump first. See the README.
+# their own upstream tags. Schema changes are migrations the api applies when it starts, and they are
+# ONE-WAY: pulling an older api image does not take one back. Take a dump first. See the README.
 #
 # A channel tag does NOT mean the app forgets which build it is: `stable` is a second name on the same
 # image as its version tag, and the version is stamped INTO the image when it is built. The footer in
@@ -59,7 +58,7 @@ services:
   # key once and will not let you past until you have put it somewhere.
   init:
     image: ${JARVIS_IMAGE_API:-git.luxit.be/luxit/jarvis-api:stable}
-    entrypoint: ["node", "/app/apps/api/init-secrets.cjs"]
+    entrypoint: ["jarvis", "init-secrets"]
     restart: "no"
     environment:
       # Only read when the corresponding file does not exist yet — the upgrade path for a stack
@@ -128,6 +127,7 @@ services:
       # sealed under, and nothing about that failure is visible until somebody opens a credential.
       - jarvis_secrets:/var/lib/jarvis/secrets:ro
     environment:
+      # Read by the api under this name: the refresh cookie is `Secure` only in production.
       NODE_ENV: production
       API_PORT: "4000"
 
@@ -140,7 +140,7 @@ services:
       # and every consumer now reads the single stored value.
       WEB_ORIGIN: ${WEB_ORIGIN:-}
 
-      # Assembled by the entrypoint from POSTGRES_PASSWORD_FILE, because a password that lives in a
+      # Assembled by the api from POSTGRES_PASSWORD_FILE, because a password that lives in a
       # file cannot be interpolated into a URL by compose. Set DATABASE_URL in .env to override it
       # outright — pointing at a managed postgres outside this stack, say.
       DATABASE_URL: ${DATABASE_URL:-}
@@ -208,11 +208,11 @@ services:
 
       # This container brings the database up to its own schema before serving. Left on, because on
       # compose one container IS the deployment. Turn it off only where something else runs
-      # `migrate.sh` first — an orchestrator with a run-once Job, say.
+      # `jarvis migrate` first — an orchestrator with a run-once Job, say.
       JARVIS_SKIP_MIGRATIONS: ${JARVIS_SKIP_MIGRATIONS:-false}
-      # Let that phase DROP columns and tables. OFF, and it should stay off between deliberate acts:
-      # without it the schema sync REFUSES and prints what it would have destroyed, which is the
-      # answer you want from an upgrade that was not expecting to lose anything.
+      # Let a migration DROP columns and tables. OFF, and it should stay off between deliberate acts:
+      # without it a migration that would drop one is REFUSED, naming what it would have destroyed,
+      # which is the answer you want from an upgrade that was not expecting to lose anything.
       SCHEMA_ACCEPT_DATA_LOSS: ${SCHEMA_ACCEPT_DATA_LOSS:-false}
 
       # The browser the assistant may use, if you run one. Unset is a supported state: the two web
@@ -230,15 +230,11 @@ services:
       - default
       - browsernet
     healthcheck:
-      test:
-        - CMD
-        - node
-        - -e
-        - "fetch('http://localhost:4000/api/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"
+      test: ["CMD", "jarvis", "healthcheck"]
       interval: 10s
       timeout: 5s
       retries: 12
-      # First boot syncs the schema and runs the data backfills before it listens.
+      # First boot applies the schema and runs the data backfills before it listens.
       start_period: 40s
 
   # The headless browser, and everything about this service is about keeping it away from the rest.