Preview Environments for Faster Pull Request Feedback

Every platform team knows the gap between "the pull request looks fine" and "this change actually works in a real environment."

Code review, CI checks, and Helm rendering are important, but they still leave one question open:

What happens when this pull request is deployed?

With preview environments in kubriX Prime, teams can now answer that question earlier. A labelled pull request can get its own temporary Argo CD application, its own namespace, and its own route before the change enters the regular GitOps promotion flow.

The problem with late feedback

Most delivery pipelines are good at validating syntax and unit-level behavior. They are less good at showing how an application behaves once all the platform pieces are involved:

• ingress
• certificates
• DNS
• Helm values
• Kubernetes resources
• platform policies
• environment-specific configuration

Those issues often show up only after a change has already been merged and promoted into a shared test environment.

That is late feedback.

And late feedback tends to be expensive feedback.

How kubriX preview environments work

Preview environments use the Argo CD ApplicationSet pull request generator. When a pull request matches the configured labels, kubriX creates a temporary Argo CD application from the pull request head_sha.

The generated preview environment is isolated from the regular stages:

Resource	Example
Pull request label	preview
Argo CD application	my-app-preview-pr-42
Namespace	team1-my-app-pr-42
Deployed revision	PR head_sha

When the pull request changes, the preview environment follows the new commit. When the label is removed or the pull request is closed, Argo CD prunes the preview application again.

Designed for platform defaults and app-level control

Preview environments are configured in two layers.

Platform teams can define defaults during team onboarding:

previewEnvironmentsDefaults:
  enabled: true
  labels:
    - preview
  requeueAfterSeconds: 1800
  valuesFiles:
    - values.yaml
    - values-preview.yaml

Application teams can override those defaults in their app-stages.yaml:

previewEnvironments:
  labels:
    - qa
  requeueAfterSeconds: 600
  valuesFiles:
    - values.yaml
    - values-qa.yaml

This keeps the platform in control of the standard behavior while still giving application teams enough flexibility for their own workflows.

Preview URLs that follow the pull request

The application chart receives the pull request number as a Helm value:

kubriXPreviewPRNumber: "42"

That makes it easy to create deterministic preview URLs:

ingress:
  hosts:
    - host: team1-my-app-pr-{{ .Values.kubriXPreviewPRNumber }}.apps.example.com

In hub-and-spoke setups, kubriX can also inject the spoke ingress domain so the preview environment is created on the selected target cluster.

Where this fits with Kargo

Preview environments do not replace Kargo.

They sit before the promotion flow.

Kargo remains responsible for controlled promotion between stages such as test, QA, and production. Preview environments are for pull request validation before the change becomes part of the normal staged delivery path.

That gives teams a cleaner workflow:

1. Open a pull request.
2. Add the configured preview label.
3. Review the deployed change in an isolated environment.
4. Merge when ready.
5. Promote through Kargo as usual.

Why this matters

Preview environments reduce the cost of finding deployment issues. They also make reviews more concrete: instead of reviewing only YAML and screenshots, teams can inspect the running application.

For platform teams, the feature keeps preview environments standardized. For application teams, it makes pull request validation feel much closer to production delivery without turning every PR into a manual platform request.

That is the kind of feedback loop an internal developer platform should make easy.

Learn more

The feature is documented in the kubriX docs:

Preview Environments