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
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
.webp)