Dockerfile ARG ↔ ENV Converter
ARG defines build-time variables; ENV defines runtime variables. Common pattern: declare both so you can override at build OR runtime. This converter takes a list of ARG/ENV directives and converts between forms.
ARG vs ENV quick reference
| ARG | Build-time only. Available during docker build. NOT in the final image's environment. |
|---|---|
| ENV | Both build-time AND runtime. Set in the image, available to processes inside the container. |
| Common pattern | ARG VERSION=1.0ENV VERSION=$VERSIONLets you override at build ( --build-arg VERSION=2.0) and the value persists at runtime. |
| Secrets | Never use ENV for secrets (persisted in image layers). Use Docker BuildKit secrets or runtime env-files. |
How to use the Dockerfile ARG ↔ ENV Converter
Paste your existing ARG or ENV lines. Pick what to convert to. The output handles defaults (ARG =value) correctly.
ARG versus ENV in a Dockerfile
ARG and ENV look interchangeable in a Dockerfile but live in different scopes: ARG values exist only during docker build and vanish from the final image, while ENV values are baked into the image and visible to every process in the running container. Mixing them up means a build variable that is unexpectedly absent at runtime, or — worse — a secret put in ENV that is now permanently readable in the image layers.
This converts a list of ARG or ENV directives between the two forms, including the common pattern of declaring both (ARG for a build-time default, ENV to persist it at runtime). It handles the scope mechanics; to build a full Dockerfile around these directives use the Dockerfile generator, and for runtime configuration that should never be baked into an image, keep values in a .env file validated with the .env validator.
Common use cases
- Promote a build arg — turn an ARG into an ENV so its value survives into the container.
- Lock a runtime value — convert an ENV to an ARG to keep it out of the final image.
- The both pattern — generate the ARG + ENV pair that allows build- and runtime override.
- Refactor a Dockerfile — move variables between scopes without hand-editing each line.
- Learning Docker — see how build-time and runtime variables actually differ.