Hey Team,

One important thing before we get into what shipped. As you may have already seen on our landing page and in the newsletter Romaric sent out, Qovery is now positioning as an agentic infrastructure platform. Not a pivot: it is the same platform teams already run production infrastructure and applications on, extended so agents can operate it just as well as humans do. Our customers pulled us into naming it that way, because the moment they put AI agents to work, infrastructure was the first thing to break, GitOps, Terraform, and review flows were built for how humans work, not for the volume and pattern of agentic operations.

Qovery's answer is to be the control plane where agents and humans provision, deploy, observe, secure, and optimize infrastructure together, with the separation between control plane and data plane that regulated teams need. Romaric wrote up the full story: how the market pulled us into becoming an agentic platform.

This release moves that story forward on four fronts: a new MCP tool that lets agents query cluster state directly, encryption control for regulated GCP workloads, a clearer path through onboarding, and cost visibility that goes beyond dashboards into actionable recommendations.

🩺 Cluster state, queryable by any agent

Troubleshooting a cluster today usually means jumping between kubectl, dashboards, and logs to piece together what is actually happening across nodes, pods, storage, certificates, and networking. That works when a human is doing the digging. It does not work when an agent is.

The Qovery MCP Server now exposes a tool that returns the full state of your Kubernetes objects on demand, whether you want the complete picture or want to zoom into a specific area like pods, networking, certificates, or nodes. Every query goes through the same governed path as any other MCP operation, so it shows up in your audit logs like everything else an agent does on your infrastructure. This is the agent-native governance piece of the platform in practice: agents get real, structured visibility into cluster health, and you get a full record of what was queried, when, and by whom.

🔐 CMEK on GCP: bring your own encryption key

Customers in healthcare, fintech, and other regulated markets have been asking for control over the encryption keys protecting their cluster data, rather than relying solely on Google-managed keys.

Customer-Managed Encryption Keys (CMEK) are now supported on GCP clusters. You can create your own KMS key and provide it when creating a cluster. That key then encrypts node boot disks, etcd data, storage buckets, and persistent volume disks, so the encryption layer is under your organization's control rather than Google's default.

This matters most for teams that need to demonstrate key ownership and rotation policy as part of a compliance audit. Full setup requirements are in the CMEK documentation.

🧭 A clearer path through onboarding

Getting a new team from signup to a running production setup involves a lot of decisions: which cloud provider, managed or self-managed cluster, how to structure projects and environments. The old onboarding flow surfaced these choices but did not adapt much to what the user was actually trying to do.

The onboarding experience now leads with the Qovery Skill, so if you work from a coding agent, whether that is Claude Code, Codex, or another one, you can run the entire setup directly from your terminal instead of clicking through the console. For everyone else, onboarding now gives a clear task list scoped to your actual goal: spinning up ephemeral environments, delegating day-2 Kubernetes operations, or going from spec to production with agents. Instead of one generic checklist, you get the steps that matter for what you are building.

📊 Cost recommendations powered by KRR

Observability gives you visibility into resource usage, but turning that into a concrete right-sizing decision has usually meant exporting metrics and doing the analysis yourself.

We have integrated KRR (Kubernetes Resource Recommender) into the Qovery engine. If you are on the Observability product, you can now run:

qovery cluster analysis cost-recommendation -c <cluster_id> ... <OPTIONS>

This prints resource recommendations for your applications based on actual historical usage over a configurable time window, so you can see where requests and limits are oversized before you act on them. Like the cluster state tool above, these recommendations are also exposed through the CLI and API, so an agent can pull them and act on right-sizing as part of its own workflow, not just a human running the command by hand.

🛠️ Minor updates

  • Qovery Copilot now runs on Sonnet 5, with improved response quality across troubleshooting and configuration tasks.
  • Qovery Copilot's self-remediation has been improved, so it recovers more reliably when it hits an error mid-task instead of stopping and waiting for input.
  • The Qovery Terraform provider adds two new resources, qovery_organization_member and qovery_custom_roles, so team membership and custom role definitions can now be managed as code.

📚 Worth a read

🔭 What's coming next

We are expanding the Qovery Agentic Workflow, currently available to a closed set of customers, to support both Linear and Jira as trigger sources. A ticket assigned to the agent spins up a full sandbox clone of your production stack, app, database, services, and seed data, on your Kubernetes, so it can code, test, and iterate against real conditions instead of guessing. You get back a pull request that has actually been exercised end to end, not just a diff that looks right and breaks in staging. If you want to try it early on Linear or Jira, reach out to your CSM.

We are also wiring the new cluster state tool directly into the qovery-troubleshoot skill, so an agent diagnosing a cluster issue reaches for structured Kubernetes state as a first step instead of piecing it together from logs and kubectl.

As always, let us know what you think and what you would like to see next.

Talk soon, The Qovery Team 🚀