By default, it won't overwrite existing environment variables as dotenv assumes the deployment environment has more knowledge about configuration than the application does. To overwrite existing environment variables you can use Dotenv.overload.
A practical use case is if I am running my application in dev environment standalone as well as containerized. I override the redis connection env variable in my docker compose file to be different from .env file (used by standalone version). By virtue of this behavior my connection to redis fails for the containerized version.
It looks like when starting puma it looks for a
.env
file and loads all the environment variable without checking for existing ENV variables here: https://github.com/puma/puma-dev/blob/master/dev/app.go#L243This in turn overrides any ENV variables which might have already been set differently for various reasons (in my case via a docker compose file). This is in contrast with default dotenv behavior: https://github.com/bkeepers/dotenv#why-is-it-not-overriding-existing-env-variables
A practical use case is if I am running my application in dev environment standalone as well as containerized. I override the redis connection env variable in my docker compose file to be different from
.env
file (used by standalone version). By virtue of this behavior my connection to redis fails for the containerized version.