Overview
Identifies build and deployment optimization levers and their expected gain, then opens a PR with the proposed change and/or updates the build configuration in Qovery directly. It never merges a fix on its own.How It Works
To find concrete ways to make builds and deployments faster and cheaper, the agent:- Inspects the service’s build setup: Dockerfile, dependency installation, layer caching, image size, and the build/deploy configuration in Qovery.
- Identifies optimization levers, for example better layer ordering and caching, multi-stage builds, smaller base images, pruning unused dependencies, or parallelisable steps.
- For each lever, estimates the expected gain (build time, image size, or cost) and the risk.
- Opens a PR with the proposed changes to the build configuration, and/or updates the build configuration in Qovery directly.
- Summarises what it changed, the expected gain, and anything that needs a human decision. It never merges, the human always stays the gate.
Setting It Up
1
Create the agent task
From the Agent use cases section when creating a new service, pick Build & deployment optimizer (see Creating an Agent), or start from scratch and paste in the instructions above.
2
Connect the repository
Add the Git repository of the service to optimize as its Context, so the agent can inspect the Dockerfile and build setup. You can also add the Qovery service itself as Context, alongside its repository.
3
Add the Qovery MCP server
Since you added the service as Context, Qovery’s own MCP server is created and selected automatically: organization-scoped, read-only, backed by a Viewer API token. That’s enough for the agent to propose changes (open a PR).To let it apply changes to Qovery directly instead, add the MCP server manually with an API Policy Token that has write permissions on that service’s build/deploy configuration. See Add MCP Servers.
4
Add a trigger
Add a schedule trigger, for example weekly, to periodically review build performance, or a webhook trigger. See Triggers for how they work in general.
5
Keep In Place as the execution mode
This agent is typically run on a schedule rather than triggered concurrently, so In Place (the default) works well. Use Clone Environment instead if you expect overlapping runs. See Execution Mode.
6
Trigger a first run and check the results
Click Trigger on the agent task’s overview page to run it on demand. Check the run under its Deployments tab, and review the PR it opened (or the build configuration it updated, if you granted write access).