Deploy from CI with Infisical and ship Payload changes as migrations

CI reads Infisical staging as the read-only convexmonorepo-ci machine identity, deploys the Convex functions, builds and pushes the image, and asks the VPS to redeploy. Payload schema changes now ship as migrations that production runs on startup; the baseline matches the production schema and is recorded as applied there. The local stack moves to its own ports and syncs the Convex runtime env, and the scripts pick up Infisical account switching, dev-kill and a cache-safe CI install.

README.md

@@ -5,7 +5,8 @@ Payload CMS, shared UI/config packages, Vitest, and Docker deployment.
 
 ## Local setup
 
-Requirements: Bun 1.3.10, Docker or Podman, Node 22, and the Infisical CLI.
+Requirements: Bun 1.3.14, Docker or Podman, Node 22, the Infisical CLI, `jq`, and
+`flock`.
 
 ```sh
 bun install --frozen-lockfile
@@ -22,9 +23,9 @@ files. Select staging with `INFISICAL_ENV=staging bun dev:next`.
 Local services:
 
 - Next.js: `http://localhost:3000`
-- Convex API: `http://localhost:3210`
-- Convex dashboard: `http://localhost:6791`
-- Payload Postgres: `localhost:5432`
+- Convex API: `http://localhost:3240`
+- Convex dashboard: `http://localhost:6794`
+- Payload Postgres: `localhost:5436`
 
 Next and Expo run on the host. Payload uses the local Postgres database. Convex
 uses a separate self-hosted data volume and does not use Postgres by default.
@@ -54,7 +55,8 @@ Convex URL with the development host's LAN address when testing Expo on-device.
 
 - Local `dev` and `staging`: Infisical.
 - Generated local state: `.local/<environment>.generated.env`.
-- CI/CD: Gitea `DOTENV_PROD`, materialized only as a temporary runner file.
+- CI/CD: Infisical `staging`, read by the read-only `convexmonorepo-ci` machine
+  identity and materialized only as a temporary runner file.
 - Docker compilation: explicit Compose build args; `.env*` stays outside the
   image context.
 
@@ -87,6 +89,14 @@ Shared dependency versions belong in root catalogs. Edit the root catalog, run
 
 Production Compose retains the self-hosted Convex backend/dashboard and accepts
 an external Payload `PAYLOAD_DB_URL`. Its commented Postgres service remains an
-optional Payload database. Gitea runs the quality gate first, builds the Next
-image from a temporary Gitea-secret env file, then pushes SHA and `latest` tags.
-CI never installs or invokes Infisical.
+optional Payload database.
+
+A push to `main` runs the quality gate, deploys the Convex functions, builds the
+Next image, pushes SHA and `latest` tags, and asks the VPS to redeploy
+`podman-convexmonorepo.service` over the forced-command deploy key. If that last
+step fails, the nightly update timer deploys the image instead. Each job reads
+Infisical `staging` through `scripts/ci-export-env.mjs` as the `convexmonorepo-ci`
+machine identity (Gitea secrets `INFISICAL_CLIENT_ID` and
+`INFISICAL_CLIENT_SECRET`).
+
+Payload schema changes ship as migrations; see `AGENTS.md`.