Hey Team,

AI agents are provisioning infrastructure now, not just writing code, spinning up a database or a full environment in seconds, faster than any ticket queue or manual review was built for. That leaves platform teams with the same old choice, hand-build every request or hand out raw access, except now an agent can act on that access at machine speed. This is why we built and shipped Qovery Blueprints.

Alongside it, this release also brings a round of Builders Portal improvements.

🧱 Qovery Blueprints: self-service infrastructure with guardrails built in

Provisioning a MySQL, PostgreSQL, Redis, or S3 bucket has always forced platform teams into a bad trade-off: build the Terraform service by hand for every request, human or agent, and each new database becomes a ticket in someone's queue, or hand out direct access instead and lose any guardrail on what gets deployed, at what cost, or for how long. That trade-off only gets worse across a full environment, and handing an agent the same raw keys you would hesitate to hand a developer is a different order of risk, since nothing pauses to sanity check a config running at machine speed.

Qovery Blueprints are reusable, composable infrastructure elements with guardrails built in, replacing the old managed databases offering with something platform teams can actually govern. Out of the box, Qovery ships Qovery-maintained Blueprints for the infrastructure blocks every team eventually needs: MySQL, PostgreSQL, S3, Redis, and more. A developer, or an agent using the Qovery deploy skill, adds a new service, picks a Blueprint, fills in the required fields, and deploys, skipping both the ticket and the hand-written Terraform.

Read the full story on why this had to happen now: Qovery Blueprints, another building block toward agentic infrastructure.

🖥️ Builders Portal: fewer papercuts, more reliable chat

The Builders Portal is where you spend most of your time provisioning and iterating with Qovery, so this release focuses on cleaning up the rough edges that showed up the most in day-to-day use.

Chat sessions now survive a reload instead of disappearing mid-conversation, including on a hard refresh, so an unsent draft or an in-progress exchange with the agent is no longer lost the moment the page reloads. We also fixed an issue that was causing the portal to reload unnecessarily, which was interrupting work for no reason. On top of that, error messages across the portal and chat now show the actual underlying message instead of a raw JSON blob or a generic failure, so when something does go wrong, you know what happened without digging through the network tab. The Create Project blueprint picker is also now scrollable, useful now that the list of available Blueprints keeps growing.

  • Chat sessions and unsent drafts persist across reloads, including hard refreshes
  • Fixed unnecessary page reloads in the portal
  • Portal and chat errors now surface a readable message instead of a raw error blob
  • The Create Project blueprint picker is now scrollable

🛠️ Minor updates

  • Service deployments can now be triggered even if the target cluster is not currently running. The deployment is queued and executes automatically once the cluster comes back up, instead of failing outright.

🔭 What's coming next

We are working on extending Qovery Copilot to help troubleshoot errors you might hit while deploying a cluster, the kind that usually require deep Kubernetes and cloud provider knowledge to even start diagnosing. The goal is to make that class of error approachable without needing a platform expert on hand, so a cluster-level failure is something you can resolve in minutes instead of escalating. If you want to try it early, reach out to your CSM.

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

Talk soon, The Qovery Team 🚀