The database goes live

The boot has one hard precondition with two parts, and missing either looks almost the same at the crash site. Portal.Engine.init/1 folds the Portal’s state by replaying the event log, and it does so synchronously at startup: init/1 calls Portal.Engine.load/0, which calls the event store’s read_stream/1 — a real SELECT … FROM events under the connection pool’s four-second queue_timeout. If the database is unreachable the read times out; if it is reachable but unmigrated the read hits a table that does not exist. Either way init/1 raises, the child fails to start, the release exits, and Fly suspends the machine after ten restarts. Select a database condition to see what the boot’s read does.

A built release does not carry mix — it ships the compiled BEAM files and a bin/portal script, not the Mix archive — so mix ecto.migrate is not a command the deploy machine has. The schema is applied release-native instead, through Portal.Release.migrate/0, which loads :portal, starts the repository in isolation through Ecto.Migrator.with_repo, and runs every pending migration — without booting the full supervision tree. Three triggers reach that one entry point; the fourth does not exist on a release. Select a trigger to see where it runs and what it invokes.

In order: the release-native migration path by symbol — Portal.Release.migrate/0, rollback/2, and the idempotency that makes them safe to repeat; the empty-database trap and the fly proxy procedure that applies a schema against the writable primary; and the synchronous boot-time database coupling, documented with its hardening named as a carried item that touches the engine and so stays unbuilt here.