makearmy/le-app
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

define canonical migration deployment paths

Browse source
This commit is contained in:
makearmy 2026-07-10 20:21:27 -04:00
parent ed1c84eb76
commit 27fd4f4ae3
4 changed files with 238 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/payload-migration/architecture-proposal.md
View file

@ -139,8 +139,14 @@ The repository's separate curated file library (`app/files`, 282 files and appro
CI builds the frontend, Payload, BGBye, and proxy images once from reviewed commits under their pinned runtimes. Integration tests run those exact digests. Staging and production consume the same core Compose definitions and immutable image digests; they do not rebuild from source or use separately maintained service definitions. Environment overlays may change secrets, hostnames, resource policies, external storage/database endpoints, replica counts, and production TLS integration, but not application image contents or service contracts.
The permanent production checkout and deployment root is `/var/www/lasereverything.net.db`. It contains the complete versioned stack: frontend, Payload, BGBye, Compose definitions, migrations, deployment scripts, internal gateway contract, health checks, and validation tooling. No production checkout or application deployment may run from `/srv`, `/opt`, a Codex workspace, a temporary worktree, or another project root. Operational Docker layers, declared database/media volumes, and server-wide proxy files may live elsewhere, but the deployment rooted at the canonical production checkout declares and controls their contracts.
The sole persistent nonproduction project root is `/srv/le-payload-dev`, with the checkout at `/srv/le-payload-dev/lasereverything.net.db`. The dedicated account design does not retain the current nested `.worktrees/payload-migration` layout. Temporary worktrees may be created under the canonical nonproduction root for a specific documented task and must be removed when that task ends.
Production database schema changes use committed Payload migrations as an explicit release job before application rollout. Imports are migration-only jobs and are not part of ordinary application startup. Promotion requires recorded image digests, migration status, validation results, rollback compatibility, and health checks.
Promotion never copies the nonproduction checkout or filesystem into production. A reviewed commit/release manifest is fetched into a clean checkout or unpacked as a verified release artifact at `/var/www/lasereverything.net.db`; production then pulls the already-tested immutable image digests. Development caches, local secrets, scrubbed snapshots, reports, test artifacts, rootless state, and disposable volumes are never promotion inputs.
## Directus metadata disposition
See `metadata-disposition.md` for the explicit include, translate, archive-only, and exclude decisions. Exclusion means “not imported into Payload runtime tables,” never “destroyed from the frozen snapshot or archive.”