Is it common to add a shell script somewhere? I see that Fly.io generated an env.sh.eex to export some variables. Should I do the same? Not sure how to run that before each compile, however…

For development, the answer is probably to use direnv.

Personally, I just make myself a shell script in the root directory that I call dev that has the following as a bare minimum.

#!/usr/bin/env bash

source .env

case $@ in
  c)
    iex -S mix
    ;;

  *)
    iex -S mix phx.server
    ;;
esac

Then just ./dev to start the dev server.

For production is dependent on how you deploy, of course.

This is great. Thank you.

For production I use Fly.io. You can set “secrets” with their cli and on their website.

Or you can create an additional config file that you will add to gitignore and import from dev.exs or test.exs.

Is that was dev.secrets.exs was/is?

I mean there is no convention, but yeah, I’ve seen this used in a few projects.

I’ve seen it around also.

I got the impression that it used to be generated in Phoenix apps in a previous version of the phx generator. See for example here: https://stackoverflow.com/q/68239156.

But thanks again.

My 2c: I tent to prefer explicitness for env vars, rather than having things magically get loaded. I’ve seen and used this mechanism before:

export $(cat .env | xargs) && mix phx.server

direnv works well, but assumes folks have it set up (most do). The above is more explicit in my opinion. I don’t mind the verbosity, mostly due to me rarely having to type that out (always on a readme or in a shell history somewhere).

When working with others, there is usually something on the readme that will help (including yourself when you forget ) As far as the mechanics:

• There is usually a .env.example that is committed to the repo (example)
• an entry for an .env file in .gitignore (example)
• instructions to create your .env file in the readme (example)

If you don’t have a lot of env vars, I’d start with SOME_VAR=your_var mix phx.server and build from that. Then, consider the above if that sounds interesting.

I don’t know why I never thought of this—it seems so obvious, lol.

The dev script still comes in handy, at least for one project, where I need to start up multiple nodes. Of course, Docker is probably the “real” answer there, but I’m stubborn. Maybe there is another way? Though this is getting a little off topic of purely ENV vars.

I use (and love) direnv, but for working with others, I find that dotenvy is a good solution with less friction than direnv.

It’s another dependency, but it gets rolled in with the others when you run mix deps.get. Plus it works in all environments, instead of only ones where direnv is installed (CI, shared dev boxes, etc.).

I’ve encountered the custom config.exs strategy mentioned by @D4no0, and I’m not a fan of the concept. Dotenv files are closer to a “universal” configuration system, so that’s a big plus for me. It allows me to share a config system between my Elixir project, my Docker Compose config, etc.