Stop Building Your Own Agent Infrastructure. Meet Agent Tasks
Agent Tasks let you run one-time or scheduled AI agents on your own infrastructure, with network guardrails, centralized MCP access and custom agent environment.
Running AI agents safely means either sending your data to someone else's infrastructure or building your own event receivers, schedulers, and Helm charts just to keep the agent on your side of the perimeter. For every team that's shipped a production agent, that's meant weeks of infrastructure work before a single agent has done anything useful, plus ongoing maintenance to keep it patched and secure. And if your data is sensitive, you're either proving to security that the agent can be trusted with it, or scoping the agent down until it's not useful enough to bother with.
Agent Tasks: Agents as a First-Class Workload
Agent Tasks treat AI agents as a first-class workload on Qovery, so an agent gets the same infrastructure control, network boundaries, and data residency as any other service in your stack, instead of becoming a new, ungoverned surface to secure on its own. That's what lets a single Agent Task be a PR reviewer that checks out a branch on a private repo and comments with findings, a nightly build and deployment optimizer that queries your deployments, or an incident responder that pages itself into your observability stack, each running on your infrastructure with only the access you gave it.
Instructions. Write the system prompt that defines what the agent actually does, a few templates are there to show you how a task is put together, but the logic is yours.
Context. Connect the sources that give it context, one or more git repositories, an observability tool, or an internal API, through MCP servers and secrets managed centrally in your organization settings. Since it's a workload like any other on Qovery, it can also interact directly with other applications and databases you run.
Boundaries. Set network egress rules that constrain exactly which domains and IPs it's allowed to reach.
Trigger. Fire it however fits the use case, on a schedule or via webhook, without building the receiver and scheduler yourself.
Agents that ship fast, without going off the grid.
Agent Tasks run entirely inside your own infrastructure, so agent execution never leaves your compliance boundary.
Example: An Incident Response Agent With Actual Context
Picture an on-call rotation getting an alert from the observability stack at 2am. Instead of paging an engineer cold, the alert fires a webhook that kicks off an Agent Task built for exactly this. It gathers the incident details, pulls the relevant metrics from the observability tool, checks the git repository for the code and runbooks tied to the affected service, and queries Qovery directly for the last deployment and cluster state. Its network rules allow it to reach exactly two places outside Qovery: Slack and your git remote. A few seconds later, a Slack message lands with a root cause, a proposed fix, and a PR ready for review. The engineer who does get paged starts from an answer, not a blank incident channel, and can keep the conversation going with the same agent if they need more context.
Get Started
Agent Tasks are live in beta and open to everyone today. Create one from scratch or from a template, and you'll have it wired to real context and running on your infrastructure in minutes.
