405b929f66
- Add Nitro plugin to apply Drizzle migrations on server boot (skips when DATABASE_URL is unset, e.g. during build). - Split compose: docker-compose.dev.yml (hot-reload + Postgres) vs docker-compose.yml (production/self-host, env-driven, Coolify-deployable). - Add .dockerignore; parameterise compose env; document the autodeploy decision (Coolify watches main, no CI workflow needed) in ADR 0003 and plan.md T12.
24 lines
1.2 KiB
Markdown
24 lines
1.2 KiB
Markdown
# Use Coolify-managed PostgreSQL over SQLite
|
|
|
|
The `/deep-design` session chose SQLite on a persistent volume for its zero-ops
|
|
simplicity at this scale. Deploying on **Coolify** changes the calculus: Coolify
|
|
provides **managed PostgreSQL with automatic scheduled backups**, whereas a
|
|
SQLite file inside an app volume has *no* managed backup and forces a
|
|
single-instance, stop-then-start deploy strategy to avoid file-lock contention
|
|
when Coolify briefly runs old and new containers during a rolling restart. We
|
|
switch to **Coolify-managed PostgreSQL** (via Drizzle's `pg` driver).
|
|
|
|
## Consequences
|
|
|
|
- Backups are handled by Coolify's database backup feature — no bespoke tooling
|
|
(e.g. Litestream) needed.
|
|
- Deploys no longer need a recreate/single-instance constraint; the app can
|
|
restart freely while Postgres persists as a separate service.
|
|
- Adds a Postgres service to local dev (`docker-compose`) and a managed DB in
|
|
prod — one more moving part than a single file.
|
|
- **Supersedes** the SQLite choice in DESIGN.md (T5, F10) and the original
|
|
`/deep-design` decision.
|
|
- Autodeploy from `main` is enabled (Coolify watches the repo and deploys on
|
|
push); `main` must be protected with required PR review + CI so only vetted
|
|
commits reach production.
|