For Ecto, you can just run a function:

  migrations_path = Path.join(["#{:code.priv_dir(:myapp)}", "repo", "migrations"])
  Ecto.Migrator.run(MyApp.Repo, migrations_path, :up, all: true)

Since migrations are idempotent, and I always want to run up to the latest migration, I just include this in lib/myapp.ex in its start function. That way any time a new release rolls out, the first node with the new release automatically runs the migrations. (We always make sure our migrations are backwards compatible for at least X number of versions, which means never deleting tables or columns so that existing nodes don't break)

But then you need to install Erlang/Elixir on the server, which kind of defeats the purpose of releases, don't you? Or have you abandoned releases altogether?

I actually find really good that mix commands are not included. Those are Makefile commands, I wouldn't expect them on production.

It's funny that the case highlighted is the one about migrations, which indeed shouldn't be located or connected to the app in the first place. There are a lot of SQL migration tooks available, but even simple bash scripts are enough.