New service list, Cluster lock, Fallback screens for deployment logs, Redis default encryption

Hello Team,

Take a look at this week’s changelog, which features some exciting updates and enhancements from our team!

#New service list: focus on what matters

Through discussions with our customers, we identified some common sources of confusion when navigating the service list page:

• What’s the difference between deployment status and service status?
• Why are both showing errors?
• Which branch is being used for a given service?

Using this invaluable feedback, we have redesigned the service list with the following key improvements:

• Enhanced Focus on Service Status: The most critical information—service status—now takes center stage in the interface.
• Streamlined Deployment Status Display: Deployment status is now only shown when relevant, such as during an ongoing deployment or when a deployment fails. Once completed, a timestamp will be shown in the “Last Update” column.
• Commit Details Relocated: Commit details are moved to a more intuitive location, improving clarity.
• Branch Information Visibility: The branch used for the deployment is now clearly displayed, reducing any ambiguity.

Check out the video below for a closer look!

#Cluster lock - protect your cluster from unwanted updates

We’ve introduced a new feature in the Qovery CLI that allows you to temporarily lock your cluster, preventing any updates—whether initiated by you or Qovery—during critical business periods.

Execute the following command to lock your cluster:

qovery cluster lock --cluster-id <your-cluster_id> --reason <reason> --ttl-in-days <days>

--ttl-in-days: Defines the duration of the lock (maximum of 5 days).

Note that Qovery reserves the right to force unlock the cluster in the event of a critical bug fix release.

Here's the documentation.

#Improved deployment log views with fallback screens

To enhance clarity in understanding deployment outcomes, we’ve added fallback screens to the deployment log views. These updates provide better insights into what happened during your environment deployment.

You’ll now see a default screen clearly indicating if an error occurred:

• During the pre-check phase
• During the deployment of another service

This feature ensures you can quickly identify and address issues in your environment deployment process.

#Encryption at rest enabled for Redis (AWS)

We have enabled encryption at rest by default for managed Redis instances deployed via Qovery on AWS. This enhancement provides an added layer of security for your data.

Please note that this configuration applies only to new Redis instances. Unfortunately, AWS does not support activating this feature for existing Redis instances.

#Minor Changes:

• Configure build ephemeral storage: You can now configure the amount of ephemeral storage given to the builder machines via the advanced setting build.ephemeral_storage_in_gib.
• Helm network configuration not cloned if service-specific: The network configuration of your helm chart won't be cloned if the pointed service name is strictly related to the service ID (like helm-z1234431-my-service-name). In this case, cloning the configuration won't work, and it was creating confusion.

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 🚀