4.2.4.2 ADD Remote URLs

ADD remote URLs is the capability that lets ADD fetch a file directly from a network location during the build, downloading it as part of the build process rather than requiring it to already exist locally in the build context.

Fetching a File From a URL

ADD accepts a URL as its source, retrieving the file from that location and placing it at the specified destination inside the image.

ADD https://example.com/dataset.csv /app/data/dataset.csv

This downloads the file during the build, with the resulting layer containing whatever was retrieved at that moment.

Why This Behavior Is Generally Discouraged

Because the downloaded content can change over time at the same URL, builds using this feature are not fully reproducible — running the same Dockerfile again at a later date could retrieve different content, undermining build consistency.

ADD https://example.com/latest-release.zip /app/

If the content at this URL changes after a release, rebuilding the image later would produce a different result than the original build, despite the Dockerfile itself being unchanged.

Preferred Alternative: Explicit Download With Verification

A more reproducible approach downloads the file explicitly through a RUN instruction, allowing a checksum or other verification step to confirm the downloaded content matches what is expected, rather than trusting whatever is currently being served at a URL.

RUN curl -fsSL https://example.com/dataset.csv -o /app/data/dataset.csv \
    && echo "expectedchecksum  /app/data/dataset.csv" | sha256sum -c -

This approach fails the build explicitly if the downloaded content does not match an expected checksum, rather than silently proceeding with potentially different content.

Why Avoiding This Feature in Production Dockerfiles Is Common Practice

Because of the reproducibility concerns it introduces, many Dockerfile style guides recommend avoiding ADD's remote URL fetching capability for production builds, preferring explicit, verifiable download steps instead.

docker build --no-cache -t myapp .

Forcing a fresh build without cache is one way to surface whether a Dockerfile relying on this feature would actually produce different results over time.

Why This Matters

Understanding both the convenience and the reproducibility risk this capability introduces is essential for deciding when, if ever, it is an appropriate choice within a Dockerfile.