Qovery Free: A Live Environment for Every Agent PR, on Your Own Cluster

Key points:

• Qovery Free runs on a Kubernetes cluster you already operate, version 1.31 or later: EKS, GKE, AKS, k3s or on-premise. You get 3 users, AI agents don't count as users, 1 cluster, and 1,000 deployment minutes a month. No credit card, no time limit.
• Want to try it first? Run qovery demo up on your laptop before you connect a real cluster.
• Preview environments and environment cloning are included. Every pull request against your base branch gets a copy of a blueprint environment (apps, databases, variables and secrets) with its own URL, and Qovery deletes it when the PR is merged or closed.
• Built for teams whose coding agents already open more PRs than reviewers can run locally. Claude Code, Cursor and Codex can also drive Qovery directly through the MCP server, the CLI and Qovery Skills.
• At 1,000 minutes, deployments stop until the next month or an upgrade. Nothing gets billed by surprise.
• Moving later from your own cluster to a Qovery-managed one is a migration. You create the new cluster and move environments onto it. There is no single switch.

A good part of the pull request queue now comes from Claude Code, Cursor or Codex, and nobody has run that code anywhere. Reading a 600-line diff tells you whether it looks right. It doesn't tell you whether the checkout flow still works against a real database.

The fix teams reach for is the same one that worked for human PRs: a running environment per pull request, with a URL in the PR. Qovery has shipped preview environments since 2021. Starting today, you can run them on the cluster you already have without paying for anything.

What Qovery Free includes

These are the limits as published on the pricing page:

A "user" is anyone with access to the Qovery console. Agents that call the Qovery MCP server, CLI or API authenticate with their own API tokens, inherit scoped permissions, and don't take a seat. A team of three engineers running ten agents stays on Free.

A deployment minute is one minute of build and deploy time across any service, so an idle preview consumes none.

Who it is for

Free fits teams that already run Kubernetes, already use coding agents, and have reviewers as the bottleneck. You don't want to hand-write an Argo CD ApplicationSet, DNS scheme and cleanup job per repo, and you don't want a vendor hosting your app.

Qovery runs inside your own cloud account and your own cluster. It is an Agentic DevOps platform: it deploys and operates what runs on your cluster. It never hosts your applications on its own infrastructure.

If you want to see Qovery before connecting anything, try it first on your laptop with qovery demo up (compared below). If you don't run Kubernetes yet, Free is the wrong starting point. Start the 14-day trial on a paid plan instead, where Qovery can create and manage the cluster for you.

How it works, in 3 steps

1. Connect your cluster. Your cluster needs Kubernetes 1.31 or later. Install the CLI, sign in, and run qovery cluster install. The command asks a few questions (cluster type, region, registry credentials, Let's Encrypt email), writes a Helm values file, and prints the helm commands to run against your cluster. The Qovery agent and its components land in a qovery namespace. The EKS walkthrough has every command.

curl -s https://get.qovery.com | bash
qovery auth
qovery cluster install

2. Create a blueprint environment. Deploy one working copy of your stack (frontend, API, Postgres, Redis, workers) and clone it into an environment called blueprint. Point each application at your base branch, usually main or staging. Then open the blueprint's Settings, go to the Preview environments tab, switch on Turn on Preview Environments, and pick which services get a preview when a PR is opened on them.

3. Let the agent open PRs. When a PR targets the base branch, Qovery clones the blueprint into a new environment, deploys the PR branch, and posts the environment links as a comment on the PR. New commits redeploy it. Merging or closing the PR deletes it. If you only want previews for some PRs, switch on Create on demand and comment /qovery preview on the PRs that need one, which is a good default when an agent opens a lot of small PRs.

One detail to plan for: databases are cloned as instances, with their configuration, and their data stays behind. Seed each preview with a lifecycle job that runs on environment start, using fixture data that is safe to share.

The Claude Code + GitHub Actions tutorial walks through the agent side end to end.

Free vs Starter trial vs local demo

qovery demo up creates a k3s cluster with k3d, installs Qovery on it and registers it in your organization. It needs Docker running and about 4 GB of RAM, and it doesn't run from native Windows (use WSL). It is a sandbox. Your teammates and your agent's PR links can't reach a cluster on your laptop.

What happens at 1,000 minutes

Deployments stop, and nothing is charged. Free has no overage: new builds and deploys resume with the next month's allowance, or right away if you upgrade to a paid plan.

To estimate how far 1,000 minutes goes, time one preview deployment of your stack. If a build plus deploy takes 4 minutes and an agent PR gets 3 pushes before it is merged, each PR costs about 12 minutes, so roughly 80 agent PRs a month. Two levers stretch that: Create on demand, so only PRs someone actually wants to test get an environment, and a smaller blueprint that skips services the reviewer doesn't need. Builds also reuse cached Docker layers, which shortens rebuilds when only application code changed.

How to upgrade, and what isn't a click

Going from Free to Starter, Growth or Scale is a plan change in the console. Your cluster, environments and preview settings stay where they are, and you get more users, more minutes and a support channel.

Moving from your own cluster to a Qovery-managed one is a different operation. Qovery creates the managed cluster in your cloud account (EKS, for example, with its own VPC, Karpenter and load balancer controller), and then you move environments onto it, for example by cloning each one with a target cluster and switching DNS. Plan it like any cluster migration: data, domains and cutover order. Support on the paid plans can help you plan it, but it isn't a toggle.

For agent deploys beyond previews, see AI CI/CD with Qovery and why the deploy and verify steps are where agent workflows break.