Seamless Cloud account management đ - The Future of Qovery - Week #8
This series will reveal all the changes and features you will get in the next major release of Qovery. Let's go!
Read the previous article: The easiest way to deploy your database - The Future of Qovery - Week #7
Seamless Cloud account management đ
You may be familiar with the AWS web console and how complex it is to have a complete overview of what's going on. You may wonder:
- How many services are running?
- How much is it going to cost?
- How to optimize my resource consumption?
Those questions are legitimate. And even if they are not directly linked to Qovery, we want to help you better clarify what happens on your Cloud account. That's why we worked on a brand new Cloud account management console with our product team. In the next version of Qovery, you will gain visibility on your infrastructure. Helping you to optimize your resource consumption and better use the Cloud.
Simplicity
Using Qovery on your Cloud account is as simple as creating a Cluster and binding your Cloud Service Provider through the settings.
Today we support AWS and Digital Ocean (beta). And we plan to add Scaleway for Q3 2021 and Google Cloud Platform for Q4 2021.
Invite your teammates đ«
Qovery empowers developer collaboration. You will have the ability to give access to your teammates with appropriate roles: admin, developer, and viewer. Once again, if you are familiar with IAM from AWS, you see how easy it is to onboard your team. You no longer need to slam your head against the IAM wall. Life is more straightforward, and you can go back to work.
Manage multiple Cloud accounts đ
Wow, this is the most fantastic feature ever, right? đ. But this is not exactly what you think. At Qovery, we provide pragmatic multi-cloud. Meaning, you can add clusters to different Cloud Service Providers to reduce your Cloud cost based on the reliability needed for your workload.
The most pragmatic choice that you can make is:
- Keep your production workload on a reliable Cloud provider.
- Put your development workload on the cheapest Cloud provider.
Doing this way makes you able to reduce your Cloud cost per four đ”!! Which is a considerable cost saving without any downside because you keep the same great Qovery experience. This is 100% transparent for you. There is no magic. This is just how Qovery works by design.
Clarity on Cluster auto-scaling đ
Cluster auto-scaling is a vast topic. You may have heard about vertical auto-scaling, horizontal auto-scaling, and even multidimensional autoscaling đš - this is super complex... That's why we decided to simplify all of that and make it evident for you.
What our customers want is to pay only what they use, and that's it. That's the promise of the Cloud. So with Qovery, you choose the number of nodes you want and the CPU and the RAM per node of your cluster. That's it. Qovery takes care of scaling up or down your nodes based on your actual workload. Magic? Once again, it is not. We are just working hard to make it works.
Transparent pricing đ°
To build a product that you love, we need to hire the best engineers out there. And to have the best, we need to give them reasonable compensation. Our business model is based on the number of apps Qovery manages for you and not based on what you consume on your Cloud account. Providing you with transparent pricing is critical. From the web console, you know how much Qovery costs for you in real-time.
Conclusion
Getting started to deploy your apps on your Cloud account should not be more complicated than the experience provided by Qovery. In 15 minutes, you can access the deployment stack that you would build for your company. My team and I are excited to release our next major version of Qovery. If you are interested in joining the beta in early June, let me know on Discord.
--
See you next week -- same hour, same place đ
Romaric from Qovery -- We are hiring.
.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)