Argo CD or Qovery Free for Agent PR Environments

Key Points:

• Argo CD can already create one environment per pull request. The ApplicationSet pull request generator turns every matching PR on GitHub, GitLab, Gitea, Bitbucket or Azure DevOps into an Argo CD Application, and deletes it when the PR no longer matches.
• The generator deploys manifests. Everything around them is yours to build: image builds per commit, a database per PR, DNS and TLS, secrets, seeding, PR comments with the URL, schedules, and how agents get access.
• Argo CD is the better choice when your stack is already packaged as Helm charts or Kustomize, Git must stay the only source of truth, and a platform engineer owns the glue.
• Qovery Free fits when you want per-PR environments for agent-written code on your existing cluster this week, without building that glue: it clones a blueprint environment per PR, builds the images, gives each preview a URL, posts it on the PR and deletes the environment on merge or close.
• They can coexist. Qovery's Argo CD integration shows Argo CD applications as Qovery environments, read-only. You can keep production on Argo CD and run agent previews with Qovery.

Teams running Kubernetes who start using coding agents usually ask for the same thing within a few weeks: a live environment for each PR the agent opens, so a human can click through the change before merging it. If Argo CD is already in the cluster, the first idea is to use it. That is a reasonable idea, and for some teams it is the right one.

This post compares the two paths for a team that already has a cluster and is deciding between building on Argo CD and adopting Qovery Free. Many of the platform teams we talk to run Argo CD, and Qovery integrates with it, so the goal here is to describe both accurately.

What Argo CD gives you per pull request

Argo CD's ApplicationSet controller generates Argo CD Applications from templates. Its pull request generator lists open PRs on GitHub, GitLab, Gitea, Bitbucket Server, Bitbucket Cloud or Azure DevOps, and renders one Application per PR. Each Application can use the PR's number, branch, branch_slug (a DNS-safe branch name), head_sha, head_short_sha, labels and author.

Here is an ApplicationSet that creates a preview for every PR from an agent branch that carries the preview label:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: shop-previews
  namespace: argocd
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - pullRequest:
      github:
        owner: acme
        repo: shop
        tokenRef:
          secretName: github-token
          key: token
        labels:
        - preview
      filters:
      - branchMatch: "^agent/.*"
      requeueAfterSeconds: 300
  template:
    metadata:
      name: 'shop-pr-{{.number}}'
    spec:
      project: previews
      source:
        repoURL: https://github.com/acme/shop.git
        targetRevision: '{{.head_sha}}'
        path: deploy/chart
        helm:
          parameters:
          - name: image.tag
            value: 'pr-{{.number}}-{{.head_short_sha}}'
          - name: ingress.host
            value: 'pr-{{.number}}.preview.acme.dev'
      destination:
        server: https://kubernetes.default.svc
        namespace: 'shop-pr-{{.number}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
        - CreateNamespace=true

A few details from the Argo CD docs that matter in practice:

• Polling. The generator checks for PRs every 30 minutes by default (requeueAfterSeconds: 1800). For a preview that appears seconds after an agent opens a PR, configure a webhook on /api/webhook with pull request events, or lower the interval and watch your Git provider's API rate limit.
• Labels. The labels filter keeps PRs that carry all of the listed labels, which is a simple way to let a reviewer (or the agent) opt a PR in.
• Cleanup. When a PR closes or stops matching, the controller deletes its Application. Applications generated by an ApplicationSet carry the resources-finalizer.argocd.argoproj.io finalizer, so Argo CD deletes their Kubernetes resources too, unless you set preserveResourcesOnDeletion. See Application deletion.

This is solid, well-documented machinery, and it is free and open source.

What you still build around it

The ApplicationSet syncs manifests at a commit. A preview a reviewer can use needs more than that. Here is the list we see teams work through, in the order they usually hit it.

1. An image for every commit. The template above deploys image.tag: pr-<number>-<sha>. Something has to build and push that image before Argo CD syncs, or the pods sit in ImagePullBackOff. That is a CI workflow per service, triggered on PR events, with registry credentials and a tag convention shared with the chart. Agent PRs often get several pushes in a row after review comments, so build speed and caching matter.

2. A database per PR. Agent PRs touch schemas more often than people expect. A preview pointed at a shared staging database turns one agent's migration into everyone's broken environment. You either add a Postgres to the chart (a StatefulSet or an operator such as CloudNativePG), or call a database branching service from CI and inject the connection string. Then you need seed data that is realistic and not copied from production. Check what happens to volumes at cleanup: by default, PersistentVolumeClaims created from a StatefulSet's volumeClaimTemplates are kept when the StatefulSet is deleted, and they keep billing.

3. DNS and TLS. pr-1842.preview.acme.dev needs a wildcard DNS record pointing at your ingress, and certificates. That is usually ingress-nginx or another controller, cert-manager with a DNS-01 solver for a wildcard certificate, and external-dns if you want per-host records.

4. Secrets. Each preview needs API keys, OAuth client IDs and service credentials, preferably not the production ones. With Argo CD that usually means External Secrets Operator or Sealed Secrets, a naming scheme per namespace, and a decision on which third-party sandboxes each preview gets.

5. The URL on the pull request. Reviewers, and the agent itself, need to know where the preview lives and whether it is healthy. Argo CD doesn't comment on PRs by itself. Teams add a CI step that waits for the Application to be Healthy and posts the URL, or configure Argo CD Notifications with a GitHub template.

6. Cost controls. Previews for agent PRs multiply fast. Stopping previews at night, creating them only on request, and capping the node group are all possible, but each one is another script, CronJob or policy. We modelled the numbers in what a preview per agent PR costs: for 30 agent PRs a day, the difference between no controls and all of them is roughly $7,700 against $95 a month in AWS compute.

7. Agent access and guardrails. With Argo CD, the agent's only lever is Git: it pushes a branch and opens a PR, and the ApplicationSet does the rest. That is a strong guardrail, because the agent never holds cluster credentials. It also means the agent can't read its own preview's logs or events when a deployment fails, unless someone gives it kubectl or Argo CD API access scoped to the preview namespaces.

None of this is exotic. It is a few weeks of platform work to build, and a permanent line item to maintain, because every new service, secret and database version has to be wired into it.

How the same flow works on Qovery Free

Qovery is an Agentic DevOps platform that deploys to Kubernetes in your own cloud account. On the Free plan you connect one cluster you already run (EKS, GKE, AKS, k3s or on-premise) with qovery cluster install. If the cluster lacks them, Qovery installs an ingress controller, cert-manager, external-dns and the metrics server, as described in the BYOK documentation.

Per-PR environments then work from a blueprint environment:

1. Describe the stack once. Create an environment with your services (built from a Git repository and a Dockerfile, or from an image), a container database, variables and secrets. Or ask Claude Code, Cursor or Codex to do it with the Qovery Skills.
2. Turn on preview environments in that environment's settings and choose which services each preview includes. Databases can be cloned per preview or shared.
3. Open a PR. Qovery clones the blueprint, including its variables and secrets, builds the images for the PR's branch, deploys them, and posts the preview URL in the PR comments. New pushes redeploy the preview.
4. Merge or close the PR. Qovery deletes the environment.

The preview environment docs cover the two creation modes: automatic for every PR, or on demand, where nothing starts until someone comments /qovery preview on the PR. Deployment rules with the [PR]* pattern stop and start previews on a schedule.

If you prefer to drive previews from CI with your own naming, the CLI does the same steps:

qovery environment clone --organization "Acme" --project "Shop" \
  --environment "blueprint" --new-environment-name "preview-pr-1842" --cluster "eks-previews"
qovery application update --organization "Acme" --project "Shop" \
  --environment "preview-pr-1842" --application "api" --branch "agent/fix-billing-rounding"
qovery environment deploy --organization "Acme" --project "Shop" \
  --environment "preview-pr-1842" --watch

Agent access. Agents reach Qovery through the MCP server, the CLI or the Skills. The MCP server is read-only by default and needs read_write=true for deployments. For an autonomous agent, an API Policy Token (in preview) attaches an Open Policy Agent policy evaluated on every request, so you can let an agent read logs and redeploy previews in one project while denying anything that touches production. On the Free plan, AI agents don't count against the 3 users.

Limits to know. Free includes 1,000 deployment minutes a month with a hard stop, one cluster, 3 users and community support. One deployment minute is one minute of build and deploy time across any service. For a team with many agent PRs a day, the on-demand mode keeps minutes for the PRs that need a running environment. Paid plans add minutes, users, Qovery-managed clusters and support (pricing).

Side by side

Where Argo CD is the better choice

Pick Argo CD (and keep it) when most of these are true:

• Your stack is already Helm or Kustomize, and previews should run exactly the charts production runs. The ApplicationSet adds a template on top of what you have.
• Git must be the only source of truth. Some teams need every change to the cluster to be a reviewed commit, for audit or for habit. Argo CD is built around that, and its audit story is well understood.
• You run many clusters, CRDs and operators, and previews are one of many GitOps use cases. Argo CD's multi-cluster model and its ecosystem are hard to beat there.
• You have a platform engineer who owns the glue (CI builds, secrets, DNS, cleanup) and wants full control over every piece.
• You want no vendor in the loop, whatever the plan.

Flux users have a comparable path: the Flux Operator's ResourceSet API can generate ephemeral environments from GitHub pull requests, with the same list of surrounding pieces to build.

Where Qovery Free fits

Qovery Free is the faster path when:

• Nobody on the team wants to build and own preview glue. Images, databases, URLs, PR comments, cleanup and schedules come with the product.
• Your stack isn't packaged as charts yet. A few services with Dockerfiles and a Postgres become a blueprint without writing Kubernetes YAML.
• Agents should operate their own previews: read logs, redeploy after a fix, report the URL back, under a policy you control, without cluster credentials.
• You want to try the workflow before investing. Free has no time limit, so a small team can run agent previews for real on one cluster and decide later.

If you are comparing more broadly, our Argo CD alternatives guide covers managed GitOps options, and 8 per-PR environment tools on Kubernetes compares preview-specific products.

Running both

You don't have to choose for the whole company. Qovery's Argo CD integration connects an Argo CD instance running on a cluster added to Qovery. Argo CD applications then appear as Qovery environments, organized by namespace, with pod status, shell access, log streaming and sync status. Deployment ownership stays in Argo CD: those applications are read-only in Qovery, and configuration stays in Git. The docs flag the integration's behaviour as subject to change, and we haven't checked its availability plan by plan, so confirm it for your plan before you rely on it.

A common split looks like this:

• Production and staging stay on Argo CD, with your existing charts and review process.
• Agent PR previews run on Qovery, ideally on a separate cluster, which the Qovery docs recommend for previews anyway.
• One place to look: Argo CD applications and Qovery previews side by side in the Qovery Console.

You can read more about the integration in Keep Argo CD, get Qovery, and about the agent review workflow on AI CI/CD with Qovery.