Summary

Due to a infrastructure change in a core GCP tool we use to store build images we'll need to implement a build cap of 1100 stored build images.

 

Details

Google Cloud is deprecating and ending support to the tool we use to store build images. This update significantly impacts our costs, requiring us to migrate all build images to a different Google product, which will unfortunately increase our storage expenses by over six times.

To manage these increased costs without impacting the pricing of our product and to affect your development process as little as possible, we're implementing a new build image retention policy. Currently, we retain all build images for every project since its inception. Under the new policy, we will retain the 1100 most recent build images for each project. We'll also not delete:

• Images a service is currently running on, no matter how long ago it was built;
• Build images of the last two successful deployments of a service.

So, for example, if you have a build that is your 1200th most recent build, but it's the image a service in your dev environment is running on, it'll not be deleted until you successfully deploy two more builds to that service in that environment.

 

Expected impact

It's important to understand that this change does not mean you will lose access to your code. This adjustment only impacts the older built images themselves.

In the rare instance you need an older build image, you can easily rebuild it from your existing code. However we expect this to happen very rarely. The choice of 1100 as the new build limit was done after extensive research of over one hundred thousand builds from several customers with different build patterns and was encompassed them all with minimal to none rebuilds necessary.

 

Best Practices to reduce number of builds created

In rare situations this change might require minor adaptations to the workflow. To assist those customers in these scenarios with this transition, we have prepared guidance with recommended configuration changes to manage the number of build images your project produces.

 

Important Considerations for Services Deployed Before December 2024

 

While the migration of build images to the new Google Cloud tool has been completed, there's an important consideration for services that haven't been redeployed since before December 2024.

After May 20th, 2025, these older deployments might face unexpected outages. This is because the underlying pod running the service will eventually lose its reference to the original build image location.

Although your service won't stop running immediately, our Kubernetes orchestration layer might, at some point, decide to restart the pod on a different cluster node. If this happens after the image reference has been lost, the pod will be unable to restart, leading to a potential outage.

The good news is that resolving this is straightforward. A simple redeployment (or even the deployment of a different build) of your service will restore normal operation. This will ensure your service uses the migrated build image and has a valid reference.

We strongly encourage customers who haven't redeployed services since before December 2024 to plan a redeployment at their earliest convenience to avoid any potential disruptions after May 20th, 2025. This proactive step will ensure a smooth transition and prevent any unexpected service interruptions due to pod reallocation.