The Future of Qovery - Week #4
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 Future of Qovery - Week #3.
Deploy your apps on multiple cloud providers with Qovery
Deploying multiple Cloud service providers (CSP) helps not be vendor-locked, providing more reliable service to your users and reducing your Cloud cost. In this post, I explain how Qovery pragmatically* provides multi-cloud for your apps.
How does Qovery manage multi-cloud?
For years you had to choose the Cloud service provider you wanted to use. Once you made your choice, it was almost impossible to change for another one. Moving an app from a Cloud provider to another one is very hard if your app has not been designed with this aspect in mind. Building abstraction at the application level is complex and requires a lot of engineering effort, which leads to more extended product development. This is why Qovery is built on top of CSPs to provide the abstraction layer below your apps to simplify your app's deployment on any CSP and extend your Cloud capabilities.
Keep your production on AWS, put your dev environments on Digital Ocean.
With Qovery's DevOps automation tool, you choose where your environments run. For instance, you can keep your production on AWS and put your development environments on Digital Ocean. This is what I call "pragmatic multi-cloud". Multi-cloud for each environment brings tons of advantages with almost no downside like:
- Huge Cloud cost reduction: keeping your production on the most reliable CSP and moving out your dev environments on a cheaper one is the pragmatic way to reduce your cost up to 10 times.
- Predictable performances: all your apps will use the same network and resources within the same environment, which means very low latency with the same hardware specs.
- No vendor-locked: you can move an environment from one CSP to another.
- No outbound/inbound network cost between CSPs.
We are building the future of the Cloud.
This is the first step of what we want to build at Qovery. Creating this abstraction layer on top of the best CSPs in the world allows us to provide a new set of features. (🤫 I will reveal more in the following weeks)
> Possibilities are endless, and I am eager to hear what you have in mind and what you would love to see coming next. Would you?
--
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.
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 biggest mistake enterprises make when evaluating Kubernetes management platforms is confusing infrastructure provisioning with Day-2 operations. Tools like Terraform or kOps are excellent for spinning up the underlying EC2 instances and networking, but they do absolutely nothing to prevent configuration drift, automate certificate rotation, or right-size your idle workloads once the cluster is actually running.
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.
Rancher solved the Day-1 problem of launching clusters across disparate bare-metal environments. But in 2026, launching clusters is no longer the bottleneck. The real failure point is Day-2: managing the operational chaos, security patching, and configuration drift on top of them. Rancher is a heavy, ops-focused fleet manager that completely ignores the application developer. If your goal is developer velocity and automated FinOps, you must graduate from basic fleet management to an intent-based Kubernetes Management Platform like Qovery.
.webp)