Istio 1.31 changes where release artifacts are published
New Istio artifacts leave the former Google-hosted endpoints, with separate destinations for images and charts. The transition also changes signing-key planning and tests hidden download dependencies.
An installation can name the correct Istio version and still ask a registry that will never receive it. Istio 1.31 stops publication to the former Google-hosted artifact endpoints, including gcr.io/istio-release and registry.istio.io. The release moves charts and other artifacts to different destinations. This affects the configuration that obtains the software before any mesh component starts.
The August 21 infrastructure announcement explains the reason. Changes in the project's funding model led Istio to migrate its infrastructure from Google Cloud Platform to Amazon Web Services. Container images will publish to Docker Hub, while conventional Helm charts and other release artifacts use blob.istio.io. OCI charts use GitHub Container Registry.
After five years with Istio, I regard installation dependencies as part of the cost of operating its additional distributed system. Workload identity and uniform traffic policy justify that cost in the right fleet. They do not make the machinery for obtaining a replacement proxy incidental. The hosting change affects whether a node or deployment process can obtain the exact version that configuration declares.
Publication and availability change on different schedules
The release announcement says that artifacts from 1.31 onward will no longer publish to the old endpoints. The infrastructure post separately schedules removal of old locations in December. Those are different events. A repository can remain reachable while lacking a newly requested release, and a repository containing an older release can later become unavailable.
The destination therefore matters even before complete decommissioning. A pipeline that continues requesting new releases from an old location will not be repaired by waiting for a mirror to catch up. The project explicitly says the new minor release will not publish there. Configuration needs to select the supported destination for the artifact type.
The conventional chart repository is https://blob.istio.io/istio-release/charts. OCI charts use ghcr.io/istio/release/charts. The infrastructure post says other artifacts, including packages, istioctl, source, and SPDX documents, are available under https://blob.istio.io/istio-release/releases. A search limited to container-image references can therefore miss another active dependency on the retired storage host.
This is also why changing only a release version is insufficient. Artifact type and source location are inputs to the installation workflow. A container image reference, a Helm repository, and a package download script can all name Istio while obtaining different release material from separate services. Each needs the destination that the project documents for that material.
A recent default does not imply continued hosting
The Istio 1.30 announcement made registry.istio.io the default image registry. The 1.31 announcement includes that hostname among the publication locations being retired. An operator following the previous release's default can therefore still have an infrastructure migration to make. The sequence is documented in the project's own release material.
This is a useful distinction between a stable configuration value and a stable service arrangement. A chart can preserve an explicit registry override across upgrades. That retained value is not evidence that the project continues publishing new artifacts there. The release process and the installation's stored values have separate lifecycles.
The infrastructure announcement recommends Docker Hub or a pull-through cache for images. A cache changes the location the installation contacts, but its upstream configuration still needs a supported source. An internal image hostname can conceal a dependency on a retired external registry. The configuration responsible for populating the cache belongs in the same migration inventory as the workload's image reference.
For my use, a declared installation should explain both the version and the source of the release material. That includes automation which refreshes a mirror and verification software which checks signatures. Reproducibility needs those operations to keep working when the original upstream hosting arrangement changes.
Temporary outages target hidden consumers
The project schedules temporary shutdowns of the Google-hosted locations before final removal. As of August 31, the first announced window is September 15, from 15:00 to 16:00 UTC. Later planned windows extend the interruption. The purpose is to make remaining dependencies visible while the project still has time to communicate the migration.
These are announced future tests, not evidence that any particular installation has already failed. Their relevance is the path that an otherwise quiet dependency may use. A running proxy and a fresh installation do not make the same artifact requests. The latter has to obtain release material that the former already has available.
A successful upgrade using locally available artifacts also answers a narrower question than a fresh download. The hosting announcement covers images and other release inputs. Checking the path that supplies those inputs is necessary to understand whether the installation has moved. A deployment's current health cannot establish which external host its next replacement will contact.
The temporary tests also distinguish publication migration from old-release access. Even an installation pinned to an earlier version can retain a dependency on a host scheduled for removal. Pinning protects the requested version from changing. It does not preserve the availability of the service asked to supply that version.
Signature verification has its own transition
The infrastructure announcement also describes a signing-key change. The old public key remains at https://istio.io/misc/istio-key.pub, while a new public key is available at https://istio.io/misc/istio-key-v2.pub. For 1.31.0, the published expectation identifies that release as using the old key. New hosting and a new verification key are therefore related migration work without being the same version boundary.
That distinction matters for an installation enforcing image verification. Updating the registry location does not automatically update the trusted signing material. Conversely, replacing a trusted key without accounting for the version being installed can reject an otherwise expected artifact. The project publishes key expectations so those decisions can remain explicit.
The announcement does not justify disabling verification to make the hosting transition easier. It supplies the public-key locations and distinguishes their intended use. A release process can migrate its distribution service while retaining a verification requirement. The installation workflow needs to reflect both inputs rather than treating a download failure and a signature failure as interchangeable symptoms.
The published destinations also separate conventional Helm repository access from OCI access. A conventional repository consumer needs the blob-hosted chart repository, while an OCI consumer needs the GitHub Container Registry path. Replacing a hostname without accounting for which distribution form the automation uses can leave the download procedure incorrect. The migration announcement gives both forms because the project continues distributing both. Internal installation documentation should preserve that distinction, including the configuration used by automated chart updates, so that a later version change does not restore an obsolete repository address.
The release also expands agentgateway's role
Istio 1.31 adds the istio-agentgateway-waypoint GatewayClass. This extends the experimental gateway-only support introduced in 1.30 to an agentgateway waypoint role. The change notes also describe ListenerSet handling and mutual-TLS connectivity corrections for agentgateway backends.
One connectivity correction concerns raw TCP routed to sidecar-injected backends. Previously, those connections used plaintext where Istio mutual TLS was needed. Server-first protocols could hang, and backends enforcing strict mutual TLS were unreachable. This is an implementation compatibility issue with the mesh's backend expectations, separate from the GatewayClass that selects the proxy.
The waypoint addition makes the hosting change more consequential for anyone evaluating the new role. Configuration can select a newly supported implementation, but the node must still obtain its release image from a publishing location that contains it. Feature configuration and artifact delivery meet at that installation boundary.
Weighted waypoint canaries are another addition in the release. A service or namespace can reference a primary and canary waypoint, with an annotation controlling a share of in-mesh connections. The announcement describes gradual rollout without client changes. That supplies a traffic-management mechanism, while artifact sources and signing keys remain part of preparing the actual waypoint instances.
The new capabilities make the release worth evaluating, but the mandatory hosting work has a wider population. Installations that do not adopt agentgateway still need supported sources for their existing components and tooling. The migration record needs to account for fresh artifact retrieval and verification, including chart repositories and mirrors whose external dependencies are not visible in an ordinary workload manifest.