> ## Content Index
> Fetch the complete content index at: https://devopscube.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# ArgoCD Metadata.annotations: Too long Error [Solved]
- URL: https://devopscube.com/argocd-metadata-annotations-too-long/
- Published: 2025-05-02T15:38:34.000Z
- Updated: 2025-05-29T08:13:36.000Z
- Author: Aswin Vijayan
- Tags: #blog, ARGOCD, #syntax-highlight

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](https://devopscube.com/setup-prometheus-helm-chart/) using [ArgoCD](https://devopscube.com/argo-cd-ultimate-guide/), I faced the following error.

```bash
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**](https://devopscube.com/kubernetes-tutorials-beginners/) **256 KiB (262 144 bytes) limit.** (Refer the [code here](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/api/validation/objectmeta.go?ref=devopscube.com#L44-L67))

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](https://devopscube.com/kubernetes-architecture-explained/#1-kube-apiserver) 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.

```yaml
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.

![](https://storage.ghost.io/c/5f/2f/5f2f4d20-2abf-4534-8d40-7aa233aedd43/content/images/2025/05/image.png)

💡

[Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/?ref=devopscube.com) (SSA) is a native feature of Kubernetes.  
  
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.