What you can do today to ensure your clusters are not impacted by the retirement of `gcr.io/istio-release` and `registry.istio.io`.
In a previous blog post, we announced that Istio will retire the gcr.io/istio-release
container registry in late 2026 and switch to registry.istio.io/release
as the new home for Istio images.
The original design was that registry.istio.io/release
would be a Cloudflare worker that proxied requests to any OCI-compliant registry, allowing us to switch registries without any interruption to Istio users.
Currently, we proxy to gcr.io/istio-release
.
As mentioned before, we are retiring gcr.io/istio-release
in late 2026.
With a limited infrastructure budget for 2027, we plan to use free container hosting platforms to host Istio images.
Unfortunately, proxying through Cloudflare means that we funnel all traffic through a few egress IPs, triggering rate-limiting policies on free container hosting platforms.
After discussions with hosting platforms regarding this limitation, we have made the difficult decision to retire registry.istio.io/release
.
We will keep hosting registry.istio.io/release
until late 2026.
As always, we will publish Istio images to docker.io/istio
and plan on publishing to mirrors in the future.
Am I affected?
By default, Istio 1.30 installations use registry.istio.io/release
as their container registry.
All other Istio versions default to docker.io/istio
.
You can check whether you are affected by running the following:
$ kubectl get pods --all-namespaces -o json \
| jq -r '.items[] | select(.spec.containers[].image | startswith("registry.istio.io/release")) | "\(.metadata.namespace)/\(.metadata.name)"'
The above command will list all the pods that use images hosted on registry.istio.io/release
.
If there are any such pods, you will likely need to migrate.
Note that we will still retire gcr.io/istio-release
in late 2026 as mentioned in the previous post, so you should check for gcr.io/istio-release
usage too.
What to do today
Although we plan to keep images available on registry.istio.io/release
and gcr.io/istio-release
until late 2026,
we suggest you migrate to docker.io/istio
as soon as possible.
Even better, configure a pull-through cache to ensure maximum availability.
Using istioctl
If you install Istio using istioctl
, you can update your IstioOperator
configuration as follows:
istiooperator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
...
hub: docker.io/istio # or your pull-through cache
Everything else can stay the same unless you reference `gcr.io/istio-release` images elsewhere
And install Istio using this configuration:
$ istioctl install -f istiooperator.yaml
Alternatively, you can pass in the registry as a command-line argument
$ istioctl install --set hub=docker.io/istio # or your pull-through cache
Using Helm
If you use Helm to install Istio, update your values file as follows:
...
hub: docker.io/istio # or your pull-through cache
global:
hub: docker.io/istio # or your pull-through cache
Everything else can stay the same unless you reference `gcr.io/istio-release` images elsewhere
Then, update your Helm installation with your new values file.
Facts Only
* Istio will retire the `gcr.io/istio-release` container registry in late 2026.
* The new registry home is planned to be `registry.istio.io/release`.
* The original design used `registry.istio.io/release` as a Cloudflare worker proxying requests to OCI-compliant registries.
* Current proxying routes traffic through `gcr.io/istio-release`.
* A decision was made to retire `registry.istio.io/release` due to limitations in proxying free container hosting platforms.
* `registry.istio.io/release` will remain hosted until late 2026.
* Istio 1.30 installations use `registry.istio.io/release`.
* Other Istio versions default to `docker.io/istio`.
* Users are advised to migrate to `docker.io/istio` immediately.
* A check can identify pods using images from `registry.istio.io/release`.
Executive Summary
Full Take
The migration narrative illustrates a tension between an idealized architectural goal—seamless registry switching—and the practical constraints of resource limitations and operational realities. The initial design prioritized abstract flexibility, but the execution revealed a point where infrastructure cost (proxying through Cloudflare) directly conflicted with the intended flexibility when interfacing with constrained free hosting environments. This forced a pragmatic retreat from the ideal state by retiring one component. The implication is that architectural elegance must yield to resource reality in the deployment of complex systems.
The pattern observed involves setting an ambitious, future-facing technical goal, then introducing immediate, tangible constraints (budget limitations), and resolving the conflict by backtracking on the planned evolution rather than redefining the initial premises. This suggests a historical tendency where operational necessity dictates architecture, rather than the reverse. The warning issued to users—to migrate away from the specific image references—is not just a technical instruction but a demand for cognitive sovereignty over infrastructure dependencies. The core pattern here is the management of deferred risk; postponing the unavoidable structural change creates an environment where current, potentially unstable, dependencies are maintained under the guise of temporary coexistence.
What assumptions underpin the suggestion to migrate immediately? It assumes that the immediate shift to `docker.io/istio` offers sufficient resilience, irrespective of the historical context of Istio's design philosophy. What is the cost of maintaining the dual path for a year or two while simultaneously managing migration pressure? When systems are designed with perceived permanence, the erosion of those assumptions due to external constraints highlights the fragility of abstract definitions when faced with concrete resource allocation. What steps should be taken to ensure that future planning incorporates infrastructure constraints as primary design parameters, rather than as secondary mitigation factors?
Sentinel — Human
This text reads like official internal technical guidance explaining a planned infrastructure migration, characterized by precise technical detail and direct, actionable instructions.