Q2 2022 product retrospective - Last quarter's top features
Qovery V3
You are not mistaken; the Qovery Console V3 is in Alpha testing! After a full quarter of work, our teams can finally show you what they have been working on for the past three months, and even if this V3 is in Alpha and many things are missing, we can’t. Wait for you to try it out! From a better developer experience to more transparency, a lot has been improved from the V2 to the V3 but don’t take my words for granted; watch this demo that will tell you everything you need to know about it or read this article to know it all.
Qovery EC2
Until today, Qovery's DevOps automation software was relying on an AWS EKS (Managed Kubernetes by AWS) to deploy your apps. This service costs you $220/month. Regardless that you deploy 1 or 10 applications. Our team has been working for 2 months now on a $20/month offer to host your apps on AWS - Qovery AWS EC2. The difference? Qovery no longer spawns an AWS EC2 instance instead of an AWS EKS Kubernetes cluster. It's the perfect solution for your hobby project and testing environments. The main difference between AWS EC2 and AWS EKS is the number of Availability Zones (AZ). If a network or power disruption happens on the AZ where the EC2 instance runs, your applications will no longer be available until it's solved. It's an acceptable outage for most of the development and hobby projects. That's why we only recommend running development and hobby projects on an EC2 instance!
Slack
If you'd like to automatically notify your team on a Slack workspace whenever a change has occurred on your apps, this Integration will help you out. You can choose which actions should trigger messages on your Slack workspace. If you want to know how to set it up, here is the full tutorial or here is a little demo.
[Terraform] Improve Terraform integration
If you’re following us, you probably saw the Qovery demo day that we organized last week, where Bilel (Software Engineer at Qovery) explained all the improvements added to the Terraform integration; if you want to take a look at the whole demo day, it’s here. Otherwise, I added the part about Terraform right below, but in a nutshell, the changes were:
- Add the VPC peering feature to the cluster
- Use Qovery’s API token
- Use instance type to create the cluster instead of CPU/ RAM
- Add build-in environment variables to the application, environment and project
- Add secrets to the application, environment and project
- Various bugs and fixes and stability improvement
- Functional tests
[API] Advanced settings
Qovery already allows you to customize quite a lot of parameters in your application (RAM, storage, Networks…); for most of our clients, it’s more than enough to have their applications up and running the way they want, but we are aware that some specific industry or more prominent companies might require more, that’s why we created the advanced settings: a section that you can find in the API only for now.
Nb: the section will grow within the next sprints.
[API] Handle application deployment delay time (via Advanced settings)
The first functionality of this brand new advanced settings panel, if you want to define a "delay time" (in seconds) for your application to start receiving traffic only after that specified amount of time, it’s now possible. Now, you might ask: why would I want that? This is necessary to handle applications taking a long time to boot (using JVM etc..). Until now, we were waiting for the app to be deployed without checking if the application could receive traffic, and this could cause an impact on the first rollout and application updates. Still, this time is now over cause this new feature got you covered.
As part of the advanced settings, this is only available in the API for now.
Others
- New pricing slider for sign up
- Add Preview Environment URL in comment into Pull Request page
- Filter logs by pod name
- Allow using an URL to connect via the Qovery shell command
- Github - Handle permission per repository
- “Delete organization” API call does not work when there are no clusters
- Can’t switch database from private to public and vice versa (container side)
- Accept instance type selection in cluster setup + provide an endpoint to list available instance types
- Display in logs if the Docker cache is used correctly
- Desired nodes should be higher or equal to min node
- Refresh application metrics when switching between apps and during deployment
- Refactoring Open-API: removing Response
Do you want to know what’s next? You can find our progression in the Changelog section of our website where we post every two weeks.
.svg)
.svg)
.svg)
Suggested articles
At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.
To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.
AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.
By adopting GitOps and utilizing management platforms like Qovery, fintech teams can automatically generate DORA-compliant audit trails, transforming regulatory compliance from a manual, time-consuming chore into an automated, native byproduct of their infrastructure.
Kubernetes success is determined by Day 2 execution, not Day 1 deployment. While migration is a bounded project, maintenance is an infinite loop that often consumes 40% of senior engineering capacity. To protect margins and velocity, enterprises must transition from manual toil to agentic automation that handles scaling, security, and cost.
Day-0 is planning, Day-1 is deployment, and Day-2 is the infinite lifecycle of maintenance. While Day-0/1 are foundational, Day-2 is where enterprise operational debt accumulates. At fleet scale (1,000+ clusters), managing these differences manually is impossible, requiring agentic automation to maintain stability and eliminate toil.
.webp)