In Argo CD, pin third-party inputs by using exact Helm chart versions, Git tags or commit SHAs for sources, and by installing config management plugins only from trusted, audited sources with versioned images. Anything that tracks HEAD, a branch or a star range can change meaning without a change in your repository.
Does Argo CD have actions to pin?
Not in the GitHub sense. Argo CD does not run third-party workflow steps the way a hosted CI does. Its outside inputs are different: chart repositories, Git repositories, kustomize remote bases, and config management plugins that run in the repo server. Those are what you pin.
How do tracking strategies work?
The Argo CD documentation lays out tracking strategies per source type. For Helm, chart versions are semantic versions, and a table shows how to pin to a version in production: use the exact number, such as 1.2.0. Ranges like 1.2.* track patches, 1.* tracks minor releases, and a star range tracks the latest, including with a prerelease suffix.
For Git, all versions are Git references. To pin in production, either tag the commit and use the tag, or use the commit SHA. Branch or HEAD tracking compares live state to the tip of the branch, which moves whenever someone pushes. Tag tracking is more stable but the docs say a tag can be changed by retagging it to a different commit, so a SHA is the strongest pin. Semver constraints are matched only against tags, never branches.
A constructed example: the production app for a billing service uses a chart source with a star range, the same as in the dev environment. A maintainer of the upstream chart publishes a new major release with changed defaults. The next auto-sync applies it to production. A pinned version would have kept the cluster unchanged until a reviewed pull request bumped it.
What about remote bases and templating?
The Argo CD best practices page warns that manifests at a Git revision are not truly immutable when templating tools pull from upstream. Its example is a kustomization that references a remote base at HEAD of the argo-cd repository: the manifests can change meaning without any change in your own repository. The better version uses a tag or commit SHA in the ref parameter. Apply the same thought to Helm dependencies inside a chart and to valueFiles pulled from other repositories.
How should you treat config management plugins?
Argo CD's built-in tools are Helm, Jsonnet and Kustomize. A config management plugin lets the repo server delegate manifest generation to another tool, installed as a sidecar. The documentation carries a clear warning: plugins are granted a level of trust in the system, administrators should only install plugins from trusted sources, and they should audit plugins to weigh risks and benefits.
The security page adds that the repo server holds no Kubernetes privileges or Git credentials by default, but may be configured with plugins that do hold sensitive material, such as decryption keys. If so, extreme care must be taken to make sure repository contents can be trusted at all times. It also says you may disable built-in tools you do not need.
Plugin configs support an optional version, and when set the application must refer to the plugin as name plus version. Use that so an app moves to a new plugin only when you change the app.
What to do
- List every Application and ApplicationSet source. Record its type and its revision setting.
- Change production sources to exact chart versions, release tags or commit SHAs. Keep ranges and branches for lower environments only.
- Search kustomizations and Helm dependencies for remote references without a pinned
refor exact version. - Build plugin sidecar images yourself from reviewed sources. Pin the image by digest and record where each tool binary came from.
- Use the plugin version field so applications select a specific plugin release.
- Disable built-in config tools you do not use, per the security page.
- Scan the images and charts you reference. Safeguard can generate an SBOM and scan container images and dependencies so a version bump is a reviewed, evidence-backed change.
Quick check
Is a Git tag a safe pin?
It is stable in normal use, but the Argo CD docs note a tag can be moved by retagging. A commit SHA cannot be moved.
Do plugins run with special privileges?
They run in the repo server's context and the docs say they are granted a level of trust, which is why they must come from trusted sources and be audited.
Sources
- Argo CD: Tracking and Deployment Strategies
- Argo CD: Best Practices
- Argo CD: Config Management Plugins
- Argo CD: Security
Last reviewed: 18 October 2026.
