I don’t think you need to take any special care. Ecto takes care of this case by locking the migrations table:

https://hexdocs.pm/ecto_sql/Ecto.Migrator.html#run/4-execution-model

Another reason to love Ecto

Highly recommend the Safe Ecto Migrations series of posts — gave me a lot more confidence and understanding in this area.

Yes. The first instance to acquire the lock will run the migrations. All other instances will wait for the first instance to finish and release the lock - they will then acquire the lock in turn, see the database already migrated, and do nothing.

And I do the same as an ExecStartPre in systemd.

ExecStartPre= /opt/admin/bin/admin eval "Admin.Release.migrate()"
ExecStart= /opt/admin/bin/admin start
ExecStop= /opt/admin/bin/admin stop

Hey everyone, I know this is an old thread but building on the accepted answer, I ran into an issue where docker compose stop was timing out on Elixir containers. The problem was the shell script (sh) handling SIGTERM as PID 1 instead of the BEAM.

To fix this, I updated the custom Phoenix server script (rel/overlays/bin/server):

#!/bin/sh
set -eu

cd -P -- "$(dirname -- "$0")"
# added this migration line
./my_app eval MyApp.Release.migrate 

PHX_SERVER=true exec ./my_app start

With this, the Dockerfile stays:

CMD ["/app/bin/server"]

Now migrations run on startup, and SIGTERM signals are properly handled. Hope this helps someone that may be going through the same problem! Thanks! (: