Road to Kubernetes 1.32/1.33, Job output validation, updates on credentials management, Optimising Log article

Hello Team,

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

#Road to Kubernetes 1.32/1.33: upcoming updates

Upgrading Kubernetes is not a simple or instant task. Behind what might look like a routine update lies a full month of dedicated engineering effort.

Every upgrade requires a deep compatibility check across every Helm chart, every system component, and every managed service to ensure that nothing breaks. It means validating countless configurations, planning safe rollouts, and testing for edge cases across all customer clusters, at scale.

This is not something most teams can or should handle alone. It’s exactly the kind of operational complexity Qovery was built to abstract away.

As we do every quarter, we’ve already started preparing for the upcoming Kubernetes upgrades to 1.32 and 1.33. For example, we’ve recently updated Karpenter to version 1.5.1, which is required for Kubernetes 1.32 compatibility.

The actual upgrade will begin next month, and we’ll soon share a detailed rollout plan. In the meantime, everything is being taken care of, so you don’t even have to think about it.

(If you want to understand just how deep this work goes, check out this interview with our CTO, Pierre.)

#Job output validation step and Sidecar migration

With Qovery Lifecycle Jobs, you can generate values, like credentials, connection strings, or resource IDs, that get automatically injected as environment variables into any other service within the same environment.

No need to modify your application code. No need to redeploy. Your services just receive the right data, at the right time.

This is especially powerful when provisioning dynamic cloud resources, such as an RDS PostgreSQL database, where your backend needs the connection string generated by a job script. It all happens behind the scenes.

To make this even more robust, we’ve added a validation step to ensure the output file format is correct. If something’s off, we’ll notify you immediately, so you’re never left guessing.

Previously, we deployed a separate container to fetch this output. Now, we’ve improved this mechanism by using a Kubernetes sidecar container. This simplifies the deployment and improves reliability by aligning better with Kubernetes best practices.

#Updated credentials section

In the last sprint, we released a new cloud credential management view to give you a clearer, safer, and more structured way to manage access to your infrastructure.

Security starts with visibility. That’s why we’ve introduced a simple but powerful improvement: credentials are now split into two sections, in use and not in use. This makes it much easier to spot unused or outdated credentials, helping you reduce attack surface and keep your cloud environments clean and secure.

This change is part of a broader effort to bring more clarity and control to your cloud setup. Next up, we’ll apply the same pattern to Helm repositories, container registries, and Git provider accesses.

#Some good reading: Optimising Logs Interfaces

Rémi from our front-end team recently shared a behind-the-scenes look at how the Qovery engineering team built a high-performance Logs Interface capable of handling thousands of lines of data efficiently.

It’s a great read if you’re curious about UI performance and frontend engineering at scale.

Check it out on our blog.

#Minor Changes:

• Improved permission table display: We have changed the elements ordering, making it easier to read.

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 🚀