Webinar Sept 24: Heroku to AWS in one command, with an agent doing the work.
Integrations

Bring your own agent. The boundary stays the same.

Qovery does not care which coding agent you run. Eight skills install with one command and work across 30+ tools, because what an agent is allowed to do is decided in the API underneath rather than in the agent itself. Swap Claude Code for Codex tomorrow and your guardrails do not move.

Start free trialRead the docs
Guides by agent

Set up in one command.

Same install, same eight skills, same boundary. These pages cover the connection details and what changes per agent.

Recommended

Claude Code

Anthropic
Setup guide →
Supported

Gemini CLI

Google
Setup guide →
Supported

OpenAI Codex

OpenAI
Setup guide →
Also supported

Cursor · OpenCode · VS Code Copilot · Roo Code · Goose · Amp · Junie · Kiro · OpenHands · Mistral Vibe · TRAE - and any tool that discovers skills from .claude/skills/, .config/opencode/skills/ or .agents/skills/.

One install

Eight skills, every agent.

The installer places all eight skills, with their reference material and slash commands, wherever your tools look for them. Re-run it to update.

qoveryEntry point.
qovery-onboardGuided setup.
qovery-deployDeploys any application to Kubernetes.
qovery-troubleshootEight-layer diagnosis across deployment status, build and runtime logs, health checks, env vars, networking, resources and cluster.
qovery-optimizeAnalyses historical CPU and memory against allocation across seven optimisation dimensions, estimates external cloud costs, and produces a markdown report plus CSV export.
qovery-speedupMeasures the deployment pipeline stage by stage, classifies each bottleneck as yours or Qovery infrastructure, and proposes Dockerfile and health-check fixes with before and after timings.
qovery-previewCreates a preview environment from a pull request.
qovery-terraformReads an existing Qovery setup from the API and generates HCL for the qovery/qovery provider, imports resources into state, and validates against a test clone before you commit.
# Install all eight skills, globally
$ curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scope them to the current project only
$ curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project
The boundary

Agnostic about the agent.
Specific about what it may do.

Swapping agents changes the interface. It does not change any of this, because none of it is something the model is asked to respect.

Read-only by default

The Qovery MCP Server connects in read-only mode unless you say otherwise. Your agent can list environments, read service state, and tail logs. It cannot change anything.

Write access is two deliberate switches

Writes require read_write=true on the connection URL and a separate write-access setting enabled in the Qovery Console. Neither one is something a model can talk its way into.

Scoped by the RBAC you already run

An agent authenticates with its own API token and inherits the permissions of the role that token was issued under. Agents do not get a parallel access model, and they do not consume user seats.

Every action lands in the audit log

MCP tool calls and API operations are recorded in the Qovery Console audit trail against the token that made them, which is what turns "an agent did something" into an answerable question.

Agents and Qovery.

Which AI coding agents work with Qovery?
The Qovery agent skills follow the Agent Skills open standard, so they work with 30+ tools. The published compatibility table lists Claude Code, OpenCode, Cursor, VS Code Copilot, Gemini CLI, Roo Code, Goose, Amp, Junie, Kiro, OpenHands, OpenAI Codex, Mistral Vibe and TRAE, plus any tool that discovers skills from .claude/skills/, .config/opencode/skills/ or .agents/skills/.
Do I need a different setup for each agent?
No. One command installs all eight skills in every location a compatible tool looks in: curl -fsSL https://skill.qovery.com/install.sh | bash. Qovery is agnostic about which agent you use, which is the point. The permission boundary is in the API, so it does not change when you switch agents.
What is the difference between the Qovery skills and the MCP Server?
The skills deploy and the MCP Server operates. Skills take you from source code to a running application: analysing the codebase, writing a Dockerfile, provisioning a database, deploying. The MCP Server manages infrastructure that already exists: querying state, reading logs, triggering deployments. Most teams use both.
How do I stop an agent doing something destructive?
The boundary sits outside the model. MCP access is read-only by default; write access needs read_write=true on the connection URL and a separate setting enabled in the Qovery Console. Agents authenticate with their own API tokens and inherit that role RBAC, and every action is recorded in the audit log. None of that is a prompt the model can argue with.
Do AI agents consume Qovery user seats?
No. Agents authenticate with their own API tokens and there is no limit on how many you run. They inherit scoped RBAC permissions and are audited exactly like a human user. What they consume is deployment minutes and environments.

Get started

Your agent already knows how to deploy.
Point it at infrastructure you own.

One install command, your own AWS, GCP, Azure or Scaleway account, and a boundary you set once instead of restating in every prompt.

Start free trialTalk with us