Q3 2022 product retrospective - Last quarter's top features
Qovery V3 Beta Testing
Spoiler alert here, or almost 😅 . If you are following the updates, you probably already know that we have been building a brand new console for some months now, and I have the pleasure of telling you that this V3 is currently in Beta testing, so all of you can give it a go! From a better developer experience to more transparency, and after many excellent feedbacks from our Alpha tester, we can’t wait for you to try it.
If you want to know everything about it, I recommend you check out this article.
Infrastructure logs
Those logs are about to change your life; the goal is to facilitate debugging and optimize the visibility and transparency of your infrastructure.
Soon to be accessible from the cluster page on the V3, it is now accessible from the organization panel on the V2:
Now, the fun doesn’t stop there because if you have an error, an error tab will automatically display the information of the last issue in the logs.
Can’t wait to see what it looks like, well head to the console and find out for yourself, but if you really can’t wait, here is a snapshot of it:
Deployment logs environment improvement
With our brand new infrastructure logs, we felt it was also time to improve the environment logs to make your experience easier with a “current status” that explains the state of the deployment and the pods of an application. In case of an issue, you are also given extra information to help resolve it and a link to our troubleshooting page.
NB: We’re still working on the infrastructure and deployment logs, so if something isn’t clear, don’t hesitate to post a message on our forum.
Qovery EC2
What is Qovery EC2? In just one sentence: what if I told you that you could host your application on AWS from $20 per month? Well, it’s now possible thanks to Qovery EC2! 🦾
Today, Qovery relies 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 two months on a $20/month offer to host your apps on AWS - Qovery AWS EC2.
Qovery EC2 vs EKS
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. We only recommend running development and hobby projects on an EC2 instance; you can find the limitations here!
Here is a quick demo video of Qovery EC2👇🏻
Advanced Settings - IP Whitelist (CLI only)
Let’s start strong with a feature that is both new in the V3 console and the V2 via the API: IP whitelisting!
What our user wants, they get, as this was a user request from the forum that got quite popular.
You can now limit access to the application to certain IP addresses.
How to use it in the V2?
- Check out our API documentation.
⚠️ Keep your API token secured - never share it with anyone.
Whitelist IP addresses
To whitelist only some IPs like:
- 1.1.1.1
- 42.42.42.42
- 11.11.11.11
You can run the following CURL command:
Then redeploy your application to apply the change.
The default value is: 0.0.0.0/0, which means all the IPs are whitelisted.
Your Application ID (appId) is the last ID in your console.qovery.com URL. E.g. for https://console.qovery.com/platform/organization/141c07c8-0dd9-4623-983b-3fdd61867777/projects/4ac1185f-4b7c-4f12-95b6-0690f796bbbb/environments/1109c4d2-ffbb-49d6-9826-f5a7ca3a8888/applications/3cc850c6-cc4f-46bc-ad05-c90f7b597333/summary the Organization ID is 3cc850c6-cc4f-46bc-ad05-c90f7b597333
Container Deployments (API only)
We are super excited to announce the public beta launch of our container feature! Most of you have been waiting long to deploy container applications from your private and public container registries. Since we launched Qovery, we were only supporting application deployment from your git repository - now, you can also deploy it from your container registry.
Why Use Container Instead of Application?
If you already use a CI system and have pushed your container images into your container registry, you might want to use those images and avoid rebuilding them. This is where deploying a container is useful.
Deploying an application is 4 steps - Qovery clones your Git Repository, builds your container image, pushes it into a private container registry, and deploys it.
Deploying a container is 2 steps - Qovery takes your container image from your container registry and deploys it.
If you want to know how to do it, here are some further explanations and a tutorial that can help.
Others
- Cluster Advanced Settings
- Preview Environments New Message on PR
- Infrastructure logs bug correction and improvements
- Automatically expose publicly applications with Buildpack mode.
- Improve "Last update" information on environment and service list
- Kubernetes upgrade
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)