> ## Documentation Index
> Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL.
> Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other.
> Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking.
> Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify.

# GitOps fleet.yaml Configuration Examples

> fleet.yaml configuration examples for customizing Helm chart deployments across edge Kubernetes clusters using ZEDEDA Edge Kubernetes Service.

When a GitOps repository is connected to ZEDEDA Edge Kubernetes Service, the service uses the Rancher Fleet format to deploy Helm chart bundles to clusters. You can optionally include a `fleet.yaml` file in your repository root to customize how bundles are deployed: specify namespaces, override Helm values, target specific clusters, or exclude clusters from deployment.

If no `fleet.yaml` is present, the service deploys the chart with default settings to all target clusters defined for that repository.

The service polls the repository every 60 seconds and applies any changes it detects.

A starter repository with example configurations is available at [https://github.com/zededa/k8s-app-flows-starter](https://github.com/zededa/k8s-app-flows-starter).

## Basic Helm Deployment

The following example deploys a Helm chart from a subdirectory of the repository to a specified namespace:

```yaml theme={"dark"}
name: my-app
namespace: my-namespace
helm:
  chart: ./charts/my-app
```

## Override Helm Values

Use the `values` field under `helm` to set or override chart values at deploy time:

```yaml theme={"dark"}
name: my-app
namespace: my-namespace
helm:
  chart: ./charts/my-app
  values:
    replicaCount: 3
    image:
      tag: v1.2.0
```

## Per-Cluster Value Overrides

Use `targetCustomizations` to apply different values to different clusters based on their labels. Each entry in `targetCustomizations` specifies a `clusterSelector` that matches clusters by label, and a `helm` block that overrides values for those clusters only:

```yaml theme={"dark"}
name: my-app
namespace: my-namespace
helm:
  chart: ./charts/my-app
  values:
    replicaCount: 1
targetCustomizations:
  - name: production
    clusterSelector:
      matchLabels:
        env: production
    helm:
      values:
        replicaCount: 5
  - name: staging
    clusterSelector:
      matchLabels:
        env: staging
    helm:
      values:
        replicaCount: 2
```

Clusters that do not match any `targetCustomizations` entry receive the base `values` defined at the top level.

## Skip Deployment to Specific Clusters

Set `doNotDeploy: true` in a `targetCustomizations` entry to prevent deployment to clusters matching that selector:

```yaml theme={"dark"}
name: my-app
namespace: my-namespace
helm:
  chart: ./charts/my-app
targetCustomizations:
  - name: exclude-dev
    clusterSelector:
      matchLabels:
        env: dev
    doNotDeploy: true
```

All clusters not matching the `exclude-dev` selector receive the chart normally.

## Base Values File Plus Per-Cluster Overrides

You can combine a base values file with per-cluster overrides. The fleet agent merges values in the following order, with later entries taking precedence:

1. `values.yaml` in the chart directory.
2. Files listed in `valuesFiles` at the top level.
3. Inline `values` in the top-level `helm` block.
4. Files listed in `valuesFiles` within a `targetCustomizations` entry.
5. Inline `values` within a `targetCustomizations` entry.

```yaml theme={"dark"}
name: my-app
namespace: my-namespace
helm:
  chart: ./charts/my-app
  valuesFiles:
    - values-base.yaml
targetCustomizations:
  - name: east-region
    clusterSelector:
      matchLabels:
        region: east
    helm:
      valuesFiles:
        - values-east.yaml
      values:
        replicaCount: 3
```

## Key Fields Reference

| Field | Description |
| - | - |
| `name` | The bundle name used internally by the Fleet agent. |
| `namespace` | The Kubernetes namespace to deploy resources into. |
| `helm.chart` | Path to the Helm chart directory within the repository, relative to `fleet.yaml`. |
| `helm.values` | Inline key-value overrides applied to the chart at deploy time. |
| `helm.valuesFiles` | List of values file paths within the repository to merge into the chart values. |
| `targetCustomizations` | List of per-cluster override entries. Each entry applies to clusters matching its `clusterSelector`. |
| `clusterSelector.matchLabels` | Key-value label pairs used to select target clusters. Clusters must have all specified labels to match. |
| `doNotDeploy` | When `true`, skips deployment to clusters matched by the enclosing `targetCustomizations` entry. |

## Next Steps

> [card] [Create GitOps Repositories](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/create-gitops-repositories.md)
>
> Connect a Git repository to ZEDEDA Edge Kubernetes Service and configure authentication.

> [card] [Manage Cluster Groupings](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/manage-kubernetes-cluster-groupings.md)
>
> Organize clusters into groups and assign labels for use with fleet.yaml selectors.