Plan for two separate cutovers
Zarf’s maintainers announced version 1.0 on November 9. The tool bundles software for Kubernetes environments that cannot pull dependencies directly from the internet. Teams often build those bundles on a connected system and deploy them elsewhere, so the two sides of the workflow can hit different compatibility deadlines.
The new package definition format is v1beta1. The maintainers say the older v1alpha1 format remains supported through May 2027. Starting in February, jobs that create, publish or sign legacy packages will need an explicit opt-in. Deployment jobs will need that opt-in starting in March. Teams can use the gap to identify which build pipelines and disconnected sites still depend on the old format.
Test the rollback before upgrading
The release also changes how Zarf records deployed packages in Kubernetes. The project says pre-1.0 clients cannot read the compressed records written by 1.0. Keep that in mind if an offline site has several operator workstations or a recovery image with an older client. CGH’s reading of the compatibility notes is that keeping an older binary alone is an incomplete rollback plan.
For fresh cluster initialization, the default package now accepts settings through values. The project says new installations inherit the cluster’s default storage class unless operators set one. Existing upgrades retain their storage class. A rehearsal should cover whichever path the site actually uses.
Release availability
The stable release assets are public on GitHub under an Apache 2.0 project. The sources specify no purchase price or regional rollout for the self-managed software. CGH checked the release and documentation without testing an installation or a rollback.