Skip to main content

Create and manage ApplicationSets

Harness provides two ways to work with GitOps ApplicationSets:

  1. First-Class Support (Recommended) - Enhanced UI wizard with Service/Environment integration, full CRUD operations, improved RBAC, and Terraform support
  2. Standard Flow - Create ApplicationSets as GitOps Applications with manual YAML configuration
Feature Flag Required

The first-class ApplicationSet support is enabled by the feature flag GITOPS_APPLICATIONSET_FIRST_CLASS_SUPPORT.

If you have the feature flag enabled: Use the First-Class Support tab in the Create and Manage ApplicationSets section below.

If you don't have the feature flag: Use the Standard Flow tab. Contact Harness Support to enable first-class support for an enhanced experience.

What you'll learn

With First-Class Support:

  • Create ApplicationSets using the Harness UI wizard
  • Configure generators to dynamically create applications
  • Define templates with Service and Environment labels
  • Validate and preview ApplicationSet manifests
  • Monitor ApplicationSet sync status and generated applications

With Standard Flow:

  • Create ApplicationSets as GitOps Applications
  • Configure ApplicationSet manifests in Git
  • Sync ApplicationSets to generate child applications
  • Monitor generated applications

Prerequisites

Before you begin, ensure you have:

Additional for First-Class Support:

Additional for Standard Flow:

  • At least two target clusters (e.g., dev and prod)
  • GitHub account with access to clone and modify repositories
info

ApplicationSets are project-scoped entities. All applications generated by an ApplicationSet belong to the same Harness project as the ApplicationSet itself.

ApplicationSet overview

An ApplicationSet is a Kubernetes custom resource that enables you to automatically generate and manage multiple Argo CD applications from a single manifest. It consists of two main components:

  • Generator: Defines the source of parameters used to create applications (e.g., Git repositories, clusters, lists)
  • Template: Defines the application structure with parameterized fields that get substituted with values from the generator

For more information about ApplicationSet concepts, see ApplicationSet basics.


Create and Manage ApplicationSets

Select Your Flow

Choose the appropriate tab below:

  • First-Class Support: If you have access to the enhanced UI wizard (recommended)
  • Standard Flow: If you're using the standard ApplicationSet creation method
info

This flow requires the feature flag GITOPS_APPLICATIONSET_FIRST_CLASS_SUPPORT to be enabled. If you don't have access to the ApplicationSet wizard, use the Standard Flow tab or contact Harness Support to enable this feature.

  1. In your Harness project, go to Deployments > GitOps.
  2. Select Applications from the left navigation.
  3. Switch to the Application Set tab.

You'll see a list of all ApplicationSets in your project.

Create an ApplicationSet

Step 1: Start the ApplicationSet wizard

  1. On the Application Set tab, select + New Application Set.
  2. The ApplicationSet creation wizard opens with four tabs: Overview, Sync Policy, Configuration, and Preview.

Step 2: Configure Overview settings

On the Overview tab, provide the following details:

  • App Set Name: Enter a unique name for your ApplicationSet.
  • GitOps Operator: Select Argo (currently the only supported operator).
  • GitOps Agent: Select the GitOps Agent that will manage this ApplicationSet.
  • Service: Select the Harness Service associated with this ApplicationSet. This enables PR pipeline integration, service dashboard visibility, and RBAC policies.
  • Environment: Select the Harness Environment associated with this ApplicationSet. This enables environment-based filtering and PR pipeline configuration.
tip

The Service and Environment selections automatically add harness.io/serviceRef and harness.io/envRef labels to the ApplicationSet template, enabling integration with Harness pipelines and RBAC policies.

Select Continue to proceed to the next step.

Step 3: Configure Sync Policy

On the Sync Policy tab, define the sync policy that governs the relationship between the ApplicationSet and its child applications.

Sync Options

  • Preserve Resource On Deletion: Check this option if you want to preserve Kubernetes resources when the application is deleted from Argo CD.

Applications Sync

Select the sync policy for applications created by this ApplicationSet.

Currently Supported Option

Currently, only the Sync policy is supported. While other options may appear in the UI, they are not yet functional.

Sync (Recommended): Fully automated sync with create, update, and delete operations. This is the current default and only supported option.

Future Options (Coming Soon):

  • Create-Only: Only create applications; don't update or delete them automatically.
  • Create-Update: Create new applications and update existing ones.
  • Create-Delete: Create new applications and delete removed ones.

Select Continue to proceed to configuration.

Step 4: Configure Generator and Template

The Configuration tab is where you define the generator and template for your ApplicationSet.

Select Generator Type

Choose the generator type from the dropdown. Harness supports all Argo CD generator types:

  • Git: Generate applications from files or directories in a Git repository
  • List: Generate applications from a static list of parameters
  • Cluster: Generate applications for each cluster registered in Argo CD
  • Matrix: Combine multiple generators
  • Pull Request: Generate applications from pull requests
  • SCM Provider: Generate applications from repositories in an SCM provider
  • Cluster Decision Resource: Generate applications based on custom Kubernetes resources
  • Plugin: Use custom generator plugins

For more information on supported generator types, see Argo CD Generator Types.

When you select a generator type, Harness automatically generates a template skeleton for that generator.

Configure Generator

The generator configuration appears in a YAML editor. Modify the template according to your needs.

Example: List Generator

generators:
- list:
elements:
- ns: engineering-dev
url: https://kubernetes.default.svc
- ns: engineering-prod
url: https://kubernetes.default.svc
- ns: engineering-check1
url: https://kubernetes.default.svc

Configure Template

Below the generator configuration, you'll see the template section with automatically added labels for Harness integration:

template:
metadata:
name: "{{.ns}}-guestbook"
labels:
harness.io/serviceRef: guestbook
harness.io/envRef: dev
annotations:
argocd.argoproj.io/sync-options: CreateNamespace=true
spec:
project: default
source:
repoURL: https://github.com/argoproj/argo-cd.git
path: applicationset/examples/list-generator/guestbook/{{.ns}}
targetRevision: HEAD
destination:
server: https://kubernetes.default.svc
namespace: "{{.ns}}"
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true

The template includes:

  • harness.io/serviceRef: References the Service you selected in the Overview step. This label is added to the ApplicationSet template metadata and will be inherited by all child applications generated from this ApplicationSet.
  • harness.io/envRef: References the Environment you selected in the Overview step. This label is added to the ApplicationSet template metadata and will be inherited by all child applications generated from this ApplicationSet.
  • project: The Argo CD project where the ApplicationSet is created. This is usually auto-populated based on the project where the ApplicationSet is created. You can also get this value from the agent details under Mapped Harness ProjectArgo Projects.

The sample generator and template refer to the sample Argo CD guestbook ApplicationSet provided in the Argo CD GitHub repository.

How these labels are used:

The harness.io/serviceRef and harness.io/envRef labels are applied to all child applications generated by the ApplicationSet. These labels enable:

  • Service Dashboard Tracking: Applications appear in the Harness Service dashboard for the referenced service
  • PR Pipeline Configuration: The Fetch Linked Apps step in PR pipelines uses these labels to identify applications associated with a service
  • Environment-based Filtering: Filter and organize applications by service and environment in the Harness UI

You can use variables in the format {{.variableName}} throughout the template. These variables will be substituted with values from the generator.

Step 5: Preview and Validate

On the Preview tab, you can review the complete ApplicationSet manifest before creating it.

Validate the Manifest

  1. Review the generated YAML manifest.

  2. Click Validate to check the manifest for:

    • Syntax errors
    • Template variable substitution issues
    • Service and Environment references
    • Repository and cluster access permissions
  3. If validation succeeds, you'll see a success message.

  4. If validation fails, review the error messages and go back to fix the configuration.

Create the ApplicationSet

Once validation passes, select Finish to create the ApplicationSet.

View ApplicationSet Details

After creating the ApplicationSet, you can view its details and monitor the applications it generates.

ApplicationSet Dashboard

  1. The ApplicationSet dashboard displays all ApplicationSets in the project, along with basic information such as:
    • Applications within each ApplicationSet
    • Labels
    • The agent used to create the ApplicationSet
  1. Click on the ApplicationSet you created to view its details.

On the App Set Details page, you can see:

  • ApplicationSet name
  • GitOps agent used
  • Labels and annotations
  • Generator details
  • Template generated based on the generator
  • Sync options and policies
  1. Click on the Resource View tab to view the generated applications.

The Resource View shows:

  • The ApplicationSet as the parent resource
  • All applications generated by the ApplicationSet
  • The sync status and health of each application

You can:

  • Click on any generated application to view its details
  • Monitor the sync status and health of all applications
  • See which applications are healthy, progressing, or degraded
Resource Tree Refresh

When viewing the ApplicationSet resource tree, child application objects may appear out of sync even if the individual application page shows a synced status. This is because the ApplicationSet resource tree refreshes every 3 minutes by default. For the most up-to-date status of a specific application, click on the application to view its dedicated details page.

  1. Click on the Manifest tab to see the complete manifest generated for the ApplicationSet.

If you want more details about the applications created by the ApplicationSet, navigate to the Applications page. Filter by the agent and cluster to view the applications created by the ApplicationSet. Typically, all applications created by an ApplicationSet will use the same agent and cluster.

Filter ApplicationSets

You can filter ApplicationSets in the list view using:

  • Search: Enter text to search by ApplicationSet name
  • Agent: Filter by GitOps Agent
  • Sync Status: Filter by sync status (Synced, OutOfSync, Unknown)
  • Health Status: Filter by health status (Healthy, Progressing, Degraded, Suspended, Missing)

Edit ApplicationSets

To edit an existing ApplicationSet:

  1. Go to the Application Set tab.
  2. Select your ApplicationSet.
  3. Select the Manifest tab.
  4. Select Edit to modify the manifest.
  5. Make your changes and select Save.
warning

Editing an ApplicationSet may cause applications to be created, updated, or deleted based on the changes you make to the generator or template.

Delete ApplicationSets

To delete an ApplicationSet:

  1. Go to the Application Set tab.

  2. Find your ApplicationSet in the list.

  3. Select the three vertical dots (⋮) next to the ApplicationSet.

  4. Select Delete.

  5. In the Delete Application Set dialog, configure the deletion options:

    Propagation Policy: Select how the deletion should be handled:

    • Foreground (recommended): Deletes the ApplicationSet first, then waits for all child applications and their resources to be deleted. This ensures a clean, ordered deletion process.
    • Background: Deletes the ApplicationSet immediately and removes child applications asynchronously in the background. The ApplicationSet is removed from the UI before all resources are fully cleaned up.
    • Non-cascading: Deletes only the ApplicationSet itself without deleting child applications. The applications become orphaned and continue running independently.

    Remove any existing finalizer: Check this option to remove Kubernetes finalizers and force immediate deletion. Only use this if the ApplicationSet is stuck in a deleting state.

  6. Click Confirm to proceed with the deletion.

danger

Deleting an ApplicationSet with Foreground or Background propagation will also delete all applications generated by it and their deployed resources, unless you've configured the sync policy to preserve resources or you select Non-cascading.


Next Steps