arcanemachine
Preamble: I am aware of other methods of dynamic runtime configuration (e.g.
Config.Provider), and am currently a happy user of Dotenvy. The title of this thread is not “How to dynamically configure runtime config?”, but is specifically pertains to the usage ofCode.eval_file/1as a strategy to do so.
I am experimenting with different strategies to dynamically import runtime config, similar to how Config.import_config/1 works for compile-time config.
I have come up with a solution that appears to work. I am bringing the topic here for discussion, to see if there are any valid technical reasons why I should not use this strategy.
The strategy
Here is an example config/runtime.exs that uses Code.eval_file/1 to import a local runtime config file, if one exists:
config/runtime.exs
import Config
config :my_project, :hello, :world
# Maybe import local runtime config file(s)
for local_runtime_config_file_name <-
["runtime.local.exs", "runtime.#{config_env()}.local.exs"] do
local_runtime_config_file_path = Path.join(__DIR__, local_runtime_config_file_name)
if File.exists?(local_runtime_config_file_path) do
IO.puts("Importing local runtime config from `#{local_runtime_config_file_path}`...")
Code.eval_file(local_runtime_config_file_path)
end
end
This allows one or more (presumably gitignored) local runtime config files to be added, without having to modify the main runtime config file:
config/runtime.local.exs
import Config
config :my_project, :hello, :another_world
The above example shows how a local runtime config file could be loaded for 1) all configuration environments, and/or 2) a specific configuration environment (e.g. :dev, :test, etc.), and supports cascading (i.e. the global runtime.local.exs would be overridden by e.g. runtime.dev.local.exs). If any of the local files do not exist, then that is fine also, and no custom config would be loaded.
I have this running, and it appears to work. But I haven’t seen this strategy documented anywhere, so I’m a little wary of using it.
Does this appear to be a viable strategy, or is there some hidden footgun here that I am not aware of?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #elixirconf-us
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 8- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
mudasobwa
I might be missing something, but what would be wrong with plain old good
Config.import_config/2?tfwright
I infer from your preable that you are specifically looking for technical answers, but since you mention this purpose I am curious why in such a situation you wouldn’t just use a single default “example” file and modify/copy it to the “real location” as needed, which I think is a pretty standard way to handle this kind of thing?
I suspect any real answer to your question would benefit from similar details, because answers to a question like “can I” generally come with a lot of “depends”…
LostKobrakai
Instead of answering the question I’ll answer why this isn’t a feature in the first place:
Runtime config needs to be copied into releases, so the config can be executed when the application boots. That copying means mix needs to know which files to copy in the first place statically – it cannot run the config file to figure it out, because conditions might change. Therefore to keep things easy elixir limits runtime config to a single file by default, which has to exist with a known name at a known location. All this happens under the premise that a release once assembled can be copied as is and is startable.
Now you can manually make sure additional files are also copied into the release and then you could read them. It would retain all the properties elixir/mix tries to uphold from it’s pov knowling less details about your project. I’ll leave the judgement if that’s a good idea to yourself though.
arcanemachine
I thought that didn’t work for runtime config?
I need to look into this again…
EDIT: Got this error:
** (RuntimeError) import_config/1 is not enabled for this configuration file.arcanemachine
We basically do what you’re describing, but it can lead to drift between the committed
runtime.exsfile and what the DevOps people’s file looks like. There have been times where a dev committed code that was in their local compile-time config, but wasn’t actually committed to the code repo, which can lead to confusion when other people pull the code and have no way of seeing what the config value should be, leading to some confusing crashes. (I realize that this is not a problem with the runtime config itself, but it sort of addresses an issue with the exampleruntime.exsfile, which is that “drift” can occur.)What it really comes down to is this: When I use Dotenvy, I get a nice “base” runtime.exs, which I can extend for each environment with custom dotenv files. This also prevents the “drift” in
runtime.exsthat I mentioned before. I’m just trying to see if I can come up with a solution that feels similarly “right” without needing the external dependency. (I’m a huge Dotenvy fan because the same dotenv config files can also be used to customize a Docker image environment, which has been useful.)mudasobwa
Ah, indeed. The documentation even explicitly states that. Good to know.
LostKobrakai
Personally I skip file in the equation. All the things that need to be set from the outside at runtime need to come in as system env variables.
runtime.exsreads those. But elixir/mix/releases are not at all involved at setting those variables. For that I tend to use direnv locally / in development and whatever tool my deployment target provides to set environment variables. Those may or may not be able to source from files committed to the repo itself - e.g. .envrc for direnv can be commited, but a systemd unit might live elsewhere – so first and foremost I want to provide documentation (and good errors) around the set of expected env variables, rather than trying to prescribe how downstream people have to provide values. Theruntime.exsessentially becomes a mapping from system env input to elixir config values for the minimal set of what should be configurable at runtime.adamu
It sounds like you have a local uncommited
.exsfile that is duplicating the role thatruntime.exsin plays in a release. So in the uncommited.exsyou are setting up config using elixir, andruntime.exsyou are setting the same config via environment variables.It might simplify things to remove the ability to have any uncommited local config, and have any customisations set via environment variables via
runtime.exslocally, too. That way, if a dev forgets to commit the config, it will fail to compile on CI / for everyone else.edit: whoops, posted before seeing the above post. I think we’re saying the same thing.