Mix release and config files priority

You should also verify that this isn’t from the load-balancing layer on AWS because each of those have idle timeouts as well. It’s typically in the strict sense of “no bytes have flowed in or out in this time” though.

In terms of precedence, I typically tell people to use a remote console (or whatever the non-Distillery name for the release’s subcommand is) and check Application.get_all_env/1 to see if their desired configuration is being realized on the running release. If not, work backwards from there.

Elixir 1.11 will bring a unifying idea of runtime config that behaves the same in dev/test/prod/releases and should make this question of precedence slightly less ambiguous/hard to teach.

Precedence is quite simple actually:

config.exs is evalutated by mix, so for releases at the time the release is built. Everything import_config follows the order of execution.

releases.exs is evaluated when a release is started.

I have a clear defined precedence in my setup, because my releases.exs file is always evaluated first, no matter what env I am working on, therefore I override production config in development, not the other way around. See my reply with an example here:

config.exs

# This file is responsible for configuring your application
# and its dependencies with the aid of the Mix.Config module.
#
# This configuration file is loaded before any dependency and
# is restricted to this project.

# General application configuration
use Mix.Config

# Keep consistency between environments. Development will derive from a
#  production environment, not the other way around. Having separated
#  configuration as Elixir and Phoenix currently promote can lead to adding a
#  new configuration field in `dev.exs` that you then forgot to add in
#  `prod.exs` and/or `releases.exs`, therefore you then have a broken production
#  deployment.
import_config "releases.exs"

config :mnesia,
  dir: '.mnesia/#{Mix.env}/#{node()}'

# Import environment specific config. This must remain at the bottom
# of this file so it overrides the configuration defined above.
import_config "#{Mix.env()}.exs"

So at build time you’re evaluating releases.exs just to override it with prod.exs, which at release startup is then overriden by releases.exs contents. This to me sounds like way backwards.

Thanks for this. It was a good tip.

I am going to use this pattern. It is great.

The example is a very simplified one.

In releases.exs I will put all the config that is for a production environment, and then in each environment test and development environment I override only what I need.

From the example comments:

# Keep consistency between environments. Development will derive from a
#  production environment, not the other way around. Having separated
#  configuration as Elixir and Phoenix currently promote can lead to adding a
#  new configuration field in `dev.exs` that you then forgot to add in
#  `prod.exs` and/or `releases.exs`, therefore you then have a broken production
#  deployment.

I saw that the last time you posted it, but I still feel this is problematic. To me it works like that:

config.exs (baseline)
→ #{Mix.exs} (Mix level override)
—> releases.exs (system/runtime level override)

Config is by no means separate. The stuff from config.exs and prod.exs is fully available to your release. What you did by no means solved the problem because someone adding a config in dev.exs will still make it be not configured in a prod release.

What if I have both prod.exs, config.exs(obviously importing prod.exs) and release.exs. Both prod and release configure the same env attribute. Will release triumph? and have its data used?