Kubernetes 1.32 as default, Azure improvements, improved uninstall flow

Hello Team,

Check out this week’s changelog for exciting updates and enhancements from our team! 🚀

#Welcome, Kubernetes 1.32: the new default version

As part of our rollout plan for Kubernetes 1.32 and 1.33, version 1.32 is now the default for all newly created clusters.

Next week, we will begin the upgrade phase for existing clusters, starting with non-production environments. You can choose to upgrade to 1.32 yourself or wait for us to handle it for you.

Upgrading Kubernetes may look simple, but it requires a month of engineering work to validate and prepare every component across all clusters. Each upgrade involves:

• Reviewing and upgrading all Helm charts for compatibility
• Testing integrations with managed services
• Validating cluster-specific configurations
• Planning and executing phased rollouts for safety

We upgrade non-production clusters first to give you time to validate before moving to production.

#Azure Beta: better credentials management

A few weeks ago, we announced the launch of our Qovery Managed cluster offering on Microsoft Azure AKS (Azure Kubernetes Service), making it easier than ever to deploy and manage cloud-native applications on Azure with zero Kubernetes overhead (Have a look at our official announcement here).

A few customers have been using it so far, and we've already delivered the first improvements to the credentials management!

We now automatically rotate credentials used to access your cloud account. Even if credentials are leaked, they expire within hours, minimizing risk. To avoid unnecessary secret generation, secrets are temporarily stored and reused across operations (e.g., deploy app A, stop app B).

What's coming next:

• Additional security and best-practice configurations to help you pass SOC2 and HIPAA certification
• Integration of Karpenter as an advanced autoscaler as soon as it is officially released for Azure

#Simplified uninstall and delete flow

A few weeks back, we released the uninstall feature, allowing you to delete the remote resource while keeping your Qovery configuration intact. This is extremely helpful when you don't want to waste resources on your Kubernetes cluster but still keep the configuration on the Qovery side without deleting it.

Since the difference between the actions "delete" and "uninstall" wasn't so clear, we have improved the flow by merging the two actions into one and allowing you to decide if you want to keep the Qovery configuration or not.

#Minor Changes:

• Reduced AWS S3 default permissions: the service account created to access the logs via Loki has been reduced, and it can now only target buckets starting with "qovery*".

For the latest news and upcoming features, remember to check out changelog.qovery.com.

As always, we appreciate your feedback and support.

Happy Deploying!

The Qovery Team 🚀