3 Pro Tips To Get The Most Out Of Qovery - Part 1
1. Filter the logs
For the first tip, we’ll be speaking about logs; let’s say you have plenty of pod names in your application logs. Still, suppose you want to focus on only one. In that case, looking for all the pods with the same name can become quickly messy and time-consuming. To avoid the headache, you can filter the logs by pod name.
How does it work?
- Head to your application logs
- Click on the pod name you wish to select
- A filter will make only the one select visible.
- To unselect, click on the cross near your pod name
Here is a small video to show you how it works in action 🎬
2. Cost Optimization
Developers in your company work from 9-to-5, five days a week. Keeping all development environments running during the weekend, at night, and outside working hours may be a considerable expense that gives you no benefits.
Using the Deployment Rules is a good practice to reduce your cost drastically. Indeed, Qovery knows how to optimize your Cloud resources when your applications are not running. Then you can expect to reduce your Cloud cost by up to 60% using the Deployment Rules.
How does it work?
- Navigate to Console
- Select your project
- In the project overview, click the Settings button:
- In the popup, select Deployment Rules and add New:
Then you need to add the rules that apply to your company, and all set 🤩
3. Clickable message on Rollback
This tip will be handy if you are using the rollback feature (more about it on this changelog); when you make a rollback, the commit messages are clickable, so you can easily access your commit on git without having to search for it for hours, camera, live, action!
How does it work?
- Head to the console and in your application, click on the action panel.
- Then click on deploy other version and choose the version you want to open.
- Once clicked, you will be automatically redirected to the Git page of the selected branch.
Magic, isn’t it? 🪄
Wrapping up
Whether you’re planning to filter the logs, click on a rollback message, or start with cost optimization, I hope that those small tips were helpful to you and if after your time spent on Qovery you have tips or tick, don’t hesitate to post it on the forum and maybe we can even share one of yours in the second part 🚀
.svg)
.svg)
.svg)
Suggested articles
Kubernetes is a distributed orchestration engine that automates container deployment and scaling. At an enterprise level, its core mechanisms—control planes, schedulers, and worker nodes—provide foundational infrastructure resiliency. However, operating these components natively across thousands of clusters creates massive configuration drift, requiring intent-based control planes to manage Day-2 FinOps, RBAC, and multi-cloud abstraction globally.
Kubernetes autoscaling relies on three dimensions: horizontal (pod count), vertical (resource size), and cluster (node count). While CPU-based scaling is standard, enterprise fleets require advanced Day-2 strategies (such as custom Prometheus metrics and priority-class overprovisioning) to prevent node boot delays and memory bottlenecks during severe traffic spikes.
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 is an open-source container orchestration engine. At enterprise scale, it abstracts infrastructure to automate deployment, scaling, and networking. However, managing hundreds of clusters introduces severe Day-2 operational toil, requiring agentic control planes to enforce global governance, security policies, and cost optimizations across multi-cloud fleets.
The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards
Effective Kubernetes management in 2026 demands a shift from manual cluster building to intent-based fleet orchestration. By implementing agentic automation on standard EKS, GKE, or AKS clusters, enterprises eliminate operational weight, prevent configuration drift, and proactively control cloud spend without vendor lock-in, enabling effective scaling across massive fleets.
A Kubernetes single pane of glass is a centralized management layer that unifies visibility, access control, cost allocation, and policy enforcement across § cluster in an enterprise fleet for all cloud providers. It replaces the fragmented practice of switching between AWS, GCP, and Azure consoles to govern infrastructure, giving platform teams a single source of truth for multi-cloud Kubernetes operations.
Deploying a Docker container on Kubernetes requires building an image, authenticating with a registry, writing YAML deployment manifests, configuring services, and executing kubectl commands. While necessary to understand, executing this manual workflow across thousands of clusters causes severe configuration drift. Enterprise platform teams use agentic platforms to automate the entire deployment lifecycle.
.webp)