Jira and Linear Are Now a Trigger Into Your Governed Infrastructure

Jira and Linear Are Now a Trigger Surface Into Your Infrastructure

Qovery's platform already lets you define what runs, where it runs, and under what guardrails, whether the requester is a developer or an agent. Agent Triggers extend that same control plane to a new entry point: a ticket. Tag a ticket on Jira, or assign it to Qovery on Linear, and that ticket triggers the execution of a governed environment on your own Kubernetes cluster, the same way a webhook or an API call already can.

What makes that possible is the same thing that makes every other Qovery environment governed: the trigger doesn't hand an agent raw access to anything. It spins up a dedicated environment scoped to that one ticket, carrying the credentials, the network rules, and the guardrails your platform team already defined, the same way any other environment on your cluster would, and it's inside that environment that an agent performs whatever action it's configured for, given the context of that ticket. The agent's configuration and the triggering logic, which Jira or Linear project to watch, live in a Blueprint you define once, so every ticket in that project inherits the same setup without anyone repeating the config by hand.

A webhook can fire a call. It can't give what it triggers somewhere governed to run - that still has to be assembled separately, usually on a laptop or an unmanaged sandbox with no network rules of its own. Qovery can wire a ticket directly to a real, governed environment because environments are already the platform's foundational primitive, for every workload, human or agent. Qovery updates the ticket status live as the environment runs, and reports back through it.

What This Unlocks

The most immediate use case is the one every team asks for first: point the trigger at a coding agent, and a ticket becomes the way you delegate a task instead of assigning it to a person. The environment the trigger spins up runs the agent with the prompt template, the Claude or Codex API token, and the guardrails your team configured, and the agent works from the spec already in the ticket and opens a PR. If that environment also carries other services the task needs, a PostgreSQL instance, another internal service, the agent can validate its own change against them before a human reviews it.

That outcome depends on the coding agent and the prompt behind it, not on Qovery. What Qovery owns is the layer underneath: the trigger, the environment it runs in, and the guardrails that hold regardless of what's running inside it. The same trigger surface works for anything else you'd want a ticket to kick off inside a governed environment, a coding agent is simply the first and most common thing teams point it at.

Outcomes for Your Platform Team

• A new governed trigger, not a new exception: a ticket now reaches infrastructure the same way a webhook or an API call already does, under the same rules.
• One config, reused across every ticket: a Blueprint defines the agent setup and which Jira or Linear project to watch, so nobody repeats it per ticket.
• Guardrails don't bend for the use case: network rules and scoped credentials apply to whatever runs inside the environment the trigger spins up, whether that's a coding agent today or something else tomorrow.

What This Looks Like in Practice

A platform team at a mid-market fintech used to lose ten minutes per task re-explaining a Linear ticket to a separate agent tool before anything happened. Now a ticket in that project triggers a governed environment directly: it spins up alongside the PostgreSQL instance the task needs, the coding agent inside it works from the ticket as written, and it opens a PR checked against that database. The platform team never had to build a special path for this, it's the same trigger and guardrail model they'd use for anything else.

Get Started

Agent Triggers is available today in closed beta. If you're an existing customer, contact your CSM to get set up.