Always use Releases


To be clear, the application start callback does not start before all the dependencies in your applications and extra_applications lists. If you have dependencies which are not well-behaved, in other words you need to configure them before starting, then you use included_applications, which puts you in control of the lifecycle of those applications, allowing you to configure them and start them whenever you like.

1.) This is so subjective I don’t think it’s an argument worth making, and rather misses the point I was making above about putting complex configuration validation/transformation logic where it belongs
2.) I absolutely agree that the documentation and guidance on configuration is wildly insufficient, but most everything I brought up is covered in Distillery’s documentation, which includes a page on configuration specifically - but that only helps if you are looking at Distillery’s docs, we need official guidance to cover the same topics.

One thing I have been considering adding to Distillery is support for using config.exs in a release, but it’s not currently implemented yet - in any case, what you are describing here is already how Mix’s configuration file works more or less, the issue boils down to the fact that it does have limitations when used with releases.


Are you using releases on Heroku as well?


I thought config/*.exs is buildtime only configuration. In other words, once the release is built, those configurations are “frozen”.

I was suggesting some config files in the style of Mix.Config (you know, with that nice sexy DSL) that are evaluated at runtime and merged into the application’s configuration at time of the application startup (right before all applications are started).

Does that make sense or am I completely not understand something?


You just described how mix config works. It loads all the configs when starting up, before starting any application.

The problem with releases is that mix is no longer there, so it can’t load config when applications start (as it does normally), but the config is serialised when a release is built and later, loaded from the serialised format.