Fix migration strategy docs to match production
Coolify runs migrations post-deploy via rel/overlays/bin/migrate, not on boot. Update both architecture and infrastructure docs. Closes #141
This commit is contained in:
@@ -36,7 +36,7 @@ MusicLibrary.Application (one_for_one)
|
||||
│ ├── Telemetry.Storage # Metrics storage (SQLite-backed, persistent)
|
||||
│ └── :telemetry_poller # 30s periodic measurements
|
||||
├── Oban # Background job engine
|
||||
├── Ecto.Migrator # Auto-migration on boot
|
||||
├── Ecto.Migrator # Migrations (skipped in release; run by Coolify post-deploy)
|
||||
├── Task.Supervisor (MusicLibrary.TaskSupervisor)
|
||||
├── Phoenix.PubSub (:music_library)
|
||||
└── MusicLibraryWeb.Endpoint
|
||||
|
||||
@@ -164,7 +164,12 @@ A manual verification workflow (`.github/workflows/verify.yml`) can be triggered
|
||||
|
||||
Standard Mix release. Entry point: `rel/overlays/bin/server` (sets `PHX_SERVER=true`).
|
||||
|
||||
Migrations run automatically on boot via `Ecto.Migrator` in the supervision tree.
|
||||
Migrations are skipped during release boot (`skip_migrations?/0` returns `true` when
|
||||
`RELEASE_NAME` is set). Instead, Coolify is configured to run migrations after the
|
||||
Docker image is built and the container is started — this happens via the
|
||||
`rel/overlays/bin/migrate` script, executed as a post-deployment command in Coolify
|
||||
before the application begins serving traffic.
|
||||
|
||||
A standalone `rel/overlays/bin/migrate` script is also available for manual use.
|
||||
|
||||
ERL_FLAGS: `+JPperf true` (JIT performance monitoring).
|
||||
|
||||
Reference in New Issue
Block a user