Skip to content
Latchkey

Helm "rendered manifests contain a resource that already exists" in CI

Helm refuses to adopt a Kubernetes object that already exists but is not labeled as part of this release. The error names the kind, the resource, and which release annotation it expected to find.

What this error means

helm install or upgrade fails with "Error: rendered manifests contain a resource that already exists. Unable to continue with install: <kind> "<name>" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata".

helm
Error: rendered manifests contain a resource that already exists. Unable to continue
with install: ConfigMap "my-app-config" in namespace "prod" exists and cannot be
imported into the current release: invalid ownership metadata; label validation error:
missing key "app.kubernetes.io/managed-by": must be set to "Helm"

Common causes

The object was created outside this release

A kubectl apply, another chart, or a leftover from a deleted release created the resource, so it lacks the Helm ownership labels and annotations.

A previous install failed and left orphans

A partial install created some objects but the release record was removed, leaving unmanaged resources behind.

How to fix it

Add the Helm ownership metadata to adopt it

  1. Confirm the object should belong to this release.
  2. Label and annotate it so Helm can take ownership on the next apply.
  3. Re-run the upgrade.
Terminal
kubectl label configmap my-app-config -n prod app.kubernetes.io/managed-by=Helm
kubectl annotate configmap my-app-config -n prod \
  meta.helm.sh/release-name=my-app meta.helm.sh/release-namespace=prod

Delete the conflicting object if it is stale

If the resource is an orphan from a failed install, delete it so Helm recreates it cleanly under the release.

Terminal
kubectl delete configmap my-app-config -n prod
helm upgrade --install my-app ./chart -n prod

How to prevent it

  • Manage objects through one tool; do not mix kubectl apply with Helm for the same resource.
  • Use unique, release-scoped names in templates to avoid cross-release collisions.
  • Clean up orphans after a failed first install before retrying.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →