Announcement: New Qovery Support Plans
This change will be effective starting from the 15th of April 2024.
New support plans
Below, you can find the three support plans that will be available in our offer
Community support (default)
This is the default support plan for any organization, regardless of your product plan. Community Support is designed for testing or early development on Qovery for individual developers and small teams who require query support. You can submit support requests directly within our community forum, and one of our engineers or another client will respond to your request. Please note that there is no guaranteed response time.
Here's a brief recap of what's included:
- Price: Free (included in your product plan)
- Channel: Community Forum, within the dedicated section to collect your product support requests (how to do X, bugs etc...)
- Number of requests/month: Unlimited
- Response time: no response time is guaranteed
- Support available: Monday to Friday, 9 am-6 pm (CET).
Business support
Business Support is the recommended Qovery Support tier if you have production or business-critical workloads and require 24x7 access to Qovery technical support. With this tier, you can open a fixed number of priority requests to our support team, each with a guaranteed response and resolution time.
- Price: 500$/Month
- Channel: Intercom tickets
- Number of priority requests/month: 5 (Bugs are not counted)
- Response time: guaranteed time to answer and time to solve, depending on the severity of the request (see more details on our support plan page).
- Support available: Monday to Friday, 9 am-6 pm (CET).
Here's a small video on how to raise a request via Intercom:
Enterprise support
Support plan tailored to meet your internal requirements. Have a look at our support plan page for more information.
FAQ
Does this change impact me?
Yes, if you are on a monthly plan or have no support plan included in your annual agreement with us. Users who already have a support plan included in their contract are not impacted.
How can I upgrade my support plan?
Contact us on Intercom via the "Billing/Pricing" option.
I'm on the community plan, can I raise any priority requests?
Yes, with an additional cost of 150$ per request. Contact us on Intercom via the "Billing/Pricing" option to unlock it.
I'm on the business plan, can I raise any priority requests if I have already used my 5 monthly requests?
Yes, with an additional cost of 100$ per request. Contact us on Intercom via the "Billing/Pricing" option to unlock it.
How can I see the priority requests opened by my company?
If you have a Business or Enterprise plan, you can access the requests opened by your company from our help center. Note that you can participate and comment on any of the opened requests, no matter who opened it within your company.
How can I provide product feedback or ask for a new feature?
You can either raise your idea directly in our product roadmap or open a discussion topic in our feature request section within our forum.
How can I contact you for any questions on the Qovery pricing/billing?
Contact us on Intercom via the "Billing/Pricing" option.
.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)