Helm service selection, Cluster Kube Upgrades, New application logs, Buildpack decommission

Hello Team,

We have been working hard over the past weeks to deliver you some exciting news on our product, check this out:

#Simplified process to publicly expose services deployed with Helm

Qovery makes it easy to expose services deployed with your Helm chart to the internet. The setup has been streamlined—you only need to select the service and port from a dropdown!

Previously, you had to manually enter both the service name and port. Now, the Qovery control plane automatically retrieves the list of services deployed by your Helm chart along with their exposed ports.

#Manual Kubernetes version upgrade

We are currently completing all the preparatory work before initiating the upgrade of your Managed clusters to Kubernetes versions 1.29 and 1.30. We'll soon share the timeline for these upgrades on our website and forum.

As part of this preparation, and to give you more control over the upgrade process, we’ve developed a new feature that allows you to manually trigger the version upgrade. Once the Qovery team officially supports a new Kubernetes version (in this case, 1.29 or 1.30), a new option will appear in your cluster's action list, enabling you to initiate the upgrade at your convenience.

If you prefer not to trigger the upgrade manually, your cluster will be automatically upgraded according to a schedule that we’ll share with you soon.

#New application log view

We've updated the application log view to bring some key improvements:

• Easily filter by pod, container, or version.
• Expand each log line to view more details.
• Fresh new UI that's more readable.

Check out the video below!

We're working on delivering a completely new error troubleshooting experience. Stay tuned for it in the upcoming releases!

#Buildpack support decommission

We have decided to stop supporting Buildpack and will focus on providing the best experience for applications built with Dockerfiles. You can no longer create new applications using Buildpack, and we will soon decommission the remaining codebase.

However, this doesn't mean we're leaving our existing customers who use Buildpack behind. We are working on a new solution to generate Dockerfiles using generative AI, as shared in our blog post here.

#Minor Changes:

• Removed advanced setting deployment.custom_domain_check_enabled: following the updates on the custom domain configuration section, we have removed this advanced setting.
• Added production flag in Qovery Terraform provider: You can now define if a cluster is for production directly from your TF manifest.
• Added linked service info in environment variable dropdown: in the new dropdown to select the environment variables for interpolation, we have added the information about the linked service (only for BUILT_IN variables)

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 🚀