Preview Environments for AI Coding Agents: The Full-Stack Guide

Key points:

• A preview environment is a running copy of your stack for one pull request, created when the PR opens and destroyed when it closes. For agent-written PRs it replaces the step a human author used to do on their laptop: running the code before asking for review.
• A full-stack preview needs seven things: every service the change touches, its own databases, seed data that isn't production data, secrets scoped away from production, a URL with TLS posted on the PR, automatic cleanup, and a cost cap.
• Vercel and Netlify previews cover the frontend. Your API, workers and databases still need somewhere to run per PR.
• Argo CD's ApplicationSet Pull Request generator creates and removes an Argo CD Application per PR. Namespaces, databases, DNS, secrets and seeding are templates you write and maintain.
• Homegrown GitHub Actions + Terraform works and gets expensive in hours: per-PR state, orphaned resources when a cleanup job fails, and token rules that affect bot-opened PRs.
• Qovery clones a blueprint environment per PR on your own Kubernetes cluster, posts the links on the PR, redeploys on push and deletes on merge or close. It is included in Qovery Free.

The cost of writing a pull request dropped. The cost of reviewing one didn't. When Claude Code, Cursor or Codex opens a PR, the diff is often clean, the tests the agent wrote pass, and nobody has seen the feature run. The human author's habit of starting the app and clicking through the change before asking for review is the step agents skip, and reviewers can't do it from a diff.

This guide covers what a preview environment for agent PRs has to include, the four common ways to build one, and how to set it up on a cluster you already run.

Why agent PRs need running environments

Three things change when agents write a large share of your PRs.

Volume. One engineer supervising three agents produces more PRs than one engineer writing code. If each review requires checking out the branch, installing dependencies and starting four services locally, review becomes the bottleneck.

Confidence is lower per line. Agent code tends to be plausible. It compiles, it matches the style, and it occasionally calls an endpoint that doesn't exist or handles the empty state wrong. Those bugs show up when the code runs against real dependencies, not in the diff.

Product people review too. A PM who asked an agent for a settings page wants to click the settings page. A URL on the PR is the only interface that works for them.

The Coding Agents Broken Loop post makes the longer argument: agents stop at "code", and the deploy, test and verify steps are where the loop breaks.

What a full-stack preview environment needs

Services and databases

A preview of the frontend alone tests the frontend. If the PR touches the API, the preview needs the API, its workers, and its own Postgres and Redis. Sharing one staging database between previews breaks as soon as two PRs carry migrations. Each preview gets its own database instance, which is cheap on Kubernetes as a container database and only needs to live as long as the PR.

Seed data without production data

Cloning production data into an environment built from unreviewed agent code is a data leak waiting for an audit finding. Seed every preview from a fixture file instead: a SQL script or a seeding command that runs once when the environment starts, with synthetic users and enough records to exercise pagination. If your schema evolves through migrations, run migrations first and seed reference data second. Schema migrations in ephemeral environments covers the ordering.

Secrets scoping

The preview runs code that no human has approved yet. Give it the credentials of a sandbox: a test Stripe key, a staging OAuth client, an S3 bucket that holds nothing you'd miss. Keep these on the template the previews are cloned from, so a PR never inherits production values by accident. The same principle applies to the agent itself: it should hold a scoped API token, not cloud credentials. Run AI coding agents without production credentials goes deeper.

Cleanup and cost caps

Agents open PRs, get feedback, and sometimes abandon them. Cleanup has to key on the PR being merged or closed, not on someone remembering. Cost caps come in three layers: create previews only on request for low-value PRs, stop previews outside working hours, and bound the total amount of build time you're willing to spend.

The options, compared

Vercel and Netlify preview deployments

Vercel creates a preview deployment by default when you push a commit to a non-production branch or "create a pull request (PR) on GitHub, GitLab, Bitbucket, or Origin", and "each deployment gets an automatically generated URL" (Vercel docs). Netlify deploys each pull request to a unique URL such as deploy-preview-42--mysitename.netlify.app (Netlify docs).

For a frontend, this is the best developer experience available, and it works with agent PRs out of the box. The limit is what runs there. Vercel runs your code as Functions, including Docker images, which it serves "from a Function that autoscales with traffic and scales to zero when idle" (Vercel guide). Databases come from Marketplace integrations. Your existing Kubernetes API, queue workers and Postgres don't get a per-PR copy, so a full-stack change is tested against shared staging.

Argo CD ApplicationSet with the Pull Request generator

If you already run Argo CD, the Pull Request generator discovers open PRs on GitHub, GitLab, Gitea, Bitbucket or Azure DevOps and renders one Argo CD Application per PR. Adapted from the official example:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapps
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
  - pullRequest:
      github:
        owner: myorg
        repo: myrepository
        tokenRef:
          secretName: github-token
          key: token
        labels:
        - preview
      requeueAfterSeconds: 1800
  template:
    metadata:
      name: 'myapp-{{.branch}}-{{.number}}'
    spec:
      source:
        repoURL: 'https://github.com/myorg/myrepo.git'
        targetRevision: '{{.head_sha}}'
        path: kubernetes/
      project: "my-project"
      destination:
        server: https://kubernetes.default.svc
        namespace: default

The docs state that the controller polls every requeueAfterSeconds, "defaulting to every 30 minutes", and that the "Application will be removed when a Pull Request no longer meets the specified criteria".

What the generator gives you is a parameter set (number, branch, head_sha and others) per open PR. Everything else is your template: a namespace per PR instead of default, a database per PR, a hostname per PR and its DNS record, a TLS certificate, secrets that aren't production's, a seed job, and the image build for each head_sha, which Argo CD doesn't do. It's a solid choice for a platform team that already maintains Argo CD and Helm charts for every service. Budget a few weeks to build it and an owner to keep it working.

Homegrown GitHub Actions + Terraform

The DIY version: a workflow on pull_request that builds images, runs terraform apply with a workspace per PR (namespace, database, DNS record), deploys with Helm, and comments the URL. A second job on closed runs terraform destroy.

It works, and the failure modes are known:

• closed isn't a default trigger. GitHub runs pull_request workflows on opened, synchronize and reopened unless you list other types (GitHub docs).
• If the destroy job fails once, you have an orphaned database and load balancer that nothing will clean up.
• Bot-opened PRs behave differently. When a workflow using GITHUB_TOKEN opens or updates a PR, the resulting pull_request runs are created in an approval-required state (GitHub docs). Agents that open PRs through Actions need an app token, or someone has to approve the run.
• Terraform state per PR, concurrency when an agent pushes twice in a minute, and image cleanup are all yours.

Qovery preview environments

Qovery runs on your Kubernetes cluster and treats one environment as the blueprint. When a PR targets the blueprint's base branch, Qovery clones the blueprint (applications, databases, environment variables and secrets) into a new environment, deploys the PR branch, and posts the environment links as a PR comment. New commits redeploy it. Merging or closing the PR deletes it (Qovery docs).

The pieces from the requirements table map like this:

• Services: per-service toggles choose which services get a preview.
• Databases: each preview gets its own database instance. Data is not copied, which is the safe default.
• Seed data: a lifecycle job on the environment START event runs your seed script (seeding guide).
• Secrets: previews inherit the blueprint's variables and secrets, so the blueprint holds sandbox values only.
• URL: each public service gets a generated domain with TLS, and the links land on the PR.
• Cleanup: on merge or close, plus manual deletion.
• Cost caps: Create on demand so previews start only after a /qovery preview comment, deployment rules that stop all [PR]* environments at night, and on the Free plan a hard monthly limit of 1,000 deployment minutes.

The trade-offs: you need a Kubernetes cluster, the Free plan covers one cluster and 1,000 deployment minutes a month, and the template is a Qovery environment rather than your own Helm charts. If you already have a mature Argo CD setup, extending it may be the better call.

How agent PRs reach the preview

A preview environment is keyed on a pull request, so it matters how each agent gets one opened:

• Claude Code in GitHub Actions pushes a claude/... branch and links to a prefilled PR page by default, and a human opens the PR. On an existing PR, it pushes to the PR branch (claude-code-action FAQ).
• Cursor cloud agents work on a branch, and the API exposes autoCreatePR to have Cursor open the PR when the run completes (Cursor docs).
• Codex cloud lets you review the task, then "Create a PR directly from the cloud" (OpenAI docs).

An agent that only pushes a branch, with no PR, gets no preview. That is usually what you want: the PR is the moment someone intends to review.

Set it up on Qovery Free

You need a Kubernetes cluster you already run: EKS, GKE, AKS, k3s or on-premise.

1. Connect it with qovery cluster install, which generates a Helm values file and prints the commands to install Qovery into a qovery namespace. The EKS walkthrough covers it step by step.
2. Deploy your stack once, clone it into a blueprint environment, and set its applications to your base branch.
3. In the blueprint's Settings > Preview environments, switch on Turn on Preview Environments and select services.
4. Add a seed lifecycle job, replace any production secrets with sandbox values, and add a [PR]* deployment rule.
5. Point your agent at the repo. The Claude Code + GitHub Actions tutorial is a complete example.

Free includes 3 users, unlimited AI agents and 1,000 deployment minutes a month, with no credit card and no time limit. See pricing for the paid plans, and AI CI/CD for taking agent PRs past preview to production. For why the backend is the part most preview setups skip, read ephemeral environments for full-stack apps.