# An application update is a commit

> The chart version is pinned in the repository. So an update shows up in the diff, a rollback is a reverted commit, and "it updated itself" becomes impossible.

Source: https://naasson.com/en/blog/an-application-update-is-a-commit/
Published: 2026-05-24
Language: en
Direction: Cloud by Naasson (https://naasson.com/en/cloud/)
Publisher: Naasson — https://naasson.com

---
Chart versions in the catalogue are pinned. An application with an unpinned version gets the status "disabled" and is not installed by this build.

A property follows from this that is worth stating plainly: an application does not update itself.

## Why it matters

"It updated itself" is one of the worst phrases in operations. It means the state of the system changed without a human decision, and the investigation has to start without knowing when the change happened.

Most often it happens through a floating tag. The chart refers to an image by a tag like "latest" or by a major version, the content behind that address changes, and on the next reconciliation cycle a different application arrives.

A pinned version removes that mechanism. Until the version line in the repository changes, the same thing is deployed.

## What an update looks like

A version change in the description. A commit. Then ArgoCD brings the cluster to the new state.

That makes an update something to discuss: it is visible in the diff, a reason can be attached to it, and it can be scheduled for a window.

And a rollback is a reverted commit. Not a hunt for the previous chart version, not reconstructing from memory who changed what. The previous state exists as an object.

## What it costs

Updates have to be done. Nobody will do them for you, and it is work that accumulates.

A project where versions are pinned and nobody raises them for a year ends up worse off than a project with automatic updates: the version gap has grown so large that the update has become a project of its own.

We consider this trade the right one, but it is a trade, and it should be described honestly. Pinning versions moves the risk from "broke by itself at an unknown moment" to "goes stale if nobody looks after it". The second is a manageable problem; the first is not.

## What helps you not forget

The fact that the set is described in one place and lives in the repository. The list of versions is a file you can read, not cluster state you have to query.

Separately: bundled chart archives in the binary mean that updating the catalogue and updating an application are different events. A new build of the tool brings new versions into the catalogue but does not change what is already deployed. Until you edit the description, nothing happens.

## The boundary of responsibility

We are responsible for a pinned version deploying the same way it did at certification. We are not responsible for a new version of an application being compatible with your data: that is a question for the application's author and for your backups.

Hence the practical rule: before updating an application that holds state, take a verified backup. Verified means restored at least once, not merely existing.