Skip to main content
Early Preview. Agent Tasks is available in early preview to a limited set of organizations. Capabilities and setup will change before general availability.

​
Overview

Analyzes build and deployment speed for a service or environment with the qovery-speedup skill, then opens a PR for each proposed change. The template’s instructions tell the agent not to apply any change directly, and never to merge a PR on its own.

​
How It Works

To find concrete ways to make builds and deployments faster and cheaper, the agent:
  1. Loads the qovery-speedup skill and follows it to analyze build and deployment speed for the current service or environment.
  2. Inspects the setup, identifies the bottlenecks, and diagnoses their root causes, including whether a slow build is an avoidable image-mirroring miss.
  3. For every proposed change to a file in a repository (Dockerfile, build configuration, Infrastructure as Code such as Terraform), opens a PR on the relevant repository with a before/after and the expected gain. It never merges it.
  4. For a change that can only be made from the Qovery Console or API, it does not call the mutating endpoint. It lists the change as a recommendation in its summary, with the exact change needed and the expected gain.
  5. Finishes with a summary of what it found, what is proposed in which PR, and what needs a human decision. The human always stays the gate.
The template’s domain allowlist is pre-filled with github.com, api.github.com, raw.githubusercontent.com, gitlab.com, bitbucket.org, and api.bitbucket.org.

​
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 Qovery service to optimize as its Context, its linked Git repository is included automatically so the agent can inspect the Dockerfile and build setup. Add a repository on its own only if it isn’t tied to a Qovery service.
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).The template’s instructions tell the agent never to apply changes to Qovery directly. If you edit the instructions to let it apply changes, 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 PRs it opened and the recommendations in its summary.
See Configuration for resources and environment variables, general settings shared by every agent task.