`docker run --env-from` option, analogous to the `--volumes-from`

[marsjaninzmarsa]

Description

When running an image via the docker run command you've got the option --volumes-from, allowing you to inherit the passed volumes from the referenced Docker containers. It would be nice to provide also option --env-from, allowing you to - by the analogy - inherit the passed environment variables from other containers, saving the need to redefine them.

[2003Aditya]

Hey @thaJeztah 👋

I’d like to work on this issue.

I went through the Docker CLI source, mainly cli/command/container/run.go, where the docker run flags and container creation flow are handled. It seems like the most logical place to introduce a new --env-from flag.

My rough plan:

• Add --env-from <container> to inherit environment variables from another container.
• Use ContainerInspect on the referenced container to get its Config.Env.
• Merge those envs with any provided via --env, giving priority to explicitly passed ones.
• Pass the merged list through the existing container creation flow — no Engine-side changes needed.

Before starting, I wanted to clarify a few points:

• Should this work for both running and stopped containers, or only running ones?
• Are there any concerns about exposing sensitive environment variables (like secrets) when inheriting from another container?
• Would you prefer a different flag name like --env-from-container for clarity?
• Should this also be available for docker create to keep it consistent with run?

If this direction sounds good, I can start with a small prototype and open a draft PR for discussion.

Thanks — looking forward to your thoughts!

[thaJeztah]

Yeah, I'm not yet sure if this is something we'd want to add; security is definitely a concern here, and one of the reasons we've deprecated the legacy --link option on the default bridge (which would leak environment variables to other containers).

Is there a specific problem that's attempted to be addressed by this feature? It may be best to get more context on the proposed change and what problems it's resolving.

Other options, like docker compose would allow for environment variables to be defined in a compose-file, which could be inherited, or shared between services defined in the compose file, which could be a solution for some use-cases.

[2003Aditya]

@thaJeztah Thanks — that makes sense and I appreciate the security callout.

I’ll take a step back and dig into the background (legacy --link behavior and why it was removed) and verify whether docker compose or an .env-based approach already covers the common use-cases I had in mind. My intent was convenience for non-secret configuration sharing (short-lived/local workflows), not to reintroduce a secret-leak risk.

A couple of possible, safer variants I’ll evaluate and can prototype if you think any are reasonable:

• only allow --env-from for non-running/stopped containers (so it’s deliberate and less likely to be abused)
• filter out likely-secret variables by name (e.g. *_SECRET, *_TOKEN, PASSWORD, etc.)
• make it opt-in/experimental behind a feature flag with a clear warning
• or recommend docker compose / .env as the preferred pattern and document that use-case

Before I start a prototype, would you prefer I:

• explore a short prototype showing how the filtering/opt-in idea might work, or
• first document a design proposal comparing the approaches (security trade-offs + UX) so we can decide whether this is worth implementing?

I’ll start by reading the --link history and compose env handling, and report back with findings. Thanks again for the pointer — I want to be careful here and not reintroduce a known class of vulnerability.