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

Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on your Qovery-managed infrastructure like any other service. Each agent runs with its own resources, environment variables, and a domain allowlist controlling exactly what it can reach.

​
Creating an Agent

1

Create an Agent Task

In your environment, open the Automations tab and click Create agent task. Choose Create from template to pick a ready-made template (see Ready-Made Templates below), or Create from scratch to configure every part yourself.While the environment has no agent task yet, the Automations tab shows the template catalog directly. Selecting a template opens the creation form pre-filled with that template.
2

Add Context (Optional)

Connect a Qovery service, a Git repository, or both, for the agent to load as context. A Qovery service’s linked Git repository is included automatically, no need to add it separately, connect a repository on its own only when it isn’t tied to a Qovery service.
3

Choose a Provider and Model

Pick Claude (Anthropic) or AWS Bedrock, then select an existing token or create a new one on the fly. A token created here is saved and can be reused by any other agent task in the organization, no need to re-enter credentials each time. Tokens can also be managed centrally from Organization Settings > Agent > Token. When you create an AWS Bedrock token, also select its AWS region (eu-west-1 by default).Once a token is selected, pick the Model the agent runs on from the list of models available to that token. The first available model is selected by default. For AWS Bedrock, the models offered depend on the token’s AWS region. If the models can’t be loaded, check the token’s API key (Claude) or its AWS credentials and region (AWS Bedrock). Use Edit token next to the token selector to update the selected token. You can change the model later from the agent task’s Settings > AI configuration.
4

Add MCP Servers (Optional)

If you added a Qovery service as Context in the previous step, Qovery’s own MCP server is created and selected automatically: organization-scoped, read-only, backed by a Viewer API token. No URL, header, or token to configure. This is also preconfigured for the Incident Analyzer (incident.io and Honeybadger) and Build & deployment optimizer templates.For anything else, connect any remote HTTPS MCP server with its own name, URL, and headers. MCP servers added here are available to every agent task in the organization and can also be managed from Organization Settings > Agent > MCP.To add Qovery’s own MCP server manually, for example with write access instead of the automatic read-only setup, use an API Policy Token (a regular API token works too):
  • Server URL: https://mcp.qovery.com/mcp
  • HTTP header name: Authorization
  • HTTP header secret value: Token <your API token or Policy API token> (Token with a capital T, then a space, then the token value)
5

Write Instructions

Describe the agent’s role and the steps it should follow in plain text. Reference credentials by the environment variable names you configure below, for example INCIDENT_IO_API_KEY.
6

Choose an Execution Mode

Run the agent in place, or in a clone of the environment. See Execution Mode below.
7

Add a Trigger

Required to run the agent automatically. See Triggers below.
8

Add an Output (Optional)

Send the agent’s result somewhere when it’s done. See Outputs below.
New agent task form with Context, Provider, MCP, Automations, and Instructions on the left, and Resources, Governance, Environment variables, and Advanced settings on the right

​
Ready-Made Templates

The template catalog groups the available templates by category: Sentry Incident Analyzer and Slack Coding Agent ship with a secret environment variable to fill in (SENTRY_AUTH_TOKEN and SLACK_BOT_TOKEN respectively), and a domain allowlist pre-filled with the hosts they need (sentry.io and *.sentry.io, or slack.com, plus GitHub, GitLab, and Bitbucket). Incident Analyzer and Coding Agent are not tied to a specific provider: they work on the payload sent to their webhook. If the template you need isn’t listed, click Request agent template in the Automations tab, describe the template you’d like Qovery to add next, and click Send request.

​
Execution Mode

Choose where the agent runs when it’s triggered:
  • In Place: runs directly in the current environment.
  • Clone Environment: duplicates the entire environment first, then runs the agent in that isolated clone.
In In Place mode, a new trigger replaces the currently running execution, there’s no run history if the agent is triggered multiple times. Use Clone Environment for agents that can be triggered frequently or concurrently, and In Place for agents on a predictable schedule where overlap isn’t a concern.
Each ready-made template has a sensible default: the Incident Analyzer and Coding Agent templates default to Clone Environment, since an incident, a ticket, or a request can trigger them frequently or concurrently. Build & deployment optimizer, typically run on a schedule, defaults to In Place.

​
Limits

  • Execution timeout: each run is capped at 1 hour.
  • Cloned environment TTL: environments created by Clone Environment mode are deleted 3 days after creation.
  • Iterations per run: up to 50 agent iterations per run by default. Override this with the MAX_TURNS environment variable. The creation flow in the Console pre-fills the MAX_TURNS variable with 200, which you can change before creating the agent task.
  • Clone rate limit: up to 60 clones per hour, per organization, to prevent runaway environment creation.

​
Triggers and Outputs

Add a trigger to run the agent automatically, and optionally an output to send its result somewhere when it’s done. You can also trigger any agent task on demand: click the Trigger (play) button on its overview page, or from the Agent tasks list in the environment’s Automations tab.
Agent task overview page with the Trigger play button highlighted in the top right

​
Triggers

  • On a schedule: a cron expression and timezone, for example 0 8 * * 1-5 for 8:00 AM, Monday through Friday.
  • From a webhook: Qovery generates a unique URL for the agent task, visible later by hovering Webhook in the Trigger column of the Agent tasks list in the environment’s Automations tab (for example https://webhook.qovery.com/api/v1/hook/...). Anything that can send a POST request to that URL starts the agent.

​
Outputs

Send the automation’s result to a webhook: a destination URL, custom headers, and a prompt describing how to shape the result before sending it. For example, to post the result to a Slack channel:
1

Create a Slack Incoming Webhook

In Slack, add the Incoming Webhooks app to the channel and copy the generated URL (https://hooks.slack.com/services/...).
2

Add the output in Qovery

In Add output, paste that URL into Webhook URL. No custom headers are needed, Slack’s incoming webhooks accept a plain JSON POST.
3

Write the prompt

In Prompt, describe the message you want, for example: “Summarize the result as a short Slack message with the root cause and the recommended next step.”
Some agents use a different, more direct pattern instead: storing a chat webhook URL as a secret (for example SLACK_WEBHOOK_URL), adding its hostname to the domain allowlist, and instructing the agent to post to it directly as one of its own steps. Use this pattern when the agent itself, not just the automation’s final output, should decide when and what to post.

​
Configuration

A description of what the agent does.
CPU (mCPU), memory (MiB), and storage (GB) allocated to the agent, same as any other Qovery service. CPU and memory are required, with a minimum of 1000 mCPU and 2048 MiB. The ready-made templates start at these minimums.
A domain allowlist controls which external hosts the agent task can reach: comma-separated hostnames, or * for all domains.
Plain variables or encrypted secrets the agent’s instructions can reference by name. Secret values can’t be viewed again once set.
A Dockerfile fragment lets you install additional CLIs or binaries in the agent’s runtime before it starts.
On an existing agent task, the Connections, Automations, and Outputs settings, and the Dockerfile fragment under Advanced settings, are edited in a modal or side panel and saved from there with Save. These pages have no page-level save button. If saving fails, the modal or side panel stays open and shows an error.

​
After You Create It

Agent tasks appear in the Agent tasks list of your environment’s Automations tab, one-time tasks delegated to AI agents. Each one lists its name, whether it is enabled, its state, its last operation, and its trigger: Schedule with the date of the next run (or Paused), or Webhook, whose dedicated URL you can call to trigger the agent from outside Qovery. That same webhook URL is also shown on the agent task’s own overview page.

​
Run History

The Runs tab of an agent task lists its runs, with these columns:
  • Date: when the run started and, once finished, when it ended (UTC), with the run ID. Hover the date to see the exact start and end times, or click the copy icon next to the run ID to copy it.
  • Status: Queued, Running, Completed, Failed, or Cancelled.
  • Trigger: Manual, Schedule, or Webhook.
  • Payload: the payload recorded for the run, or — when there is none.
  • Duration: how long the run took.
  • Prompt: the prompt the run used.
Click a run to open its Run details side panel, which shows the run ID, trigger, status, start and end times (UTC), duration, full payload, and full prompt. Until the agent task has run, the tab shows No runs yet: use the Trigger (play) button in the header to start one. The agent task’s overview page also has a Last run section showing the trigger, how long ago the latest run happened, and its status. Click it to open that run’s details, or click See all runs to go to the Runs tab. The Deployments tab of an agent task lists its deployments, like any other service.

​
Tutorials

Incident Analyzer with incident.io

Ready-made agent that correlates a firing incident.io incident with recent changes, logs, and metrics

Incident Analyzer with Honeybadger

Ready-made agent that correlates a firing Honeybadger incident with recent changes, logs, and metrics

Build & deployment optimizer

Ready-made agent that proposes faster, cheaper build and deployment configurations

Jira Coding Agent

Ready-made agent that picks up a Jira issue and proposes the corresponding code change

Linear Coding Agent

Ready-made agent that picks up a Linear issue and proposes the corresponding code change

Agent Tasks Overview

Use cases and ready-made agent templates