Your Agents Need Infrastructure Too. Meet Qovery Blueprints.
AI agents are provisioning infrastructure now, not just writing code. Qovery Blueprints let you define what an agent, or a developer, is allowed to deploy and under what cost rules, so that self-service or delegation doesn't mean losing control.
AI agents are provisioning infrastructure now, not just writing code. An agent working through a deployment pipeline can spin up a database, a cache, or a full environment in seconds, at a speed no ticket queue or manual review was built for. Platform teams have always had to choose between hand-building every database request or handing out raw infrastructure access, and neither option was built with that speed in mind. Qovery Blueprints let you define what an agent, or a developer, is allowed to deploy and under what cost rules, so that self-service or delegation doesn't mean losing control.
The Bottleneck-or-Blank-Check Trade-off
Give an agent the keys to provision infrastructure the same way a developer would, and the choice a platform team already lived with gets a lot sharper. Either the platform team builds the Terraform service in Qovery themselves, a custom manifest for every request, which means every agent request for a new database queues up behind a human the same way a developer's would. Or the platform team hands out raw infrastructure access so the agent isn't blocked, which clears the queue but hands over unguarded access to something that can act at machine speed, with no one pausing to sanity check a config before it runs.
Handing a developer the keys was already a stretch. Handing the same keys to an agent, with no guardrails on what gets deployed, at what cost, or for how long, is a different risk entirely, because there's no human in the loop to catch a bad config before it becomes a running instance.
Either way, a team gets control or it gets speed, not both, and the same trade-off holds whether the requester is human or not. It only compounds once it's not one service but an entire environment. A database, a cache, storage, and an app tier all needed together, since assembling that by hand or handing out access to all of it multiplies whichever trade-off a team already made.
🧩 Blueprints: Self-Service Infrastructure With the Guardrails Built In
Blueprints are another building block toward Qovery as an agentic infrastructure platform, one where humans and agents self-serve infrastructure under the same rules, instead of agents becoming the exception nobody has a governance model for.
Qovery Blueprints are reusable, composable elements with guardrails built in. Out of the box, Qovery provides a set of Qovery-maintained templates for the infrastructure blocks every team eventually needs: MySQL, PostgreSQL, S3, Redis, and more. They replace the old managed databases offering with something platform teams can govern instead of just hand out. An agent working through the Qovery deploy skill adds a new service, picks one of the Qovery-provided Blueprints, fills in the required fields, and deploys, skipping the ticket and the hand-written Terraform entirely. A developer does the exact same thing from the Qovery UI. Advanced settings are still there for anyone who needs to go deeper, but the default path is self-service.
Filling in the required fields for an AWS RDS MySQL Blueprint in Qovery
The governance lives inside the platform, not bolted onto it. Qovery already knows who's requesting what, on which environment, on which cloud, so a Blueprint carries access rules (who can deploy it) and cost rules (time to live, auto start and stop) as part of the deployment itself, not as a policy someone has to remember to enforce. And because Qovery provides these Blueprints out of the box, deploying the most common infrastructure resources, on any cloud you run on, is just as easy whether it's a first deployment or a greenfield move to a new provider.
A Blueprint isn't a one-time template either. When Qovery updates a Blueprint, or a platform team updates one it defined itself, that change propagates to every instance already deployed from it. A patched default, a tightened cost rule, or a new guardrail doesn't just apply to the next deployment, it rolls out across every MySQL, Redis, or S3 instance created from that Blueprint, without anyone having to track down and update each one by hand.
Outcomes for Your Team
Reduced blast radius: a Blueprint's access rules and cost constraints hold whether the requester is an agent or a developer, so handing an agent a Blueprint never means handing it raw, unbounded infrastructure access.
Faster delivery: an agent, or a developer, gets a MySQL or Redis instance the moment it's needed, not after a round trip through the platform team's backlog.
Less waiting on platform and DevOps: Blueprints turn routine provisioning requests, agent or human, into self-service, so the platform team only gets pulled in for the exceptions that actually need a human.
Cloud portability: Qovery provides an equivalent Blueprint across cloud providers, so a greenfield migration to a new provider doesn't require rebuilding how every agent or team provisions infrastructure.
How Teams Provision Infrastructure, Today and Where It's Headed
Today, a FinTech's platform team keeps finding Postgres instances they didn't know existed. A CI pipeline spins one up for every integration test run, and because nobody's watching that request in real time, some of them outlive the test and sit there accruing cost until someone notices during a monthly cloud bill review.
With Qovery: they set up a Postgres Blueprint with a 7-day time to live and auto-stop outside business hours. The pipeline requests it through the Qovery deploy skill, fills in the required fields, and deploys without opening a ticket or waiting on a human to review the request, the same way it already does today with no guardrails. Because the Blueprint already encodes who's allowed to request what and under what constraints, that request is governed by the same rules as a developer's, not treated as a special case needing its own security review. The platform team stops finding orphaned databases after the fact and only steps in when something falls outside the Blueprint's scope.
Where it's headed, that same platform team defines its own Blueprints instead of only consuming Qovery's, with scoped RBAC controlling who, or what, inside the org can request which Blueprint, on which environment, at what cost ceiling. The mechanism itself extends past single services to entire environments, so an agent or a developer can provision a full stack, database, cache, storage, and app tier together, in one request instead of assembling it service by service. An agent requests a whole environment from an approved Blueprint the same way a developer would, with the same access rules and cost ceilings applying either way.
Give self-service infrastructure its guardrails.
Deploy a Qovery-provided Blueprint for MySQL, PostgreSQL, S3, Redis, and more, with access and cost rules built into the deployment itself.
Add a new service, from an agent using the Qovery deploy skill or from the Qovery UI, and choose from Qovery-provided Blueprints: MySQL, PostgreSQL, S3, Redis, and more.
Fill in the required fields. Advanced settings are available if you need to go deeper.
Deploy.
Get Started
Book a demo to see Blueprints in action, or log into your Qovery organization and add a Blueprint-backed service directly, no waitlist required.
