GitLab: Container Registry

Long-Standing Issue: Unknown Error Pulling Private Images from GitLab Container Registry

In early 2020 the GitLab Container Registry was still new. Quay.io was the mature, proven choice. I was running production Kubernetes workloads and wanted to consolidate on GitLab for source, CI, and images in one place.

It didn’t go smoothly. Private images pushed by GitLab CI would deploy once, then fail on the next rollout with denied: access forbidden. Same clusters, same ServiceAccount, same deployment pattern. Pointed at a private Quay.io repository, everything worked.

So I documented it and filed it with GitLab in February 2020.

Full details: gitlab.com/gitlab-org/gitlab/-/work_items/205936

This hard-to-debug issue, related to the GitLab Container Registry, is a good example of the complexity introduced when different implementations claim to provide identical features. In this case, the Quay.io offering and the GitLab offering have a notable behavioral difference, despite both presenting as standard OCI-compatible registries.

Four Years Later

As of March 2024 the issue is still open.* Engineers running EKS, GKE, LKE, and self-hosted GitLab have found it, added their own reports, and shared workarounds there. It has become a reference thread for anyone hitting image pull failures between GitLab and Kubernetes.

* Edit, late 2026: the issue is still open.

Why This Matters to My Clients

Two registries can both claim to be standard and OCI compatible and still behave differently in production. Finding that kind of gap early, proving it with evidence, and keeping workloads running while the vendor catches up is the work I do.