Kube 1.34 and 1.35 upgrades, Terraform provider improvements, Standard Kube labels, Topology spread across zones

Hey Team,

This release focuses on platform stability and scalability. We are preparing the next Kubernetes upgrades, improving Infrastructure as Code workflows, and strengthening how your workloads run in production environments.

Let’s dive in.

🚀 Kubernetes 1.34 and 1.35 upgrades

We are currently rolling out the upgrade of Qovery managed Kubernetes clusters from version 1.33 to 1.34 and 1.35.

Upgrading Kubernetes is not just a version bump. It requires deep validation across every component, Helm chart, and managed service to ensure nothing breaks in production. This is the kind of work that typically consumes days or weeks of engineering time.

With Qovery, your team does not have to deal with that complexity. We handle the full upgrade process for you, safely and progressively, saving hours of operational work and reducing the risk of misconfiguration.

We always start by upgrading non production clusters first. This gives you time to validate your workloads before production is impacted. Once validated, we roll out the upgrade to production clusters in a controlled and safe manner.

We have published a detailed rollout plan with a timeline included in this changelog section

‍

🌱 Terraform provider improvements

We continue to invest in making Qovery fully Infrastructure as Code ready.

The Terraform provider is one of the key interfaces to manage your infrastructure declaratively in Git, alongside the CLI, API, and MCP. It gives teams a reliable and versioned way to define their environments and integrate with existing workflows.

This release includes:

• Reduced noise in terraform plan so only meaningful changes are displayed
• Added support for environment variables as files, similar to the UI

These improvements make Terraform workflows easier to review, safer to operate, and better aligned with real production usage.

You can find our Terraform provider in the official registry.

‍

🏷️ Standard Kubernetes labels applied by default

Resources deployed via Qovery now automatically include standard Kubernetes labels such as app.kubernetes.io/name.

This is part of our approach to integrate seamlessly with the broader Kubernetes ecosystem. Many tools for observability, security, and policy enforcement rely on these standard labels.

By applying them automatically, Qovery ensures your workloads are immediately compatible with your existing tooling, without requiring additional configuration.

‍

‍

🌍 Topology spread across zones

You can now spread your pods across availability zones using a new advanced setting:

deployment.topology_spread.zone

This improves resilience by ensuring your workloads are distributed across zones. If one zone goes down, your services remain available.

To keep costs under control, this feature is designed for production environments and is not enabled for non production clusters by default.

👉 Documentation here

🛠️ Minor updates

• Managed databases: fields not controlled by Qovery can now be safely modified directly in the cloud provider console without causing conflicts
• Builder improvements: deployments now stop immediately when a build hits an out of memory error instead of retrying multiple times
• Terraform native: fixed status display to accurately reflect the current execution state

That is it for this release. As always, thank you for trusting Qovery to run your production workloads.

Talk soon,

The Qovery Team 🚀

‍