Kubernetes upgrade 1.29/1.30, New advanced settings for ALB, K3s/EC2 Decommission

Hello Team,

It has been a quiet sprint in terms of feature delivery, as our team was enjoying our autumn retreat (check out here with some pictures), Nevertheless, take a look at what we have managed to deliver:

#Product Clusters Upgraded to Kubernetes 1.29 and new version 1.30 upcoming

As mentioned in this forum thread, we’ve upgraded your production Managed clusters to Kubernetes version 1.29.

Now, it’s time to move forward to Kubernetes version 1.30. We've shared a new post on our forum outlining the upgrade schedule.

You can manually trigger the upgrade for your non-production cluster using the "Upgrade to K8s 1.30" option. This allows you to ensure everything runs smoothly with the new version before applying it to your production cluster.

If you don’t initiate the upgrade yourself, we’ll proceed with it according to the schedule shared in the forum post.

For users of our Self-Managed solution, please update your Qovery charts version by running the "qovery cluster install" command, and then upgrade your Kubernetes cluster version.

#New Advanced Settings for ALB management

Following the release of the ALB controller feature (only on AWS), we're excited to introduce new advanced settings. These settings allow you to customize how HTTP requests are managed through Qovery.

We have added the following advanced settings:

• use-forwarded-headers: Passes incoming X-Forwarded-For header upstream, see documentation.
• compute-full-forwarded-for: Append the remote address to the X-Forwarded-For header instead of replacing it, see documentation.

You can find the complete documentation for the advanced settings in this section.

#EC2 (K3s) Offers Decommissioning

After nearly two years since its release, we have decided to decommission the EC2 (K3s) cluster feature.

However, following the rollout, we observed limited adoption. Most usage came from individual developers looking for a simple way to deploy side projects with a very high churn rate. Despite this, our broader target audience continued to prefer multi-node Kubernetes clusters, as the EC2/K3s setup lacked node autoscaling—an essential feature for many.

Additionally, maintaining compatibility for the EC2/K3s use case added complexity to our already intricate environment. Each code change required extra consideration for this feature, which consumed significant resources.

#Minor Changes:

• Improved cluster creation flow: cloud hosting option cards have been improved with better visibility on the self-managed offer.
• Improved notification for clusters in error: in case of cluster update error, you will have a blinking red error dot on the left nav bar (we are working on an email notification system as well).

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 🚀