kubectl apply --server-side Field Manager Conflicts in CI

Server-side apply records the field manager that owns each field. When a pipeline switches to --server-side, or uses an inconsistent --field-manager name, the new apply collides with the manager that previously owned those fields and the API server reports a conflict.

What this error means

kubectl apply --server-side fails with Apply failed with N conflict(s) naming a manager such as kubectl-client-side-apply or a differently-named manager from an earlier run. The same run conflicts the same way until ownership is reconciled.

error: Apply failed with 2 conflicts: conflicts with "kubectl-client-side-apply":
- .spec.template.spec.containers[name="app"].image
- .metadata.labels.version

Common causes

Migrating client-side → server-side apply

Fields previously owned by kubectl-client-side-apply (via the last-applied annotation) collide when you first switch to server-side apply, because ownership has not yet been transferred.

Inconsistent --field-manager names

Two runs using different --field-manager values each claim fields; the next apply under one name conflicts with the fields the other name owns.

How to fix it

Use one stable field-manager name and take over once

Pin a single manager name for the pipeline and force-claim ownership the first time when you intend to own those fields.

kubectl apply --server-side \
  --field-manager=ci-deployer --force-conflicts -f deploy.yaml

Keep the manager name consistent across CI

1. Choose one --field-manager value per pipeline and use it everywhere.
2. Avoid mixing client-side and server-side apply for the same object.
3. Inspect ownership with kubectl get <obj> -o yaml --show-managed-fields.

How to prevent it

• Standardize on server-side apply with a single --field-manager name.
• Migrate ownership once with --force-conflicts, then stop forcing.
• Do not alternate between client-side and server-side apply on one resource.

Related guides