Qovery Demo Day Summary - February 2023
Agenda
- Qovery quick intro
- What we worked on last month
- Jobs Demo
- What's coming next
What We Worked on Last Month
New Landing Page
We are excited to announce a major update to our website with a brand new landing page. It has been 24 changelogs ago since our last landing page update, and it was time to give a fresh look to our website. To give you a better idea of what our V3 or our console looks like, if you haven’t tried it yet, we have also added a video showcasing the new features and design.
Pumped CLI
Our CLI has been pumped as a lot has been added to it, such as commands for:
- Application (list, deploy, redeploy, stop, delete, cancel)
- Container (list, deploy, redeploy, stop, delete, cancel)
- Environment (list, deploy, redeploy, stop, delete, cancel, clone)
- Job (list, deploy, redeploy, stop, delete, cancel)
- Database (list, deploy, redeploy, stop, delete, cancel)
Jobs Demo
Lifecycle jobs run on a Kubernetes cluster and are executed only when a specified event occurs in the environment. The output files created by the job will be automatically set as environment variables for services within the same environment. These types of jobs are useful for tasks such as seeding a database or creating external resources not natively managed by Qovery.
Qovery allows you to create and deploy jobs from Git Repository or Container Registry.
Here is also the demo of the Jobs feature by Romaric👇🏻
What's coming next
It's time to gear up for some exciting updates! Our team at Qovery is proud to announce that we have been listening to your feedback and are now launching several new features to enhance your experience. From the deployment order and parallel deployment to support for ARM instance types, and the addition of audit logs, we have got you covered.
Deployment Order and Parallel Deployment
We are thrilled to announce that deployment order and parallel deployment, two highly requested features from our community, will soon be a reality. With this new capability, you'll have the power to configure the deployment order of your services, creating stages and associating them with the deployment pipeline. This means you'll be able to specify the exact order of deployment, for example, deploying your database first, then your backend, and finally your front-end.
And that's not all, with the deployment order in place, you'll also be able to parallelize the deployment of services within a stage. This will result in significant time-saving and efficiency, allowing you to deploy faster and smarter.
You can already try it via the CLI, for more information, check here.
ARM Instance Type
By supporting ARM instance types, we aim to provide you with more cost-effective and environmentally friendly options for running your applications. ARM processors are designed to be more power-efficient, which can lead to reduced cloud computing costs, especially for applications that run continuously for long periods of time. Additionally, ARM processors have a smaller carbon footprint compared to x86 processors, making them a more environmentally conscious choice.
Audit Logs
We are thrilled to announce that audit logs are in the works and will soon be available to enhance visibility into organizational activity. With this feature, you'll have access to a comprehensive log of all changes made within your organization, including when parameters were altered, who created environments, and who initiated deployments.
Audit logs play a critical role in maintaining the security and integrity of your data, providing an additional layer of transparency and accountability.
Farewell to the V2 Console
As we move forward, it's time to bid farewell to the V2 console, which will soon be phased out. Currently, the V3 console covers most of the features and functions, and you are primarily directed toward it when using Qovery's Kubernetes management software. However, there are still a few remaining elements to be transitioned, including the cluster/GitHub app and billing. Our team is working diligently to make the transition seamless and complete.
Wrapping up
Thank you again for joining us at this Demo Day and for your trust because our product, team, and vision would not be possible without your support. If you have questions, don’t hesitate to contact us on Forum or directly on the chat from our website.
We hope to see you at the next Qovery Demo Day and if you missed the live event, you can watch the replay below. 👇🏻
.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)