forgejo-lila/lila
1
0
Fork 0
Code Issues 50 Pull requests Projects 1 Releases Packages Wiki Activity Actions

updating documentatin

Browse source
This commit is contained in:
lila 2026-04-23 10:40:34 +02:00
parent 1a50f73c74
commit 4623ea634a
2 changed files with 4 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

8
documentation/deployment.md
View file

@ -144,6 +144,7 @@ docker system prune -a # aggressive — removes all unused images
### API (`apps/api/Dockerfile`)
Multi-stage build: base → deps → dev → builder → runner. The `runner` stage does a fresh `pnpm install --prod` to get correct symlinks. Output is at `apps/api/dist/src/server.js` due to monorepo rootDir configuration.
The runner stage copies compiled migration files from the builder (packages/db/drizzle) alongside the application code. The container entrypoint runs migrate.js first, then starts server.js, ensuring schema and code are always in sync on every deploy.
### Frontend (`apps/web/Dockerfile`)
@ -174,12 +175,7 @@ The seeding script (`packages/db/src/seeding-datafiles.ts`) uses `onConflictDoNo
### Schema Migrations
Schema changes are managed by Drizzle. Deploy order matters:
1. Run migration first (database gets new structure)
2. Deploy new API image (code uses new structure)
Reversing this order causes the API to crash on missing columns/tables.
Migrations are run automatically on container startup via the CMD in the API Dockerfile. The entrypoint runs migrate.js before starting the server, so the schema is always up to date before the API begins accepting requests. The correct deploy order is enforced automatically.
## Backups