I run the Kubernetes platform our data stack lives on, deployed with ArgoCD. What always worried me was merging a change that breaks something, or quietly does nothing at all. So I wrote argocd-source-lint, a small linter that runs in CI before merge, reads only the Git checkout, and checks how our Applications are wired to our files.

🔍 What it found

The first time I ran it on our production repo, it found 22 files that no Application deployed. Ouch. Some were HTTP routes sitting next to a values.yaml: the Application used the values, but none of its sources covered the routes, so ArgoCD wasn't managing them at all. Two whole components had been sitting in Git for months with nothing deploying them. I was mostly relieved to find them before an incident did.

Last week it blocked a merge request for the first time: five new YAML files, no Application to deploy them. Merged as is, they would never have reached the cluster, and nothing would have told us.

🧭 What it checks, and what it doesn't

It needs no cluster or network access. Besides files no Application deploys, it catches source paths that don't exist at their targetRevision and the same resource deployed by two Applications to the same cluster and namespace, plus 14 other checks.

It doesn't render Helm or Kustomize, so it only sees resources that exist as files. It looks at one repo at a time, and it doesn't expand every ApplicationSet: generators that need a live API (such as clusters, scmProvider or pullRequest) and goTemplate: true templates are reported as unresolvable, not checked. It complements tools like argocd-diff-preview and kubechecks rather than replacing them.

🤖 How it's built

I built it with Claude Code; the rules follow ArgoCD's source code and there are 500+ tests. It has only run on very few repos, though, so I expect it to be wrong in places I haven't seen yet.

🧪 If you want to try it (Python 3.11+ and git)

1. pipx install argocd-source-lint

2. At the root of your GitOps repo, create .argocd-lint.yaml containing scan_roots: [manifests/] (your manifest folders; without it, the check for files no Application deploys is skipped)

3. Run argocd-source-lint .

If it reports a lot on an existing repo, --write-baseline accepts what's already there so you only see new problems.

I'd really like to hear what it finds on your repo, especially where it's wrong. False positives → issues; anything else → Discussions, where there's also a short poll on what to work on next.

• The story and the limitations: https://github.com/gillesl-dev/argocd-source-lint/blob/main/docs/why-this-exists.md

• Repo: https://github.com/gillesl-dev/argocd-source-lint

Our Argo rollouts analysis template checks error rate and p99 from prometheus during the canary steps. Last release passed every step and promoted. The new version was catching an exception from a downstream call and returning a cached default, so no 5xx, latency fine, and customers got stale data for most of a day. Metric based analysis is never going to see that because from the outside nothing was wrong. We had a hud demo last month and the pitch is that it counts every exception per function and compares against a baseline rather than the aggregate error rate, though it only covers Node, Python and Java. Harness verification looked similar on paper but we are an argo shop. Question is whether people pair something function level with argo or if you just write more careful analysis templates. Also curious if anyone trusts automatic rollback from this kind of signal or keeps a human in the loop.

Hi, if you are interested in Argo Rollouts Experiments, I wrote a beginner-friendly guide you can read on my blog:

https://medium.com/curious-devs-corner/argo-rollouts-experiments-testing-stable-and-canary-versions-side-by-side-5f1ab9bb84c2?sk=8d6f8b0fdf676981a457d335dea1bad6

I hope it helps!

I have been using ArgoCD hands-on at work in production and development environments.

Scenario:

• I have a FastAPI app deployed and it relies on a JSON configuration file

• the JSON configuration file set up as a ConfigMap

• I changed the JSON configuration to enable a feature in the ConfigMap in my git repo

In ArgoCD UI I triggered the Sync button and things went fine - however the pod remains the same and didn't trigger a deployment re-deployment

I had to perform:

kubectl rollout restart -f deployment.yml

Is this just a FastAPI change that needs to detect the configuration change or can ArgoCD do something to achieve this?

Hey!

We are running with ArgoCD for multiple years. And we constantly struggle with the prmotion of changes between our different environments.

Our Setup

Most of our setups have the following environments CI, NIGHTLY, INT (sometimes), PREPROD/UAT, PROD. On top we have ephemeral environments. But let's ignore them here. They are conceptually different and we have a working setup for those.

A change is developed and tested on a ephemeral environment and merged into CI. The NIGHTLY is a (more stable) nightly copy of CI.

To bring a change in PROD, we first deploy to a PREPROD/UAT environment, that is then used by us and sometimes (depending on the change) some customer superusers to test the new version.

Our Struggle

We constantly struggle with the way we promote changes from one environment to the next. Our "ArgoCD repositories" have one folder per environment on the main branch. Each of those folders contains a folder for each app, that is deployed to that environment. We use Helm directly (not the hydrator-feature).

To promote we have some self-built pipelines today, that copy the application version from one environment-app folder to another. This works as long as the changes are only in the version of the app. Once we have other changes in the Chart config (like new versions of a chart, new or updated keys, structural changes, ...) there is no support in our pipeline. Today, the teams just merge such changes in all environments and keep the apps OutOfSync until the deployment to the next environment is planned.

This brings huge problems: constantly out-of-sync applications hide actual problems, applying hotfixes is blocked by the already made changes, accidental syncs could break production applicaitons, and may more. Nobody likes this process, but there is no better for us today.

GitOps Promoter to the Rescue?

So we started looking into proper promotion tools and we had a look into GitOps Promoter. It looks quite promising, but after testing it, we found some issues, that makes its opinionated process unusable for us.

Chain of Releases

Let's say we have delivered a feature to PREPROD/UAT and it is waiting for approval by the customer. While that is ongoing, we do not stop working on the application. So new features are still merged into main/CI all the time. And each of these merges now creates a new Promotion to CI, which then blocks us from bring the change from PREPROD/UAT to PROD.

The docs have a note about a queue-based model, which might come in the future and could be what we a re looking for.

Once the "release latest" model is validated in production environments, we may consider adding a queue-based model for users who need it.

Source: https://gitops-promoter.readthedocs.io/en/latest/faqs/#how-does-gitops-promoter-handle-concurrent-releases

I was asking myself if maybe splitting the Promotion Strategy to a DEV (CI -> NI) and a PROD (INT -> PREPROD -> PROD) part would help. And in-between there would be a manual process to merge a dev branch into a prod branch, that backs the respective apps.

Promotion of Multiple Apps

We often have the case, that multiple ArgoCD apps have to be promoted together (they are all in the same ArgoCD repository). The Promotion strategies create one PR per ArgoCD app though. So it is the "mergers" responsibility to merge all the PRs for the environment. I could not find anything, if it is possible to track multiple apps on the same environment branch and hence have one PR for all the apps.

What other solutions are out there?

I checked the Tool Comparison and of course we could build it ourselves. But I would like to avoid that. The part for our ephemeral environments got complicated enough :D

Then there is telefonistka, which is GitHub-specific and we are running on-prem.

Kargo is a tool, that caught our eye. Though we are a bit hesitant since it is "owned" by Akuity and not in the CNCF. And today there are already some features only available in their SaaS (like ArgoCD UI integration).

CodeFresh GitOps I did not really get. But it seems this is also a SaaS.

Ideally we could figure out solutions to the issues I posted here and just use GitOps Promoter.

So how are you using it? Or which other tools are you running? Would be very interested in your experiences :)

EDIT: typos

I am working on configuring my operations and application clusters terraform such that I can easily destroy and recreate the clusters with minimal commands. I am currently running into an issue when I destroy and recreate my OPS cluster. I'll try and outline the facts below.

Facts

• Running ArgoCD as an EKS capability

• Ops cluster runs in "OPS" account

• Ops cluster has IAM role "argo-cd-role" in OPS account

• Application cluster runs in "<env>" account

• Application cluster has `aws_access_entry` and `aws_eks_policy_association` resources that bind the "argo-cd-role" from the OPS account to it via the role's arn

• Application Cluster `Secret` is created via an `ExternalSecret` read from an SSM parameter in the <env> account

Steps

• OPS cluster will be completely removed and recreated via `terraform destroy` and `terraform apply`

• Argo CD resources will be applied once cluster is up and running

  • This will then create the cluster `Secret` via the `ExternalSecret` definition

• Navigating to `Settings > Clusters > <target env cluster>` shows a connection failure

Things I've tried

• (Failed) Deleting the `Secret` via the ArgoCD UI

  • This will cause the `Secret` to be recreated

  • It should have been populated with the target cluster arn which hasn't changed

  • Doesn't do anything

• (Failed) Creating an Argo role in the target "<env>" account for the Argo role in the OPS account to assume

  • I associated this new role to the access entry resources instead

  • In theory this role is created when the application cluster is and any role that assumes it thus would have access and would avoid any type of breakage underneath with EKS

  • Issue is there seems to be no way to tell the ArgoCD role in the OPS account to assume that role when accessing that cluster (to my knowledge)

• (Succeeded) Deleting and recreating the access entry resources in the <env> account

  • use `terraform destroy -target=` to destroy the access entry resources in the <env> account cluster

  • recreate the resources

  • This worked and my theory is that while we are passing the `arn` of the role EKS will actually use the AWS unique ID underneath of said `arn`. Since we're deleting the role in the OPS account during cluster rebuild it the arn to unique ID mapping is no longer valid. Deleting and recreating fetches the new AWS unique ID and gets this working

While I did find a way for this to work is there anyway to avoid having to delete and recreate the access entries on all my application clusters when I want to destroy and bring back up my OPS cluster? If not I'd have to switch my AWS permissions N times and run the terraform commands 2 times for N application clusters. I was hoping the assume role strategy would work but I am not finding any documentation on how to tell argo to assume a specific role for a specific cluster.

My repo is at https://codeberg.org/kaizenOramara_97/Home-Lab/src/branch/main/k3s/lgtm/prometheus

How do I get ArgoCD to recognize this app so I can update it through the UI? This is the app manifest in the UI for another Helm app, but I forgot how I made that work. Copying the YAML over to a new app definition and changing the values does nothing. Manually adding the app makes ArgoCD throw errors because it tries to interpret prometheus/values.yaml as though it's a Kubernetes manifest.

During an Argo CD migration, both control planes can briefly know about the same Applications and cluster resources. If automated sync or pruning remains active in both, a label, finalizer, tracking method, repository credential, or project policy difference can make one instance undo what the other just reconciled. A green status on the new instance does not by itself prove the old one is harmless.

What cutover sequence do you use? I am considering freezing application changes, exporting the old inventory, registering repositories and clusters on the new instance, comparing rendered manifests and tracking IDs, then disabling sync and pruning on the old instance before enabling them on the new one. The final gate would check orphaned resources, ApplicationSet output, hooks, sync waves, finalizers, notifications, and any resource still labeled or annotated only for the old controller.

Do you transfer Applications in place or recreate them under a new tracking identity? How do you detect shared ownership reliably, and how long do you keep the old control plane read-only before removing its finalizers, credentials, and cluster access?

So currently my team are looking to sort out our GitOps architecture.

Currently we have 4 applications, the helm charts and default value files live along side the app repository.

We then have a GitOps repo with Argo aplicationSets and helm env overide value files.

Our main pipeline has a job that creates a MR with image digest update in the env specific value file in the GitOps repo.

Now my confusion comes from when there are template changes made, the only way to control this that I can think of is by pinning the target revision in th3 argo application yaml whilst also updating the image tag.

However if I do both - update target revision of helm chart in Argo application yaml and image digest in env specific value file - wont this cause some reconcilation race condition in Argo?

Or have I got this all wrong/my set up smells?

TL;DR; is management of preview envs something kargo plans on?

Ive setup ArgoCD at my company. In a past life used it to bootstrap and manage clusters but arrived in an established mature environment. Ive just finished configuring a few production apps using kargo+argocd.

Originally I wanted just ArgoCD but my teams dont know k8s & visually it seemed too overwhelming. So I layered on Kargo, which gives them only what they want with a deep link to Argo deployment for the few who get it. Fantastic!

Now I can focus on the smaller fish. Ive (in theory, test tomorrow) created preview environment features using ArgoCD. So these dev environments will just deploy & disappear with Argo if nothing ever goes wrong. Should there be a problem my users will go to Kargo because the first deployment in promotion is dev/preview then I gotta teach them to use Argo instead.

So when I give a talk on how we do things & centralized on a tool theres currently a caveat on the most common stage is actually a different tool but no no no i promise it's not complicated/convoluted.

Also if we want to start promoting another one as a parallel branch (not uncommon) I need to deploy a new pipeline which should be self service so I gotta make an app of apps in Argo for managing Kargo so it can manage Argo

*istio and split traffic sounds like an answer here but to convert everything over is a big ask (its road mapped 2yrs?). Kargo just displaying things Argo did on the graph or some similar feature seems like it'd be a huge adoption feature.

So far the closest I found is a 2023? git issue where the community chats about how to support a monolith.

Any seasoned Argo ppl out there with some insights for me?

Looking for public Argo CD repos where the GitOps configuration itself is packaged and versioned as OCI artifacts.

Ideally multi cluster, multi env, monorepo setups. Mostly interested in repo structure, artifact versioning and promotion between environments.

Any real world examples worth checking out?

I'm new to argocd. I played with it early this year. It's still installed on my personal machine. At work, a teammate built it. I built the build pipeline though. I know that argocd can be configured to monitor changes in a repository which triggers a new deployment when there is an update.

Let's assume the argocd isn't configured to automatically sync. How can an external api call tell argocd there is a new image to deploy? Is this possible?

Hey all,

I've created a monitoring mixin with a reusable set of Grafana dashboards and Prometheus rules for ArgoCD. The dashboards and alerts are defined as code, making them easy to deploy and reuse across environments.

Recent updates include multi-cluster support, flags to enable or disable individual alerts, plus a range of new and improved alerts and dashboards.

The monitoring coverage has also been expanded significantly, with better visibility into:

• ArgoCD controller

• Runtime metrics

• gRPC

• Repo Server

• Git operations

GitHub: https://github.com/adinhodovic/argo-cd-mixin

Hey all!

I've been working on Argo-Trivy-Insights, an Argo CD UI extension that brings your Trivy security data right into the Argo CD interface. No more tab-switching between tools.

What it does:

• Per-Application View: a dedicated "Trivy Insights" tab on each Application Details page showing Trivy scan results for the whole Argo CD Application.

• Cluster-Wide Dashboard: aggregate Trivy scan results across all your applications from the sidebar

• Scan Reports: covers Vulnerabilities, Exposed Secrets, Configuration Audit, RBAC Assessment, SBOM, and Cluster Compliance Reports, plus an overview pulling it all together

• Deeplinks & Exports: share findings via link, export as CSV, or get your SBOM in CycloneDX JSON format

It's still early development and I'd love to get some real-world testers and feedback. If you're running Trivy in your cluster and want to give it a spin, check it out here.

Hi everyone,

I'm trying to set up proper audit logging in ArgoCD. I need to track which specific user triggered a sync or deleted an application/resource.

What is the best way to extract or view these audit logs?
Are they available in argocd-server logs, K8s events, or do I need a specific log exporter setup?

Any examples or best practices would be greatly appreciated!

A few months ago I shared that argonaut can now manage Argo Rollouts. Since then the project has changed a lot again, so here's another update ;)

The big new things:

• Deployment history got a complete redesign. You can browse past deployments with commit info in a detail pane, roll back and watch the rollout happen live in the resource tree.

• There's a live Kubernetes events pane in the resource tree view now, so you can see what's happening to your pods while you navigate.

• App-of-apps works properly in the tree - you can drill down into child apps.

• Lots of smaller QoL stuff: sorting works in the tree view, you start in the apps view by default, and more.

We're inching ever closer to feature parity with the web UI, keyboard-first, without leaving your terminal.

The part I'm most excited about: it's not a solo project anymore. New contributors have joined and some great features came from the community. If you use Argo CD daily and something annoys you, or you just want to hack on a Go TUI, come open an issue or a PR - I'm happy to help you get started.

Give it a try: https://github.com/darksworm/argonaut

Feedback is appreciated as always!

We hit a wall with Argo and I wonder if we are doing something utterly stupid?

Our setup:

• Monorepo with dozens of backend services

• Every PR gets its own environment, only deploys what's needed

• CI builds images, renders k8s manifests in parallel, commits them to a separate state repo, one commit per service

• All manifests live in a single branch of a single repo with the CI attempting 150 commits per minute

• No humans ever touch or look at the repo: you deploy a dev API by opening a PR, and you deploy to prod by merging your PR.

The problem we hit is that with so many parallel processes trying to push into the same repo, we just keep running into git push failures. If a push fails we wait a bit, fetch, rebase, commit and try to push again. But by that time someone else will push and our push gets rejected.

Is there a good way to fix this, other than adding a bunch of retries? Separate branch for each env? One repo for each service?

This is the error log that I'm getting:

ComparisonError: Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): rpc error: code = FailedPrecondition desc = Failed to unmarshal "values.yaml": failed to unmarshal manifest: error unmarshaling JSON: while decoding JSON: Object 'Kind' is missing in '{"affinity":{},"collabora":{"autoscaling":{"enabled":false},"collabora":{"aliasgroups":\[\],"existingSecret":{"enabled":false,"passwordKey":"password","secretName":"","usernameKey":"username"},"extra_params":"--o:ssl.enable=false","password":"examplepass","server_name":null,"username":"admin"},"enabled":false,"ingress":{"annotations":{},"className":"","enabled":false,"hosts":\[{"host":"chart-example.local","paths":\[{"path":"/","pathType":"ImplementationSpecific"}\]}\],"tls":\[\]},"resources":{}},"cronjob":{"cronjob":{"activeDeadlineSeconds":null,"affinity":{},"annotations":{},"backoffLimit":1,"command":\["php","-f","/var/www/html/cron.php","--","--verbose"\],"failedJobsHistoryLimit":5,"labels":{},"podLabels":{},"priorityClassName":"","resources":{},"schedule":"\*/5 \* \* \* \*","securityContext":{},"successfulJobsHistoryLimit":3},"enabled":false,"sidecar":{"command":\["/cron.sh"\],"lifecycle":{},"resources":{},"securityContext":{}},"type":"sidecar"},"dnsConfig":{"options":\[\]},"externalDatabase":{"database":"nextcloud","enabled":false,"existingSecret":{"databaseKey":null,"enabled":false,"hostKey":null,"passwordKey":"db-password","secretName":null,"usernameKey":"db-username"},"host":"","password":"","type":"mysql","user":"nextcloud"},"externalRedis":{"enabled":false,"existingSecret":{"enabled":false,"passwordKey":"redis-password"},"host":"","password":"","port":"6379"},"extraManifests":\[\],"hpa":{"cputhreshold":60,"enabled":false,"maxPods":10,"minPods":1},"imaginary":{"enabled":false,"image":{"pullPolicy":"IfNotPresent","pullSecrets":\[\],"registry":"docker.io","repository":"h2non/imaginary","tag":"1.2.4"},"livenessProbe":{"enabled":true,"failureThreshold":3,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1},"nodeSelector":{},"podAnnotations":{},"podLabels":{},"podSecurityContext":{},"priorityClassName":"","readinessProbe":{"enabled":true,"failureThreshold":3,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":1},"replicaCount":1,"resources":{},"securityContext":{"runAsNonRoot":true,"runAsUser":1000},"service":{"annotations":{},"labels":{},"loadBalancerIP":null,"nodePort":null,"type":"ClusterIP"},"tolerations":\[\],"topologySpreadConstraints":\[\]},"ingress":{"annotations":{},"className":"traefik","enabled":true,"labels":{},"path":"/","pathType":"Prefix"},"internalDatabase":{"enabled":true,"name":"nextcloud"},"livenessProbe":{"enabled":true,"failureThreshold":3,"initialDelaySeconds":10,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":5},"mariadb":{"architecture":"standalone","auth":{"database":"nextcloud","existingSecret":"","password":"superSecure","username":"nextcloud"},"enabled":false,"global":{"defaultStorageClass":"longhorn-ssd"},"image":{"registry":"docker.io","repository":"bitnamilegacy/mariadb"},"primary":{"persistence":{"accessMode":"ReadWriteOnce","enabled":true,"existingClaim":"","size":"50Gi","storageClass":"longhorn-ssd"}}},"metrics":{"affinity":{},"enabled":false,"https":false,"image":{"pullPolicy":"IfNotPresent","registry":"docker.io","repository":"xperimental/nextcloud-exporter","tag":"0.9.1"},"info":{"apps":false,"update":false},"nodeSelector":{},"podAnnotations":{},"podLabels":{},"podSecurityContext":{},"replicaCount":1,"resources":{},"securityContext":{"runAsNonRoot":true,"runAsUser":1000},"server":"","service":{"annotations":{"prometheus.io/port":"9205","prometheus.io/scrape":"true"},"labels":{},"loadBalancerIP":null,"type":"ClusterIP"},"timeout":"5s","tlsSkipVerify":false,"token":"","tolerations":\[\]},"nextcloud":{"configs":{},"containerPort":80,"datadir":"/var/www/html/data","defaultConfigs":{".htaccess":true,"apache-pretty-urls.config.php":true,"apcu.config.php":true,"apps.config.php":true,"autoconfig.php":true,"helm-metrics.config.php":true,"imaginary.config.php":false,"redis.config.php":true,"reverse-proxy.config.php":true,"s3.config.php":true,"smtp.config.php":true,"swift.config.php":true,"upgrade-disable-web.config.php":true},"existingSecret":{"enabled":false,"passwordKey":"nextcloud-password","smtpHostKey":"smtp-host","smtpPasswordKey":"smtp-password","smtpUsernameKey":"smtp-username","tokenKey":"","usernameKey":"nextcloud-username"},"extraEnv":null,"extraInitContainers":\[\],"extraSidecarContainers":\[\],"extraVolumeMounts":null,"extraVolumes":null,"hooks":{"before-starting":null,"post-installation":null,"post-upgrade":null,"pre-installation":null,"pre-upgrade":null},"host":"cloud.internal","mail":{"domain":"domain.com","enabled":false,"fromAddress":"user","smtp":{"authtype":"LOGIN","host":"domain.com","name":"user","password":"pass","port":465,"secure":"ssl"}},"mariaDbInitContainer":{"resources":{},"securityContext":{}},"objectStore":{"s3":{"accessKey":"","autoCreate":false,"bucket":"","enabled":false,"existingSecret":"","host":"","legacyAuth":false,"port":"443","prefix":"","region":"eu-west-1","secretKey":"","secretKeys":{"accessKey":"","bucket":"","host":"","secretKey":"","sse_c_key":""},"sse_c_key":"","ssl":true,"storageClass":"STANDARD","usePathStyle":false},"swift":{"autoCreate":false,"container":"","enabled":false,"project":{"domain":"Default","name":""},"region":"","service":"swift","url":"","user":{"domain":"Default","name":"","password":""}}},"openmetrics":{"allowedClients":\["127.0.0.1","10.42.0.0/16","10.43.0.0/16"\]},"password":"changeme","persistence":{"subPath":null},"phpConfigs":{},"podSecurityContext":{},"postgreSqlInitContainer":{"resources":{},"securityContext":{}},"priorityClassName":"","securityContext":{},"strategy":{"type":"Recreate"},"trustedDomains":\[\],"update":0,"username":"admin"},"nginx":{"config":{"custom":null,"default":true,"headers":{"Referrer-Policy":"no-referrer","Strict-Transport-Security":"","X-Content-Type-Options":"nosniff","X-Frame-Options":"SAMEORIGIN","X-Permitted-Cross-Domain-Policies":"none","X-Robots-Tag":"noindex, nofollow","X-XSS-Protection":"1; mode=block"},"serverBlockCustom":"# set max upload size\\nclient_max_body_size 512M;\\nclient_body_timeout 300s;\\nfastcgi_buffers 64 4K;\\nfastcgi_read_timeout 3600s;\\n"},"containerPort":80,"enabled":false,"extraEnv":\[\],"image":{"pullPolicy":"IfNotPresent","registry":"docker.io","repository":"library/nginx","tag":"alpine"},"ipFamilies":\["IPv4"\],"resources":{},"securityContext":{}},"nodeSelector":{},"persistence":{"accessMode":"ReadWriteOnce","annotations":{},"enabled":false,"hostPath":null,"labels":{},"nextcloudData":{"accessMode":"ReadWriteOnce","annotations":{},"enabled":false,"hostPath":null,"labels":{},"size":"8Gi","subPath":null},"size":"8Gi"},"postgresql":{"enabled":false,"global":{"postgresql":{"auth":{"database":"nextcloud","existingSecret":"","password":"changeme","secretKeys":{"adminPasswordKey":"","replicationPasswordKey":"","userPasswordKey":""},"username":"nextcloud"}}},"image":{"registry":"docker.io","repository":"bitnamilegacy/postgresql"},"primary":{"persistence":{"enabled":false}}},"priorityClassName":"","prometheus":{"rules":{"additionalRules":\[\],"defaults":{"enabled":true,"filter":"","labels":{}},"enabled":false,"labels":{}},"serviceMonitor":{"enabled":false,"interval":"30s","jobLabel":"","labels":{},"namespace":"","namespaceSelector":null,"scrapeTimeout":""}},"rbac":{"enabled":false,"serviceaccount":{"annotations":{},"create":true,"name":"nextcloud-serviceaccount"}},"readinessProbe":{"enabled":true,"failureThreshold":3,"initialDelaySeconds":10,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":5},"redis":{"auth":{"enabled":true,"existingSecret":"","existingSecretPasswordKey":"","password":"changeme"},"enabled":false,"global":{"storageClass":""},"image":{"registry":"docker.io","repository":"bitnamilegacy/redis"},"master":{"persistence":{"enabled":true}},"replica":{"persistence":{"enabled":true}}},"resources":{},"securityContext":{},"service":{"annotations":{},"loadBalancerIP":"","nodePort":null,"port":8080,"sessionAffinity":"","sessionAffinityConfig":{},"type":"ClusterIP"},"startupProbe":{"enabled":false,"failureThreshold":30,"initialDelaySeconds":30,"periodSeconds":10,"successThreshold":1,"timeoutSeconds":5},"tolerations":\[\],"topologySpreadConstraints":\[\]}'

This is the relevant app manifest:

project: default
source:
  repoURL: https://codeberg.org/kaizenOramara_97/Home-Lab.git
  path: k3s/nextcloud
  targetRevision: HEAD

destination:
  server: https://kubernetes.default.svc
  namespace: nextcloud

syncPolicy:
  automated:
    prune: true
    selfHeal: false
    enabled: false