In this blog I have added the solution for ArgoCD Metadata.annotations: Too long
Error.
Issue - Annotation Exceeding Limit
When I tried to deploy the Prometheus-stack helm chart using ArgoCD, I faced the following error.
metadata.annotations: Too long: must have at most 262144 bytes
This issue occurs because the size of the value of the annotation exceeds the Kubernetes 256 KiB (262 144 bytes) limit. (Refer the code here)
That is a very good limit for storing many annotation. But here is why it exceeds in ArgoCD.
When ArgoCD applies the YAML, it stores a copy inside the object itself under kubectl.kubernetes.io/last-applied-configuration
annotation. That hidden copy counts toward the 256 KB limit on metadata.annotations
So, if the object itself is large (big CRDs, Prometheus, Grafana‑dashboard ConfigMaps, etc.), the annotation pushes the total size over 256 KiB and the API server rejects the object.
You won't face this issue when you try to deploy the helm chart directly using helm install
or kubectl apply
Solution - Using ServerSideApply (SSA)
To solve this issue, you can use the ServerSideApply
option available on ArgoCD.
This option tells Argo CD to let the Kubernetes API server take care of the apply instead of storing the configuration in annotations. Meaning, SSA offloads the "apply" logic and state tracking (moving it from annotations to managedFields
) to the Kubernetes API server itself
If you are using the declarative method
for deploying the application, you can specify the ServerSideApply
option under the syncPolicy
as given in the example below.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: prometheus
namespace: argocd
spec:
destination:
name: in-cluster
namespace: monitoring
project: default
source:
repoURL: '<your-repo>'
targetRevision: HEAD
path: kube-prometheus-stack
helm:
valueFiles:
- values.yaml
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
If you are deploying using ArgoCD UI
, enable the Server-Side Apply
option under the SYNC OPTIONS
during the configuration.

Traditionally,
kubectl apply
uses client-side logic. This means your local kubectl
fetches the current state of a resource from the cluster, compares it to the desired state defined in your YAML file, calculates the differences locally, and then sends an update to the API server.With SSA, that entire process shifts to the server. You send the complete desired YAML to the API server, and it takes care of comparing the current and desired states. It also keeps track of which client owns which fields in a resource - a concept known as field ownership. In our case, ArgoCD is the owner managing these fields.