You could always run the `env` command inside of the container to get all of the set environment variables. Then you can define, reconstruct and run your contai

You could always run the `env` command inside of the container to get all of the set environment variables. Then you can define, reconstruct and run your container with whatever args you want. But yeah the env_file approach is the way to go here. I've been using Docker in production since 2015 and never ran into your use case. I always had an .env file ready to go that was loaded in with env_file and always had control over being able to run the container with whatever command I see fit. And in cases where I have no control over how things are run (like Heroku), environment variables still work because a ton of hosting platforms expect you to set and read them for various configuration. And you can also commit an example env file to git with no secrets so developers can `cp .env.example .env` to get going in 1 second. The environment variable pattern is incredibly standard in the world of web dev.