docker run doesn't pull down latest image if the image exists locally #13331

mlehner616 opened this Issue May 19, 2015 · 52 comments


None yet

docker run should have an --pull or --update option to pull down the most up to date version of an image tag, then run. The behavior should match docker build.

See #4238


I think it would be consistent with docker build --pull, on the other hand; the --pull flag had to be implemented because for build there's no alternative way to deal with this, see #4238 (comment). For docker run, this would work: docker pull myimage:tag && docker run myimage:tag

@unclejack you implemented this for docker build at the time, any thoughts?


I am actually using this work-around and generally agree. However, it comes down to UX and consistency. The very same argument could be made for the --no-cache flag where you could just docker rmi myimage:tag && docker build -t myimage:tag . So why does --no-cache exist? While they appear to be effectively doing the same, it's not necessarily clear to the user if docker is performing other optimizations with the --no-cache flag set that wouldn't happen using the workaround. A simple flag to pull is a lot cleaner.


I agree on the UX perspective. But we need to prevent adding features "just because we can". Not entirely against, so don't give up hope yet. Let's see what others think.

Wrt docker rmi myimage:tag && docker build -t myimage:tag .. I don't think that's comparable. Doing that won't work if the old myimage:tag is still in use by a container, while --no- cache does. But I understand why you're comparing.


IMO this is a good indication that tags should be immutable -- especially once caching mirrors start to come into play, the behavior of changing tags becomes incredibly complex and hard to manage.

Additionally, one of the "big selling points" of Docker is that when I docker run myapp:v3.1.4, I get the exact same image as anybody else doing so. Mutable tags breaks this promise. Anecdotally, we already were bitten by this once when an upstream image of etcd overwrote a release tag with a "fixed" version that introduced a regression.


@stevenschlansker I agree, but changing tags to be immutable will not be possible without causing a serious BC breaking change.

However, #10740 and #11109 added support for referring images by digest, which does make this possible.


I'd really like to see this feature too. After rebuilding, I'd like to send a single docker command to remote hosts to start a container, but currently I have to send two: docker pull and docker run.

I found it surprising that docker didn't check for new versions by default. Currently, if the image doesn't exist, it pulls the newest version but from then on it doesn't check or do a pull. Was it done that way for performance reasons?


I found it surprising that docker didn't check for new versions by default. Currently, if the image doesn't exist, it pulls the newest version but from then on it doesn't check or do a pull. Was it done that way for performance reasons?

I think this was discussed at some point, but (if I recall correctly) there were a number of reasons;

  • If I have a locally built image (foobar:latest), and want to test it before pushing, automatically pulling that image from the registry would overwrite the local image.
  • Performance; pulling for each run can have quite an performance impact.
sielaq commented May 29, 2015

@mlehner616 has mentioned

docker run should have an --pull or --update option

which imply that user have to use this option by purpose (it would not be a default option)
and have to deal with any consequences
(so mentioned by @thaJeztah reasons are valid, but if optional and documented - not so important).

This option is very needed,
imagine that we have to deal with hundreds docker slaves
if you prefer "consistence of images" over "speed",
then performance can be solved with local registry.

Sync problem we have solved using mcollective or consul exec to trigger docker pull
whenever new image is released - but not everyone have/use those tools.


@thaJeztah Yes, I can understand now why it was done this way by default, but it was surprising at first. Docker run might get you the latest image or it might get you a year old image, you can't tell.

rbair23 commented Jun 12, 2015

I was just bitten by this. From an API perspective, the mistake the Docker team made was adding the shortcut to "run" to auto-pull images. The problem is that pulling on "run" becomes a modal operation. How the run command behaves w.r.t. pulling images has 2 modes: it behaves one way if the image has not been previously pulled and another way if it has. This of course is not naturally visible in the API -- you have to read documentation (or spend time debugging as I did and hit the internet) to learn about this mode in the API.

If the run command never auto-pulled, then the API would no longer be modal and it would be predictable (yes the simple intro example is 2 lines now instead of 1 but everybody knows what is going on and how things work and that is a really big deal for usability).

Or you have to make it so that by default "run" always pulls. I can see both reasons that @thaJeztah gives as good reasons not to want to do this.


ping @duglin @tiborvass @unclejack (just some random names, sorry) wdyt? I think this is a reasonable request that brings a friendlier UX and parity with docker build --pull.


Just my 2Β’, how exactly is docker pull image && docker run image supposed to work with Swarm? I really need a way to pull the new image as part of the run command.


@rbair23 Actually the API does not automatically pull, this is strictly a client-side implementation, and the right one IMO.

To get around this (and in general is good practice anyway), people should take advantage of the new ability to specify an image via it's content addressable digest.
Though the UI (both in Hub and the CLI) could be better here, it's a great feature.

rbair23 commented Jun 12, 2015

@cpuguy83 I was using API in the general term applying it to the programming interface exposed by the 'docker' command, not the REST API.


@cpuguy83 I got around this by going though each Swarm node and running docker -H $host pull <image> prior to the run, but if I can specify a sha1 digest then that might actually be better. Thanks.


@thaJeztah I think this is not a feature, it's a bug. With the ongoing trust efforts I hope that this will be resolved.


@tiborvass more an "omission"; I think the default behavior does make sense (see #13331 (comment)), but adding a --pull option is something that needs to be added.

Now that you completed the "docker daemon" PR, are you perhaps interested in creating a PR? πŸ˜‰

Wrt the reference to "trust"; would that mean that on every build, Docker should pull / verify the image?

ledjon commented Jul 30, 2015

I'm not really concerned if it is part of default behavior or a --pull parameter, but I really think there should be a way to do this as part of one command. Perhaps even just spit out a message saying "I am starting this container, but be aware that this is not the latest. use --pull to get the latest"

Just my thoughts on it.

andrerom commented Aug 6, 2015

+1 on this, and +1 on adding this to docker-compose where you just like build don't know about external deps.

coderfi commented Aug 8, 2015

--pull would be huge!

It is too cumbersome, for every Dockerfile, to:

  • figure out what the base image is (awk the FROM line? hard code it in your build script?)
  • issue a docker pull for that if it contains the word 'latest' or is omitted (and/or leveraging additional build/CI systems)
  • then proceed to build

A generic option like --pull, --pull-always, --pull-if-missing, etc. would be much simpler than trying to do the above in every project.

Yes, you could argue: "well why not just specify the image version".

The problem with that is the case when you are maintaining a series of Dockers which build upon each other.

We'd have to roll in a complex build system to propagate base versions down as they get build up ... and that would mean hacking the downstream Dockerfiles each time... (or dynamically generating them? even messier...)

It is much simpler to just use the 'latest' for every FROM base in our Dockerfiles.

andrerom commented Aug 9, 2015

@coderfi This is for docker run, support for pull already exists for docker build which is what you are most likely looking for given you refer to FROM lines in DockerFile.

The need to also add this to docker run is most clear for tools like Docker compose being able to very simple being able to add such features for docker-compose up which would be huge, and is much needed.

bmannix commented Sep 18, 2015

+1 for a --pull flag. This would simplify my workflows.


+1 for a --pull flag


I think this is a easy client only implementation.
docker run will call createContainer which will pull the image.


@coolljt0725 sounds good, are you interested in opening a PR?


PR is coming :)


Thanks @coolljt0725 !

alexw23 commented Dec 3, 2015


Ralf-Te commented Dec 7, 2015

Pls consider increasing priority of the feature request. In my opinion it is more essential as expected at the moment. Let my explain this by the scenario I am currently facing. To carry the issue too far, I will also explain why I think the issue should be flagged as a "bug". :D

I built a docker-based automatically scaling environment, where Amazon ECS controls the docker container placement on the docker hosts dynamically (autoscaling docker containers on auto scaling EC2-Instances). This system is running a production environment!
Because containers are launched dynamically on-demand its critical if old images are used for one or another container. Referring to the issue discussed here we encountered several states of the overall application hard to debug.
It is essential and very cumbersome to manage a cleanup of "n" docker hosts before the deployment of "m" docker containers in such a dynamic environment.
Especially on platforms like Amazon ECS, etc. where a cloud provider has already built up complex processes and thus is restricting its user to defined patterns the topic, becomes more critical.
For us the issue is limiting us in our possibilities even if automated and also having a high degree of effort to automate/test/monitor/maintain.

As I said, I'd like place a little provocation. πŸ’ƒ
Pls don't feel annoyed, but challenged in your creativity or just don't mind. It's my 2 cent on the issue ;)

Docker should deliver consistency in strictly verifying local state against a defined target state.
From the perspective of a production environment, the --pull option should not be an option it should be the default behavior. This is contrary to the history of docker having its root in local development (Tthis is what i perceived so far from docker and thus why I understand that theirs a fundamental debate on this feature).
However, from my point of view, "dev" should be the mode explicitly called, not "prod" as interpreting --pull as default behavior for "prod" in order to deliver strict consistency in operation. Its what i would expect and thus not have to enable additionally. I'd like to have a diff to "prod" in "dev" to emphasize the difference of "dev" in comparison to "prod" clearly, even if the command line or script is a few lines longer.

cpuguy83 commented Dec 7, 2015

@ralf-te fist let me just say I am +1 for adding the --pull flag (there is already an PR for this, see above).

In terms of default behavior in prod, I think this is wrong and would encourage people to use content addressable image names (available since 1.8) instead. This would remove the need for using such a flag since you either have the image or you don't since you are referencing a checksum value instead of a friendly name.


pull && run on swarm nodes will be very slow and error-prone, suppose we have a 100 node swam cluster, pulling an image will be really time consuming, and there will always the case some of the node failed to download the image. I agree with @stevenschlansker that tag should be immutable, once create, never change. But on the other side when we doing cd in our daily development lots of useless image will be created if we create new tag for every build. Any good idea? I'm currently using pull && run for my develop branch and immutable tag for release branch.


Yeah just been stung by this. Couldn't understand why devs were pulling old images despite shared run script appending :latest to the image tag. The behavior between first run and later runs is inconsistent. Will be source of endless problems imo.


@dominicwilliams using :latest is most certainly incorrect.
You should use a real pinned version, or the content addressable ID (the later just being a lazy-person's pinned version identifier)

GordonTheTurtle commented Apr 5, 2016 edited


The best way to get notified of updates is to use the Subscribe button on this page.

Please don't use "+1" or "I have this too" comments on issues. We automatically
collect those comments to keep the thread short.

The people listed below have upvoted this issue by leaving a +1 comment:


mimmus commented Jul 15, 2016

We deploy our images via systemd which doesn't like long running processes such as docker pull in the ExecStartPre fields and we have a few images, so I don't want to have to have a second service file just to pull the images first. A simple --pull or --update would be great.


--pull +1

yaziG commented Aug 10, 2016


bean5 commented Aug 10, 2016

Unfortunately, even if you use --no-cache, you are affected by this. This lack of pulling makes it really easy for builds to differ between machines, particularly Jenkins slaves, especially when one slave is much older than the other. Automated and non-automated (developer) builds are affected by this.


@bean5 if you're having that issue for docker build, then there's already --pull flag, however if you need builds to be exactly the same, you should use docker content trust, or refer to images by digest, e.g.:

FROM alpine@sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a


docker run image@sha256:......

Alternatively, docker pull image && docker run ... should do the trick if you want to always pull.

This issue is still something we want to address, but last PR opened for this, there's was no consensus on design yet; see #16609

bean5 commented Aug 10, 2016

@thaJeztah thanks for that!

bean5 commented Aug 10, 2016

Running the following on a cron may be appropriate for some uses: docker images --filter "dangling=false" --format "{{.Repository}}:{{.Tag}}" | xargs -L1 docker pull.


It would be also cool see that flag on restart, so do that:

docker restart --pull container_name

instead of:

docker stop container_name
docker rm -v container_name
docker run --name container_name …

The problem there also what I should remember or store somewhere previous run options.


@Hubbitus it's unlikely that will be implemented for docker run, but you can find similar functionality in docker service update, which does exactly that




@krzyzacy Also click the thumbs up emoji on the OP.


@sunshineo I need a :-| emoji


i really need this feature. +1

databill commented Jan 4, 2017

+1 for this feature

hylandm commented Jan 24, 2017

A force pull would be very useful. +1

vadyalex commented Feb 2, 2017 edited

I strongly agree that tags should be immutable.

An alternative approach may be to have a convention that "latest" tag or rather dev/unstable/snapshot should be auto-fetched from the Docker Hub if image checksum differs.

Similar approach has Maven regarding artifacts that have -SNAPSHOT in the version number.

xussof commented Feb 21, 2017




Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment