# Preserve Helm-compatible labels

Use Helm-style labels when an existing workload selects Pods with the `app`
and `release` keys. Keeping those selectors avoids an immutable-field change
when Kix takes ownership.

## Check the existing labels

Read the current workload selector and Pod template labels:

<Command
  commands={[
    "kubectl get deployment helm-web -n apps -o jsonpath='{.spec.selector.matchLabels}{\"\\n\"}{.spec.template.metadata.labels}{\"\\n\"}'",
  ]}
/>

Continue if the selector follows the common Helm shape, with both `app` and
`release` set to the release name. For a different selector, use
[`selectorLabels`](/docs/how-to/adopt-existing-resources/preserve-existing-selectors/)
to copy it exactly.

## Select Helm label style

Set `labelStyle` on the instance:

<Snippet {...preserveHelmLabels} />

For this instance, Kix generates `app = "helm-web"` and
`release = "helm-web"` as `scope.selectorLabels`. Packages built with Kix's
workload and Service helpers use the same pair consistently.

## Check before deploying

Evaluate the cluster:

<Command {...check} />

Render the Deployment and Service to verify their labels and selectors:

<Command {...workloadLabels} />

Compare the rendered Deployment selector with the live selector from the first
step. `kix diff` cannot make this comparison because it finds live resources
through Kix's management labels. A Helm-owned workload does not have those
labels, so the diff shows it as a new resource.

Ask the API server to review the complete ownership change instead:

<Command
  commands={["kix deploy how-to-adoption --dry-run"]}
  cwd="kix-examples/"
/>

A selector mismatch fails there rather than reaching the cluster, because the
field is immutable.

:::caution
`labelStyle = "helm"` generates the standard `app` and `release` pair. It
does not discover labels from the cluster. Use `selectorLabels` when the live
selector differs.
:::