Are you ready for 2022?
Qovery is the simplest way to deploy your apps on AWS
2019, 2020, and 2021 in a nutshell
When we started Qovery in October 2019, we were 3 - Pierre (CTO), Morgan (CRO), and I (CEO). No user, no employee, no product. Today:
- 15237 developers from more than 100 countries use Qovery to deploy their applications on AWS (and other cloud providers).
- The Qovery team is composed of 15 outstanding people. Thanks to Patryk J., Benjamin D., Romain G., Yaël F., Enzo R., Benjamin C., Rémi B., Albane T., Florian L., Yann I., Tiago S., Bilel B., Morgan P., Pierre M., Romaric P.
- Qovery is an outstanding product used by fast-growing SaaS companies in Healthcare, Insurtech, Fintech industries.
- We fundraised $5 million in total from the co-founders of Datadog, Docker, Contentsquare and Crane VC, SpeedInvest VC.
What’s next for 2022?
New features
At Qovery, we build the future of the cloud, and to succeed in our journey, we need to give access to the most expected features by our customers. For 2022, you can expect to see the support of the Cronjobs, Lambdas, and even a Marketplace. We also plan to support 2 new cloud providers, Google Cloud Platform and Microsoft Azure. Check out our public roadmap for further details.
Qovery v3
Since we launched Qovery in January 2020, we have dedicated our time to making our platform production-ready for our customers. We took 2 years to build a product that you can use every day with extraordinary stability and excellent performance. The Qovery v3 will deliver the best Developer Experience out there. I am not going to give more details about it. But if you were delighted to use Qovery v2, you will be shocked how Qovery v3 will revolutionize the way you ship your products. Stay tuned; we will talk more about it in January 2022.
Continue to make our customers successful
First of all, thanks to all our customers in North America, South America, Europe, Africa, Asia, and Australia. We are so grateful for the trust you’ve placed in us, and our team is dedicated to making you succeed in your journey. We can’t wait to see what we will build together in 2022.
In 2022, we will continue to invest in support and close contact with our customers. It is part of what we call the “Qovery Experience”. Running production infrastructure deserved a high-quality product and team. We will continue investing in the Qovery Experience to make our customers successful in what they build.
Building the future of the cloud
We proudly own the domain meta.cloud and we didn’t want to sell it to… {you know who}. Our plan since day 1 is to build the future of the cloud. Meaning, helping the next generation of developers to build the next generation of applications in the cloud. And for that, we need to start to build the main foundations. Helping junior, experienced, senior developers to deploy their applications in the cloud is the first milestone. We will talk about the second milestone in the coming weeks. Stay tuned!
Hiring
Needless to say, to reach the very high level of our ambitions, we are hiring talented people. Check out our open positions here.
Purple is the new black
The Qovery team is ready to paint the cloud world purple. And speaking of “purple”: Pantone just announced the color of the year 2022. And guess what, it’s a shade of purple! A sign? I like to think so.
2022 looks already an extraordinary one!
--
Thank you! We would seriously not have done this without you and we hope you are as excited and pumped for 2022 as we are!
All the best to you and your loved ones,
The Qovery team
.svg)
.svg)
.svg)
Suggested articles
The part teams consistently underestimate is that OPA Gatekeeper, the tool most people reach for first, only enforces policy at the cluster level. It blocks non-compliant resources from being created within a single cluster. Propagating consistent Gatekeeper policies across 300 clusters, and detecting when those policies drift, is a fleet orchestration problem that Gatekeeper was not designed to solve.
Training a model in a notebook is easy. What breaks teams is the step after, serving it reliably without haemorrhaging cloud budget or burying your SREs in YAML. The common trap: picking a platform that handles the model but not the surrounding stack. An AI deployment platform should orchestrate the full application graph (inference endpoints, vector databases, caching layers, and frontends) inside a single VPC, with GPU autoscaling that doesn't require a dedicated platform engineer to babysit.
The mistake teams make early is assuming Kubernetes namespaces provide sufficient isolation between workloads or teams. They do not. Namespaces share the control plane, the node pool, and the underlying network fabric. A misconfigured workload in one namespace can exhaust node capacity or crash the API server for every other namespace simultaneously. That is when the multi-cluster conversation starts.
Migrating from nginx Ingress to Envoy Gateway? Discover how Alan migrated 100+ services in one month, the technical hurdles they faced (like Content-Length normalization), and why staging isn't always enough.
Kubernetes assigns an entire physical GPU to a single pod by default. NVIDIA MIG solves the hardware partitioning side: one A100 becomes up to seven isolated slices. The part teams underestimate is the orchestration layer: device plugin configuration, node labeling, taints, and pod affinity rules all need to be correct before Kubernetes can actually schedule onto those slices.
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.
.webp)