Changelog

Hello Team,

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

Welcome, Kubernetes 1.32: the new default version

As part of our rollout plan for Kubernetes 1.32 and 1.33, version 1.32 is now the default for all newly created clusters.

Next week, we will begin the upgrade phase for existing clusters, starting with non-production environments. You can choose to upgrade to 1.32 yourself or wait for us to handle it for you.

Upgrading Kubernetes may look simple, but it requires a month of engineering work to validate and prepare every component across all clusters. Each upgrade involves:

• Reviewing and upgrading all Helm charts for compatibility

• Testing integrations with managed services

• Validating cluster-specific configurations

• Planning and executing phased rollouts for safety

We upgrade non-production clusters first to give you time to validate before moving to production.

Azure Beta: better credentials management

A few weeks ago, we announced the launch of our Qovery Managed cluster offering on Microsoft Azure AKS (Azure Kubernetes Service), making it easier than ever to deploy and manage cloud-native applications on Azure with zero Kubernetes overhead (Have a look at our official announcement here).

A few customers have been using it so far, and we've already delivered the first improvements to the credentials management!

We now automatically rotate credentials used to access your cloud account. Even if credentials are leaked, they expire within hours, minimizing risk. To avoid unnecessary secret generation, secrets are temporarily stored and reused across operations (e.g., deploy app A, stop app B).

What's coming next:

• Additional security and best-practice configurations to help you pass SOC2 and HIPAA certification

• Integration of Karpenter as an advanced autoscaler as soon as it is officially released for Azure

Simplified uninstall and delete flow

A few weeks back, we released the uninstall feature, allowing you to delete the remote resource while keeping your Qovery configuration intact. This is extremely helpful when you don't want to waste resources on your Kubernetes cluster but still keep the configuration on the Qovery side without deleting it.

Since the difference between the actions "delete" and "uninstall" wasn't so clear, we have improved the flow by merging the two actions into one and allowing you to decide if you want to keep the Qovery configuration or not.

Remove service - uninstall and delete

Minor Changes:

• Reduced AWS S3 default permissions: the service account created to access the logs via Loki has been reduced, and it can now only target buckets starting with "qovery*".

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,

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

Azure AKS managed by Qovery is now available in Open Beta

We’re excited to announce that the Qovery Managed cluster offering now officially supports Microsoft Azure AKS (Azure Kubernetes Service), making it easier than ever to deploy and manage cloud-native applications on Azure with zero Kubernetes overhead.

This is now available in open Beta!

From day one, Qovery’s mission has been to simplify Kubernetes operations and deployment across cloud providers, thanks to our Managed offer. After solidifying our support for AWS EKS and Google GKE, Azure AKS was the natural next step and one of the most requested features from our community.

With Qovery + AKS you will get:

• No Kubernetes expertise needed

• Get fully managed cluster operations, including automated upgrades

• Enjoy sensible defaults and built-in automation for configuration, networking, and secrets

• Built-in high availability with multi-zone AKS cluster support

• Stay secure with automatic secret and credential rotation

• Manage your infrastructure across AWS, GCP, and Azure in one unified platform

• Compliance SOC2 HIPAA (Coming soon)

• Advanced autoscaler Karpenter (Coming soon)

Have a look at our official announcement

Upgrade plan available for Kubernetes 1.32/1.33

As part of our regular maintenance cycle, we’ve published the full plan for upgrading your clusters to Kubernetes 1.32 and 1.33.

You can find the complete details in this forum post, but here’s a quick recap of the timeline:

1.31 → 1.32

• 19/08/2025: All newly created clusters will run Kubernetes 1.32 by default

• 19/08/2025: Cluster upgrade becomes available to users

• 25/08/2025: Upgrade of all non-production clusters to 1.32

• 08/09/2025: Upgrade of all production clusters to 1.32

1.32 → 1.33

• 15/09/2025: All newly created clusters will run Kubernetes 1.33 by default

• 15/09/2025: Cluster upgrade becomes available to users

• 22/09/2025: Upgrade of all non-production clusters to 1.33

• 06/10/2025: Upgrade of all production clusters to 1.33

Upgrading Kubernetes might look simple on the surface, but it’s far from it. Behind the scenes, it takes a full month of focused engineering work to validate and prepare every component across all clusters.

Each upgrade requires:

• Reviewing and upgrading all Helm charts for compatibility

• Testing integrations with managed services

• Validating cluster-specific configurations

• Planning and executing safe, phased rollouts

This is exactly why we roll out upgrades to non-production clusters first, giving you time to validate everything before we touch production.

Bitnami catalog changes: what you need to know

Bitnami recently announced that many of its free container images will move to a legacy repository with no future updates. If you want to use the latest, secure versions of these images, you’ll now need to subscribe to their paid plan.

This change impacts both Qovery-managed workloads and customer-deployed applications relying on Bitnami charts. We’ve already reviewed our internal usage and are updating our stacks accordingly.

If your apps rely on Bitnami images, we’ve proactively reached out to let you know, along with recommendations to avoid potential issues in the future.

Minor Changes:

• Improved message during cluster delete: when there is a dependency violation during the cluster delete, we have improved the error message to let you know which dependency is blocking the operation.

• Fixed CLI temp directory cleanup: fix available in CLI 1.40.5

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,

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

Cluster Overview: one unified view of your cluster health

Managing infrastructure isn’t just about provisioning and scaling, it’s also about understanding what’s going on (and fast!!).

That’s why we just rolled out Cluster Overview for all customers:

• See node health and capacity at a glance

• Diagnose issues without diving into a metrics soup

• Track Kubernetes version, nodepool limits, and resource usage - in one clean view

It’s part of a bigger effort at Qovery: Making infrastructure not just invisible but legible.

As previously announced, we’re working on Qovery Observability : an all-in-one observability solution integrated directly into the Qovery platform. Cluster Overview is one of the pillars leading up to the full release. Stay tuned.

Uninstall your services, keep your configuration

Sometimes you want to test a configuration change on a service, like adding storage. You deploy it a few times, and at the end of the day, you want to clean things up and continue tomorrow. Until now, that meant deleting the entire Qovery configuration. Not ideal.

With the new Uninstall feature, you can now delete the remote resource while keeping your Qovery configuration intact.

Service uninstall

We originally had this in mind for our upcoming Terraform service (yes, soon you’ll be able to deploy resources using Terraform manifests). But it made so much sense that we decided to roll it out for all Qovery services.

Manage cluster credentials all in one place

We have reviewed the experience with cloud credential management and consolidated all the information in one place. You can now add/edit/delete them in a single page and also see which cluster is using them.

Before, it was impossible or very complicated a have a clear view or to edit an existing cluster credential.
A single view to know which cloud credentials are in use in your organisation 👀

Cluster credentials management

#Revamped Network section for clusters

The former "Features" section was complex and hard to understand; this is why we have renamed it to Network and restructured its layout for better clarity. Here’s what’s new:

• Clearly see how to configure the network part (managed by Qovery or not)

• Clean settings (merge Features with VPC Peering)

• Add more information on what it means to have a cluster managed by Qovery (no k8s skills needed, multi-zones, ..)

Cluster Network

Minor Changes:

• Improved service statuses: Better loading logic and no more false positives

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,

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

Announcing Qovery Observability

We are thrilled to announce the next major milestone in our platform vision: Qovery observability!

This new product launch is strictly tied to Qovery’s vision to empower developers with autonomy and confidence. It brings observability directly into their hands and helps shift infrastructure ownership left, closer to those who build and ship the software.

This is our developer-first observability product that brings everything you need into a single, unified view, completely integrated into our platform.

Qovery Observability - application visibility right within the Qovery console

Thanks to the work we’ve been doing over the past years on our infrastructure management and CI/CD product, you can trace an issue from a failing pod to a recent configuration change, a network spike, or a service deployment, and even get alerted before customers notice anything without switching tabs or chasing down disconnected dashboards.

It is fully integrated into our platform and it provides metrics, events and logs across your entire stacks in a clean, powerful interface that lets you move from high-level views to granular details in seconds.

And the best part? It’s fully managed. No maintenance, no glue code, no integration headaches. Just one click and you get the data all in one place.

Have a look at our official announcement here

Improved deployment history: keep the last deployment

We’ve updated the retention rules for the Deployment History section. From now on, we will ensure that at least the last deployment of each service within an environment is always retained.

Previously, only the last 20 deployments were kept, regardless of the service. This led to confusion, especially for services that are deployed infrequently, as their last deployment record could be lost.

With this improvement, you can now be confident that the deployment history includes at least the latest deployment for every service, no matter how often it is updated.

Custom domain configuration is allowed only with a public port

We’ve improved the flow for configuring a custom domain on your application.

Now, a custom domain can only be configured if a public port is defined in the application settings.

This change ensures consistency and prevents misconfiguration, since a custom domain has no effect if the application is not exposed through a public port.

Public port mandatory for custom domain

Service running status loading improvement

We’ve heard your feedback, and we’ve fixed it: no more misleading service statuses.

In some cases, services were incorrectly displayed as “stopped” when they were actually running, forcing you to manually refresh the page to see the real status.

We’ve reviewed and improved our WebSocket system to ensure real-time and reliable status updates, so you always have an accurate view of your services.

Minor Changes:

• Improved error messages: we have reviewed a few error message texts, including the "No ingress found" error.

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,

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

Access your Kubernetes cluster directly from the Qovery console

Admins can now connect directly to their Kubernetes cluster from the Qovery console. Just head to the cluster page, hit the “Connect” button, and you’ll be dropped into a pod with kubectl, k9s, and other tools ready to go.

The objective? We want to simplify the life of cluster admins. No need to download kubeconfigs, install tools, or worry about credentials. It’s now easier and faster to check what’s going on in your cluster, right from the browser.

Additional cluster info available in the Terraform provider and environment variables

We’ve added more Kubernetes cluster metadata both in our Terraform provider and as environment variables:

• The cloud provider cluster name (env var QOVERY_KUBERNETES_CLUSTER_NAME)

• The cluster OIDC issuer

• The cluster ARN

• The cluster VPC ID (env var QOVERY_KUBERNETES_CLUSTER_VPC_ID)

The objective? Make it easier for anyone to use the cluster information at different levels:

• Simplify IAC configuration with our Terraform provider: managing the cluster setup without that information was a pain and required running custom scripts within the Terraform manifest

• Simplify the deployment of managed cloud provider services: easily retrieve the VPC information so that the resource can be deployed within the same VPC of the cluster without having to create a separate one.

Azure (AKS) managed solution - Looking for Alpha and future Beta testers

We’re launching a fully Qovery-managed AKS (Azure Kubernetes Service) experience. This brings all Qovery capabilities to Azure without the need to manage the cluster yourself via our self-managed solution.

If you need to run your workload on Azure in a fully managed, scalable and secure way, get in touch with us! (via Slack or the support widget on our website)

We are ready to launch our alpha phase before having a public beta, and thus we are looking for customers willing to collaborate with us up to the official release.

Customer support - Now fully powered by Pylon

We’ve completed the migration to Pylon, our new support system. All console requests now go through the same platform we use for Slack and email.

The objective?

Providing the best customer support has been at the core of our company since day 1. Making it scale with the increasing number of customers has been a challenging task, and we had to adapt our internal tools to make it happen. Thanks to the Pylon integration, we can now provide the best support experience across different channels (Slack, email or our console)

Minor Changes:

• CLI - added "list commands" action: it allows you to discover the available commands on our CLI.

• Improved toast message in case of variable conflict: when adding a variable which already exists, you now get a message providing you with the name and the location of the conflicting variable.

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,

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

Say hello to the Qovery DevOps Copilot

We’re thrilled to introduce the Qovery DevOps Copilot: a smart, AI-powered Agentic assistant designed to supercharge your DevOps workflows.

Currently in Alpha, the Copilot is built to automate repetitive tasks, provide contextual insights, and guide decision-making across your infrastructure where Qovery runs.

🎯 This is an incredible step forward in our vision: to offer a self-service platform that provides an exceptional developer experience, powerful automation, and reduced tooling complexity across the entire application and infrastructure lifecycle... without any deep infrastructure knowledge!

What your DevOps Copilot can do for you today

Imagine you're a developer, it's Friday afternoon, and you must ensure all development environments are properly managed before the weekend to control costs. Instead of manually checking each environment, you can tell the Copilot:

"Show me all development environments that have been inactive for more than 24 hours, and schedule them to stop at 6 PM today. Also, send a Slack notification to the team about this action."

The Copilot will handle this entire workflow for you, saving time and ensuring nothing is overlooked.

By default, the DevOps Copilot is in read-only mode, but here's what your DevOps Copilot can help you accomplish when unlocked:

• Scheduling: "Deploy serviceapito staging at 23:00 UTC."

• Reporting: "Generate a weekly usage and deployment summary for project Atlas." or “How many deployments we did on our organization on the last 30 days - can you also tell me the deployment time at 90, 95, 99 percentile for each service?”

• Environment control: "Stop all development environments that have been idle for 4 hours."

• Explain Qovery: "How does the networking layer isolate production and staging?"

• Configuration help: "What does the**CONNECTION_TIMEOUT**field in advanced settings do?"

• Optimization: "Propose Dockerfile tweaks to shrink imagefrontend." or “How can I optimize my deployment time?”

Check out a few examples:

• Generate a report on Qovery usage

• Trigger and queue deployments

ℹ️ Since it is in Alpha, a few improvements and functionalities still need to be implemented. Contact us to get early access and be part of this Alpha phase!

Choose a dedicated control plane for your Kapsule clusters

Until now, we’ve provided access to the Mutualized control plane for Kapsule clusters, a free option that’s been sufficient for most use cases.

But as our customer base grows, we’ve hit some of its limits, including etcd bottlenecks and control plane response time issues.

You can now upgrade to a Dedicated control plane directly from your Qovery console. This gives you:

• More stability and performance

• Improved scalability for demanding workloads

• Full control, without leaving the Qovery UI

New AWS region enabled: Mexico (Central)!

AWS has been steadily expanding its global infrastructure, and we’re keeping pace to give you more flexibility based on your application’s traffic needs.

We’re excited to announce that Mexico (Central) is now fully supported by Qovery! 🇲🇽

This new region, announced by AWS earlier this year (official announcement here), is now ready for your deployments, with all Qovery-managed infrastructure running smoothly.

This addition was made following a customer request, and it’s a reminder:

If you need to deploy to a specific region that isn’t supported yet, just reach out to our support team. We’re listening!

More regions. More flexibility. Same great experience.

Minor Changes:

• Increased PDB maxUnavailable value to 20%: to allow Karpenter to scale down more easily and avoid safelock in a cluster with a considerable number of nodes.

• Replaced Intercom chat with Pylon: we have migrated our support from Intercom to Pylon and we have finally changed the widget chat component used in our front-end application and use Pylon instead.

• Add priorityclass to VPA: to ensure VPA runs smoothly in every condition, a priority class has been assigned to it

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,

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

🔐 Use Assume Role (STS) for safer AWS connections

Until now, the only way to connect Qovery to your AWS account was through static credentials (Access Key / Secret Access Key). While it works, it’s not the most secure approach.

That’s why we’ve added support for Assume Role via AWS STS - bringing a much more secure and flexible way to authenticate:

• 🔄 Short-lived credentials: STS credentials automatically expire and refresh, reducing the risk of leaks

• 🧱 Granular access: IAM roles allow you to define precisely what Qovery can do on your AWS account

• 🔒 Less exposure: Static credentials are long-lived and easier to compromise

• 💡 Static credentials are still supported, but we strongly recommend switching to Assume Role for better security.

To make things simple, we provide:

• A ready-to-use CloudFormation stack to create the role in a few clicks

• In-app documentation at the exact moment you need it, while setting up your AWS credentials

It's faster, safer, and just a better way to connect.

See the documentation here.

Select your Docker build stage

Until now, there was no way to specify which stage Qovery should build when using a multi-stage Dockerfile

You can now explicitly select the target stage to build and deploy:

• Choose the right stage for your app

• Avoids the need to split or rewrite your Dockerfile

This option is available directly in your service’s Build and deploy settings.

See the documentation here.

Know when your environment is out of date

Changing a project or environment-level variable? Until now, it wasn’t obvious that you needed to redeploy the whole environment, not just individual services.

We’ve added a small but important visual cue:

• ⚠️ The Deploy Environment button now turns yellow when something is out of sync

• 🔁 Helps you avoid issues caused by partial deployments

It’s a subtle change, but it helps ensure your environment stays consistent, especially when using global variables.

Know when your environment is out of date

Minor Changes:

• Cancel a queued deployment from deployment history: You can now remove a deployment in the queue, directly from the deployment history view.

• Enable compression in NGINX by default: Compression is now enabled by default on all new clusters using the built-in NGINX layer, helping reduce payload sizes and improve performance. If you’re using an existing cluster, you can activate it manually by enabling the advanced cluster setting: nginx.controller.enable_compression. ⚠️ Note: If you already use another layer (like a CDN or custom proxy) that handles compression, we recommend not enabling this to avoid double compression issues.

• Return to infrastructure logs in dry-run mode: When updating a cluster in dry-run, you’re now redirected back to the infrastructure logs.

• Force lowercase in image names: When deploying a container image in Qovery, we now automatically convert the image name to lowercase to comply with container registry naming rules and prevent unexpected errors.

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 really active over the past sprint on improving the user experience and adding a few core functionalities to our product.

Improved command bar (Ctrl + k) with service search and favourite service management

The original command bar was a great start—letting you quickly search and run actions based on your current context. But we knew it could do more.

Finding specific services across multiple projects was painful—especially if you constantly switch between 3 or 4 services. So we’ve levelled it up with some powerful new features:

• 🔍 Service search – Just type the name of a service, and jump straight to it. Quick links to the related environment and project are also available.

• ⭐ Favourite services – Pin your most-used services to a favourites list—always visible in the command bar.

• 🕓 Recently visited – Instantly access the last 3 services you opened, right from the bar.

Check out our video below 👇

What's coming next here

We will add the possibility to search for environments and clusters!

Debug improvements - get your pod Kubernetes events on the console

Troubleshooting application issues on Kubernetes can be tricky—you need a clear, detailed view of what’s happening at the pod level.

To help with that, we’ve added Kubernetes event logs directly into your application view. You can now see the latest events that occurred on your app’s pods, making it easier to understand why something might not be working as expected.

What's coming next here

We’re working on:

• A real-time resource view for your applications

• A new observability tool that gives you visibility over past hours and days of activity

Stay tuned—more clarity and control are on the way!

Test your cluster changes before applying them - Dry-run

Want to see what changes will be made to your infrastructure—before actually applying them?

You can now run a Dry-Run to preview the exact delta between your current setup and what’s defined in your configuration. This gives you peace of mind by clearly showing what’s about to happen.

The dry-run output is split into two key steps:

• Terraform Plan – See the proposed changes to your cloud infrastructure (resources, networking, storage, etc.)

• Helm Diff – Review changes to your core cluster components (e.g., Cert-Manager, Qovery-managed apps, etc.)

Perfect for double-checking before big updates 🚀

Inject custom configuration for CoreDNS

Some applications rely on specific DNS rules to function properly. To support these advanced use cases, you can now inject custom CoreDNS configurations directly into your cluster.

This is done via the new advanced cluster setting: dns.coredns.extra_config

example:

example.com:53 { errors cache 30 forward . 8.8.8.8 8.8.4.4 }

Minor Changes:

• Qovery production cluster upgraded to 1.31: We have upgraded our production cluster during the maintenance that happened on the 14th of April.

• Scaleway coredns setup reviewed: we have modified the default configuration applied on coreDNS and managed it with a separate snippet.

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 🚀