Visit Website →
← Back to blog

How to Manage Argo CD Applications: Sync, Inspect, Scale

November 3, 2026
How to Manage Argo CD Applications: Sync, Inspect, Scale

Managing Argo CD applications comes down to four jobs: seeing what each application is doing, syncing it when you decide to, organizing many of them without chaos, and fixing them fast when they drift or stall. The CLI and the web UI cover this for one cluster. Once you run several clusters, most teams add a GUI that reaches every cluster from one place. This guide walks through each job in the order you meet them.

Kubezilla Desktop
Manage Argo CD Across Clusters
Kubezilla Desktop brings multiple clusters, live logs, metrics, and ArgoCD operations into one native interface with kubeconfigs stored locally.
Explore Kubezilla Desktop

TL;DR

  • An Argo CD application is a group of Kubernetes resources deployed together. Argo CD compares live state to the state declared in Git. Refresh compares, and sync applies.
  • Inspect with argocd app get and argocd app resources. Use the tree output to see parent-child relationships and the orphaned filter to find strays.
  • Use manual sync for production, risky changes and anything that needs a human check. Use automated sync where drift should heal itself.
  • Use ApplicationSets for templated apps across clusters, and an app-of-apps root for bootstrapping. They work well together.
  • A good GUI keeps kubeconfigs local, reaches several clusters, and puts logs, events and Helm next to the application.

Table of Contents

What an Argo CD application actually is

An Argo CD application is a group of Kubernetes resources that together deploy a workload, stored in the cluster as an instance of a custom resource definition. That detail matters in daily work. An application is just another Kubernetes object, so you can list it, describe it, version it in Git and review changes to it like any other manifest.

The core loop is simple. Argo CD compares the live state in the cluster with the target state declared in Git. According to the same overview, refresh compares the two states without necessarily applying anything, while sync applies the changes it found. Keeping those two verbs apart prevents most early confusion. A refresh is safe and read-only in spirit. A sync changes your cluster.

Two status fields tell you where an application stands:

  • Sync status says whether live state matches Git: synced or out of sync.
  • Health status says whether the resources are working: healthy, progressing, degraded and so on.

An application can be synced and unhealthy (the manifests match Git, but the pods crash), or out of sync and healthy (someone changed a replica count by hand, and traffic is fine). Read both before acting.

Inspect an application before you touch it

Start every change by looking. In the web UI, the application overview shows its components along with current sync and health states, and the App Details view shows configuration and events. That is enough for a quick check on one application.

From the terminal, two commands do most of the work.

Get the application summary

Run argocd app get APPNAME. The official command reference lists output in wide, YAML, JSON and tree formats, plus a --show-operation flag that displays the current operation. Use JSON or YAML when you feed the result into scripts. Use --show-operation when a sync is running and you want to know what it is doing right now.

List the resources it manages

Run argocd app resources APPNAME. Per the command reference for app resources, you can filter for orphaned resources with --orphaned, and show parent-child relationships with --output tree, or the more detailed tree=detailed format. The tree view is the fastest way to see that a Deployment owns a ReplicaSet that owns the failing pod. The orphaned filter helps in cleanups, since it surfaces resources that exist in the namespace but belong to no application.

A habit worth building: run app get, then app resources, then decide. Most mistakes in application management come from acting on the summary without looking at the resource tree.

List the resources it manages

Manually sync an Argo CD application

A manual sync is you telling Argo CD: apply what Git says, now. You can start it from the UI by selecting the application and choosing sync, or from the CLI with argocd app sync APPNAME. Both offer options such as syncing only selected resources, pruning resources no longer in Git, and a dry run. Check the options available in your version before using them in production.

A safe manual sync routine

  1. Refresh first. Confirm Argo CD has the latest commit from the repository, so the diff you review is current.
  2. Read the diff. Look at what is out of sync, resource by resource. If a resource you did not expect shows up, stop and find out why.
  3. Sync selectively when you can. If only one Deployment changed, sync that resource rather than the whole application.
  4. Treat prune as a separate decision. Pruning deletes live resources that Git no longer declares. That is often exactly what you want, and also what makes a bad merge expensive.
  5. Watch the rollout. Keep the resource tree and pod logs open until the new pods are healthy.

If you want a server-side safety check before changing anything, our guide to Kubernetes dry runs explains which dry-run option actually checks admission.

Manual or automated sync?

Neither is better in general. The question is who should decide when a change lands.

SituationBetter fitWhy
Development or preview environmentsAutomatedFast feedback, low blast radius
Production with change windowsManualA person approves timing
Apps with database migrations or CRD changesManualOrder and timing matter
Config that people tend to hand-editAutomated with self-healDrift gets corrected without a ticket
Clusters with strict audit needsManual, or automated with protected branchesApproval trail is clear

A common pattern is automated sync in lower environments and manual sync in production, with both reading from the same repository layout. That keeps promotion explicit: merge to the production path, review the diff, press sync.

Organize many applications: ApplicationSets and app-of-apps

One application is easy. Fifty across four clusters is where teams start losing track. Two patterns handle the growth.

ApplicationSets generate applications from a template. According to a December 2025 presentation on multi-cluster deployments, ApplicationSets automate templated deployments across clusters. Use one when the same app should exist in many places with small differences, such as cluster name, namespace or values file.

App-of-apps is a root application whose manifests are other applications. The same presentation notes that this pattern can group ApplicationSets in a root app for cluster bootstrapping. Use it when a new cluster should come up with a known set of platform components (ingress, monitoring, policy) from a single command.

The two are not rivals. Practitioners describe them as complementary, often combined in complex bootstrap workflows, per the same source. A workable rule:

  • Same app, many targets: ApplicationSet.
  • Many different apps, one bootstrap entry point: app-of-apps.
  • Both needs at once: a root app that deploys ApplicationSets.

Keep the layout boring

Whatever you choose, keep the repository layout predictable: one directory per application, one overlay or values file per environment, and consistent names. Generated applications are only as understandable as the folders they read from. If your applications deploy Helm charts, see how to deploy charts the GitOps way with Argo CD.

Manage applications across clusters

Argo CD can reach several clusters from one control plane, but day-to-day debugging still happens where the workloads run. That is where tooling friction appears: a different kubeconfig context per cluster, a VPN for one, a bastion host for another, and a browser tab for each Argo CD instance.

Two practical habits help:

  • Name clusters and projects consistently, so an application's destination is obvious from its name.
  • Avoid long-lived shared credentials for cluster access. Static tokens are easy to leak and hard to rotate. We cover the trade-offs in Argo CD across clusters: skipping static tokens.

If your clusters span providers, the same problems multiply. Our notes on multi-cloud Kubernetes management and Cluster API for platform teams go deeper on fleet-level structure.

Troubleshoot sync and reconciliation problems

Most stuck applications fall into a few families. Work through them in this order.

The application is out of sync and stays that way

Something keeps changing live state after sync. Typical causes are a controller or admission webhook that mutates a field, or a tool that writes defaults Git does not declare. Look at the diff for the same field every time. If a controller owns that field, configure the application to ignore the difference rather than syncing repeatedly.

The sync fails

Read the operation result with argocd app get APPNAME --show-operation. Failures usually name a resource: a schema error, a missing namespace, a forbidden action or a hook that did not finish. Fix the manifest in Git, then refresh and sync again.

The application is synced but degraded

Argo CD did its job and Kubernetes did not. Open the resource tree, find the unhealthy pod, and read its events and logs. Image pull errors, failing probes and unmet resource requests are the usual suspects. If a rollout needs a nudge, restart the Deployment and verify the rollout instead of restarting everything in the namespace.

Orphaned or unexpected resources

Run argocd app resources APPNAME --orphaned to find resources that exist in a managed namespace without belonging to the application. Decide whether to adopt them into Git or delete them deliberately.

The repository does not seem to update

If a commit does not appear, trigger a refresh and check repository connectivity and credentials. Slow detection after a push is normal when you rely on polling rather than webhooks, so confirm which one your setup uses before assuming a fault.

Perspective: why we built a desktop client for this

We talk to engineers who run Argo CD every day, and the complaint is rarely about Argo CD itself. It is the surrounding friction: one browser tab per instance, a terminal per cluster, a VPN to reach one API server and a bastion to reach another, and kubeconfigs scattered across laptops.

Our view is that application management is a daily workflow, so it deserves a native tool. Kubezilla Desktop is built in Rust for low memory use and fast startup, and it stores your kubeconfigs securely on your own machine. There is no cloud sync and no telemetry in our design, because cluster credentials are exactly what should not leave your laptop.

We also think the best debugging happens in one window: live logs, metrics, a pod terminal, YAML editing and Helm and ArgoCD operations next to each other, across clusters, with SSH tunnels built in. When a sync leaves an application degraded, you should not need five tools to find the failing pod.

Margus

Choose a GUI for Argo CD applications

The built-in web UI is good at showing one Argo CD instance. Teams look for something more when they work across clusters, when access sits behind tunnels, or when they want the cluster view and the GitOps view together. Judge any option on these criteria:

CriterionWhat to look for
Credential handlingKubeconfigs stored locally, no mandatory cloud account, no telemetry you cannot turn off
Multi-cluster accessSwitch clusters without re-authenticating through separate tools
Network reachSSH tunnel support for clusters behind bastions or private networks
Live visibilityStreaming logs, metrics and events beside the resource tree
OperationsSync, refresh, Helm and YAML editing without leaving the app
FootprintLow memory and quick startup, since you open it all day
PlatformsLinux, macOS and Windows, so the whole team uses the same tool

A GUI is not a replacement for Git as the source of truth. It is the place where you read state, run the sync you decided on, and debug. Whatever it changes by hand should be reflected back into the repository.

Try it on your own clusters

Kubezilla Desktop is our native app for managing Kubernetes clusters. It connects to multiple clusters, supports SSH tunnels for remote access, streams logs and metrics live, includes pod terminals and YAML editing, and gives you quick access to Helm and ArgoCD operations. It runs on Linux, macOS and Windows and costs €5 per month. See the Kubezilla Desktop app or the pricing page.

Kubezilla Desktop

If you want a closer look at the product itself first, the Kubernetes desktop app page covers the feature set.

A weekly routine for healthy applications

A short routine prevents most surprises:

  • Daily: scan for applications that are degraded or out of sync outside change windows.
  • Before each production sync: refresh, read the diff, check prune.
  • Weekly: list orphaned resources per application and resolve them.
  • Monthly: review who can sync what, which projects exist, and whether any cluster credentials should be rotated.
  • Per new cluster: bootstrap from the same root application so every cluster starts alike.

None of this is exotic. The value is consistency, and consistency is easier when the commands, the logs and the cluster contexts live in one tool.

FAQ

How do I manually sync an Argo CD application?

Select the application in the UI and start a sync, or run argocd app sync APPNAME. Refresh first so the diff reflects the latest commit, review what is out of sync, and sync only the resources you intend to change. Watch the resource tree until everything is healthy.

What is the difference between refresh and sync?

Refresh compares live state with the state declared in Git and does not necessarily change anything. Sync applies the differences it found, as described in this Argo CD overview. Refresh to look, sync to act.

Should I use ApplicationSets or app-of-apps?

Use ApplicationSets when one template should produce the same app across many clusters or environments. Use app-of-apps when you want one root application to bootstrap many different components. Many teams combine them, with a root app that deploys ApplicationSets.

How do I find resources Argo CD no longer manages?

Run argocd app resources APPNAME --orphaned, a filter documented in the official command reference. Then either bring those resources into Git or delete them on purpose.

What should I look for in an Argo CD GUI?

Check how it stores cluster credentials, whether it reaches several clusters and tunneled networks, and whether logs, metrics and sync actions sit in one view. Native performance matters too, because you will keep it open all day.

Sources