Changelog

Hello Team,

our team is back on track and we have developed some nice changes to the platform over the past sprint. Take a look at what we have managed to deliver:

Filter the Instance Types to be used with Karpenter

Karpenter has been a part of our platform for over six months, and now we’re taking it to the next level.

You can now restrict the types of instances Karpenter uses to deploy your applications. This feature is particularly useful if you want to:

• Reduce the number of nodes by using larger instances.

• Limit deployments to specific EC2 instance families.

Check out the quick demo below from our CEO to see it in action!

Dev Clusters Upgraded to Kubernetes 1.30

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

Once you have validated that everything works on your non-production cluster, you can manually trigger the upgrade for your 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.

Triggering cluster upgrade

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.

ALB as default and available for prod clusters

The ALB controller feature (available only on AWS) was released a few months ago and was initially limited to non-production clusters. We’ve now updated the configuration with the following changes:

• Default Activation: ALB is now activated by default for all new customers.

• Production Cluster Support: You can now enable the ALB feature on your production clusters.

For more details, check out our official communication: ALB Controller Feature.

Email notifications on cluster update failures

To enhance responsiveness, we’ve introduced additional email notifications for cluster-related issues. These notifications will be sent to the owner and admins of your organization in the following scenarios:

• A cluster update fails.

• Cluster credentials are no longer valid.

These updates ensure you can promptly address and resolve any issues affecting your cluster setup..

Minor Changes:

• Use private subnet ids for existing VPC setup with EKS (AWS): You can now select private subnet IDs when configuring a cluster over an existing VPC. This is necessary to enable Karpenter and run it over fargate.

• Removed default security groups (AWS): we have removed the default security groups that were too permissive (allowing 0.0.0.0/0)

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 🚀

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.

Triggering cluster upgrade

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.

Paradox of the low infra cost

#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 🚀

Hello Team,

This week, our team is enjoying an autumn retreat in Lille, France, spending quality time together after releasing some exciting features over the past two weeks. Check them out:

Non-production Clusters Upgraded to Kubernetes 1.29

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

Now, it’s time to upgrade your production clusters. The upgrade will be triggered on October 28th. If this timeline doesn’t suit you, feel free to manually trigger the upgrade beforehand using the "Upgrade K8s to 1.29" button.

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

New deployment log view

We’ve revamped the deployment log view to improve clarity and visibility:

• Deployment Pipeline: You now have a global view of each stage in the deployment pipeline and their status.

• Separation of Deployment vs. Running Logs: We’ve replaced the tab system with two distinct views to display deployment logs and application logs for each service.

• Deployment Time: You can now clearly see the deployment time for each service, along with the time spent on each step (build, deploy, etc.).

• Pre-Checks Step: This has always been part of the process, but is now more clearly visible in the interface.

Check out the video below!

Enable Whitelist on Kubernetes Public Endpoints

We've introduced new advanced settings that allow you to restrict access to the public endpoints of your Kubernetes clusters on AWS and GCP. This is especially useful for compliance concerns, as it ensures that only a specific set of whitelisted IPs can access the public endpoints. You can manage this feature via the advanced settings qovery.static_ip_mode and k8s.api.allowed_public_access_cidrs.

New AWS Regions Available

We’ve expanded our list of supported AWS regions for Managed clusters, now including:

• Asia Pacific (Hyderabad) ap-south-2

• Europe (Spain) eu-south-2

• UAE me-central-1

Minor Changes:

• Renamed advanced settings database.xxx.deny_public_access: we've renamed this advanced settings into database.xxx.deny_any_access.

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 🚀

Hello Team,

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

Deployment logs - Better Visibility of The Deployment Steps

Every application deployed via Qovery goes through several steps, such as git clone, building, image push, etc.

To enhance visibility and provide better insights into the deployment pipeline, we are completely redesigning the deployment log interface. As the first step, we’ve separated the deployment process into two distinct phases: build and deployment. Each phase now has its own status and execution time displayed.

In this way, you'll be able to easily identify where the issue originates and if either of the two steps is taking longer than expected.

Reduced Build Time by Sharing Images Across Applications

Applications built by Qovery are pushed to your container registry in your cloud account (or elsewhere for Self-Managed clusters), and you can find all the details here. Over the past weeks, we've been working on speeding up deployment times by enabling image reuse across applications within the same cluster, skipping the image build and push steps when possible.

Until last week, every application was built in complete isolation, making it impossible for application B to reuse an existing image built from application A, even if they referenced the same Git repository, Dockerfile, commit Id and root path. This required a new build for application A. With the latest release, this behaviour has changed, allowing application B to immediately use the image previously built for application A and thus reducing the overall deployment time.

This update has been globally released, and all Qovery customers can now benefit from faster deployments. We'll post an article soon to explain these changes and the improvements they've brought to the community.

Karpenter 1.0

We've upgraded Karpenter to its latest major version (1.0) to ensure we deliver the newest features (more details are available on the Karpenter blog).

We're also working on enhancing its flexibility by allowing you to choose the types of instances to run on your cluster. Check out this post from Julien for additional information.

Remember, you can already activate Karpenter on your non-production clusters and take advantage of features like spot instances!

New Cluster Creation View

We've revamped the cluster creation view to better highlight our multi-cloud capabilities and guide you more effectively through the configuration process.

The new interface is similar to the one used for creating a new service, allowing you to easily select your hosting solution and choose between a Qovery-managed or self-managed cluster.

Minor Changes:

• Fetching images from private container registries: we've added the ability to fetch both the image name and version when referencing a private container registry, making it easier to manage your container images.

• Variables interpolation helper: we’ve introduced the variable interpolation helper in the environment variable setup, making it effortless to reuse existing environment variables during configuration.

• Kubernetes 1.29 upgrade: all preparatory work for the Kubernetes 1.29 upgrade is complete. We'll be sending out communication soon with the upgrade timeline.

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 🚀

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 🚀

Hello Team,

We are excited to share the latest updates and improvements from the past two weeks. Our team has been hard at work delivering new features, enhancements, and bug fixes that will make your experience even better. Let’s dive into what’s new:

Karpenter Enabled on Existing Clusters

We’re proud to announce that Karpenter, an efficient autoscale, is now enabled on existing non-production clusters. Karpenter is excellent for reducing your AWS costs and spinning up different types of workloads (like GPUs).

We plan to allow you to turn on Karpenter for your production EKS clusters before the end of 2024.

Auto-Completion for Environment Variables

We’ve added auto-completion for environment variables along with a button to insert variables directly into the code editor. This makes managing and inserting variables smoother.

Kubectl/k9s Support for Managed Clusters

Admin users can now use kubectl, k9s, and any other Kubernetes tools on managed clusters, offering more control over your clusters.

To import your kubeconfig on your local machine, you must be admin and execute the

qovery cluster kubeconfig --cluster-id <id>

You can simply copy/paste the commands on your local machine to get access to your cluster

Minor Changes:

• New Cluster Cards UI: The cluster cards UI has been revamped for better usability and a fresher look.

• Lifecycle Template Updates: We’ve added a flag for file interpolation in the lifecycle template, simplifying workflow management.

• Cluster Deletion Modal Update: Text in the cluster deletion modal has been updated to replace "organization" with "environments" for better clarity.

• Key Icon for Git Tokens: A key icon has been added to the Git tokens in the source Git account list, improving visual clarity.

• Public/Private Access Toggle for Databases: A new switch UI element allows users to select between public and private access for their databases, adding more flexibility.

• Various Minor UI Improvements: We’ve made several other UI improvements, including updated wording and icon styles.

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 🚀

Hello Team,

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

Improved Troubleshooting Flow on Custom Domain Setup

After updating the configuration for custom domains behind a CDN, we've refined the process to troubleshoot potential issues with your custom domain setup.

When you access the Custom Domain configuration section of your application, an automatic verification is triggered for each configured domain to ensure the CNAME correctly points to the domain provided by Qovery.

Additionally, if Qovery is unable to create or renew the certificate for any configured custom domain, a banner will appear, redirecting you to the domain section to identify which custom domain is causing the issue.

New Step in Application Creation Flow: Environment Variable Setup

We've added a new step in the application creation flow: setting up environment variables.

Most applications require a few environment variables to run. Previously, you had to return to the environment variable section after creating the application before deploying it. With this new step, you can complete the setup of your application within the same flow, making the process even easier.

We'll soon enhance this section with more functionalities already available in the environment tab, like importing .env files or adding environment variables as file.

Enable Environment Variable Interpolation for Environment Variables as Files

Last year, we introduced the environment variable interpolation feature, which allows you to compose an environment variable based on strings and values from other environment variables.

Example: If you want to build a URL from an environment variable containing the backend host, you can create a new variable like this:

MY_VAR_URL = https://{{BACKEND_HOST}}

This was possible for standard environment variables but not for environment variables as files, since the file's content might already have a templating system that could conflict with Qovery's.

To ensure safe usage of the interpolation feature, we've added a new flag in the creation modal to enable this functionality.

#Improved UX for Scrolling Through Application or Deployment Logs

Navigating deployment logs or your application's logs can be complex, with a lot of information displayed on the screen. The interface navigation should be ergonomic.

The old "play"/"pause" button that controlled automatic scrolling has been replaced by a mechanism that automatically stops scrolling down as soon as you try to scroll up. An information button appears at the bottom of the logs whenever new logs are available (similar to Slack's system).

Keep an eye on this section, as we're working on a complete redesign to enhance the user experience and help you troubleshoot issues more quickly!

Minor updates:

• Identity Provider in Member List: You can now see the identity provider associated with each member in the member list (Google, Microsoft, GitHub, etc.). No more confusion if you're logged in with the same email on two different identity providers.

• Clippy Mode: In honor of the classic Clippy, you can now change the icon of the Qovery helper (the question mark on the bottom right) to "Clippy."

• Terraform Provider and CLI Version in Audit Logs: We're now logging the version of the Terraform provider and CLI used to generate events in the audit logs.

These updates aim to improve usability, performance, and flexibility, empowering you to deploy with confidence and efficiency.

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

Happy Deploying!

The Qovery Team 🚀

Hello Team,

Exciting updates are here! Check out the latest improvements and features that we have delivered in the past sprint:

Speed up Terraform and Cloudformation configuration with Lifecycle Job templates

At Qovery, deploying resources with an IaC framework is managed via Lifecycle jobs. You can package your IaC manifest as a containerized application and trigger the create/destroy command at the right moment (e.g., on environment creation). This required a thorough understanding of how Lifecycle Jobs work, what kind of Dockerfile to use, and so on.

To simplify the setup, we've introduced a template configuration system that provides a pre-filled setup to package and deploy your Terraform and CloudFormation manifests. Qovery will provide you with:

• A Dockerfile with all the necessary commands specific to Terraform or CloudFormation

• A set of triggers and commands to run depending on the trigger

• The resources to use

You can customize these to match your needs.

Check our public documentation.

We'll be adding more templates in the future, so let us know what's on your wish list!

Find the services using a specific container registry or helm repository

It used to be a real pain to determine if a Helm repository or Container registry was still in use within your organization. That's why we've added a new feature that allows you to quickly find any service still using a specific container registry or Helm repository.

You can access this functionality directly under Organization Settings > Container Repository/Helm Registry.

Customize service icon

The ultimate feature is here... you can now customize the icons of your services!

For now, you can select from a preset list of icons, but in the future, we'll allow you to upload your own custom icons.

New audit log events

In the last sprint, we added new events to the audit log to track clone, shell connection, and port-forward events.

This sprint, we've added another important event: the result of a deployment.

You now have a single view that shows both the changes made to your services and the deployment information!

Minor updates:

• Renamed "Job Configuration" to "Triggers": To better reflect their usage, we've renamed the "Job Configuration" section of Lifecycle Jobs to "Triggers."

• Quick Link to Access Git Repository: There's now a new link to quickly access the repository from the Settings > General section of your application.

• Info Message on Public Ports for Demo Clusters: We've added an info message to let you know that the public ports for applications deployed on a demo cluster are only accessible from the same machine where the cluster is deployed.

These updates aim to improve usability, performance, and flexibility, empowering you to deploy with confidence and efficiency.

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

Happy Deploying!

The Qovery Team 🚀