With Bitnami moving older container images to the Bitnami Legacy repository on August 28, 2025, customers may see failures pulling images during upgrades if their Helm charts reference images that are no longer in the main catalog.
As part of working with impacted software vendors, we’ve determined two possible workarounds with KOTS to help mitigate the severity of the impact on affected end customers.
Workarounds
1. Upgrade to KOTS 1.126.0+ (Online Installs Only)
In 1.126.0 (released August 15, 2025), KOTS introduced an improvement that helps reduce issues with stale versions:
When checking for application updates, KOTS now automatically refreshes the metadata (version labels, release notes, and required status) for pending releases in the same channel as the currently deployed version.
This makes it easier for customers to keep their release metadata up to date and reduces the likelihood of needing to manually reprocess versions.
- This feature is available for online installs only.
- Airgap installs are not impacted since images are stored in the airgap bundle and get pushed to the on-prem registry. However, vendors may encounter airgap build failures if the source images are no longer available upstream.
Example Bitnami handling use case: You can replace formerly required bitnami-impacted releases with new non-bitnami-impacted required releases. Changing the “required” status of a release, or any other release metadata you update for that release in Vendor Portal will now be fetched and updated by KOTS. You can even change a release’s title or release notes to “Do Not Use This Release”. Once your customer updates to KOTS 1.126.0 or higher, and then “checks for new application versions”, KOTS will now refetch all release metadata for releases newer than deployed.
2. Patch affected release versions with Kustomize (Available Only with kots.io/v1beta1 and plain kubernetes manifests)
We’ve had some questions come up about how patches (via kots download / kots upload) behave when customers upgrade through versions impacted by the Bitnami image changes.
Key Behavior to Understand
- Patches apply at download time, not deploy time.
If a version has already been downloaded, a later patch won’t retroactively apply to it. - If the affected version has already been downloaded, it must be patched individually.
- If the affected version has not been downloaded yet, and the version prior to it was patched, then the patch will automatically carry forward when the new version is downloaded.
You can apply patches to impacted releases using Kustomize as described in the docs:
Patching Applications with Kustomize
Important Note:
For Helm charts deployed with version kots.io/v1beta2 of the KOTS HelmChart custom resource, editing the downstream Kustomization files before deploying is not supported. This is because KOTS does not use Kustomize when installing Helm charts with the kots.io/v1beta2 resource.
Example Bitnami handling use case: Utilize a kustomize patch to rewrite a release image path such as proxy.replicated.com/proxy/appname/bitnami/redis to proxy.replicated.com/proxy/appname/bitnamilegacy/redis which may prevent a hard image pull failure while the bitnami legacy transition repo remains available. Given all previously download releases may need to be patched, consider providing this as a script to your end customer until you are able to get them on the latest KOTS and newer non-impacted versions of your software.
Next Steps
- For online customers, encourage upgrading to KOTS 1.126.0+ to take advantage of the new automatic metadata refresh.
- For Helm v1beta2 charts, continue patching affected versions manually as needed.
- Share your experiences and feedback here so we can continue improving the upgrade path.