Overwrite Docker image in GitHub Package Registry

What is the proper way to overwrite a tagged Docker image in the GitHub Package Registry?

I’ve been updating my code consistently for the past hour, yet the image inside the registry (tagged as “latest”) is still from two hours ago.

docker images -a

doesn’t return the name of my image, so I cannot simply delete it before building the new image.


Not working for me too. Looks like a bug.

Same problem on our side. We also cannot pull the specific tag with the error message “tag not found”

Still not working for me.
Pushing latest does not give an error, but tag is not updated.


same issue for me. If I want to update a package I have to give it a new version tag. Interestingly enough, that new package (I consider it a new package since it has a different tag) is uploaded but the existing package (with the older version tag) disappears. Does this mean we also cannot have multiple versions of the same code / package like: app:latest, app:1.0, app:2.0


It seems as though github package registry uses a different logic that the expected from a docker registry.

For a docker registry, like docker hub, when you upload an image with a tag that already exists, that tag is overwritten (like the default tag latest).

Github package registry instead seams to not allow any sort of rewrite, like npm, where you can’t publish the same version twice.

This makes sense for npm packages, since that is how they work. But for docker it doesn’t, since that not how docker images are usually pushed. It’s common practice to have tags whose image gets changed constantly (like latest, or foo:4 which gets updated when foo:4.2 is uploaded)


I think the elephant in the room is that overwriting would basically defeat the purpose of Github’s no-deletion policy for public packages as defined here: 


Not sure if this is its own issue, but for us not being able to delete packages is a dealbreaker - basically it means that ownership and management is transfered to Github while we still are responsible for the public existance of artifacts, yet still Github dictates the process of deleting them.

As such I can not consider the package service that Github is offering and would hope Github reconsiders their stance, as laudable as the “idea” of having relieble packages sounds in theory.


This looks to be the case, which is incredibly frustrating.

As much as they are for the dev community, I’m surprised that this is how they decided the docker repository to work. I really hope they will reconsider this decision.

Any updates on this? We tag by container with semver & latest:

docker build -t docker.pkg.github.com/$GITHUB_REPOSITORY/container_name:${{ steps.get_version.outputs.VERSION }} -t docker.pkg.github.com/$GITHUB_REPOSITORY/container_name:latest .

Then push both tags:

docker push docker.pkg.github.com/$GITHUB_REPOSITORY/container_name:${{ steps.get_version.outputs.VERSION }}
docker push docker.pkg.github.com/$GITHUB_REPOSITORY/container_name:latest

We’re using containrrr/watchtower  which polls the registry for the :latest tag. Since the :latest tag is never overwritten our container never gets swapped out.

If not then we’ll need to write a custom webhook to ping from Actions…

I have currently filled my quota with Docker images…so if I cannot delete them…then what?

Is there an update on this? Docker tags work very differently from other systems and replacing the latest tag is very important. I can see why it’s this way for public packages but currently it doesn’t even replace for private packages. I guess you could run deletePackageVersion but that should be an unnecessary step.

Beware about deleting tho, got to eagerly on one repo and now I’m wating for support to fix it 🤐.

It looks like they’re working on deletion some more, the personal access token scopes have been updated with a “delete:packages” scope https://github.com/settings/tokens