We don’t have hooks on purpose.

You can run them when your application starts, as proposed by @LostKobrakai. Alternatively, you can add your own script to the bin directory, that you use to run migrations and then start the release. You can do this by adding a step to your mix.exs:

def project do
  [
    ...,
    releases: [
      my_app: [
        steps: [:assemble, &copy_bin_files/1]
      ]
    ]
  ]
end

where:

defp copy_bin_files(release) do
  File.cp_r("rel/bin", Path.join(release.path, "bin"))
  release
end

And you put the extra scripts in rel/bin.

Couldn’t you run them as part of application startup but before starting handling user input (like e.g. starting the phoenix endpoint)

I will examine both approaches. Thank you @LostKobrakai and @josevalim.

I am slightly inclined to “bring scripts with release” method since I would like to decouple scripts from application implementation.

BTW,

I am curious about the rationale here. Simplification, perhaps?

Imo the “steps” abstraction is more powerful and composable. One could probably build a small purpose build library, which handles all the dirty work of such boot hooks and supply its assembly to the steps listed in mix.exs.

I think migrations run wrapped in a transaction (one transaction per migration if I recall) but yes, that’s a concern since I can imagine situation where with multiple application instances starting up things can go sideways.