One binary instead of a platform
Install is one command, update is replacing a file, removal is deleting a file. A platform you have to deploy in order to deploy infrastructure has a chicken-and-egg problem.
The tool is a single executable. It installs with one command or downloads as a build for your platform. It needs no agent in the cluster, no control panel, no database on the side and no subscription to a service.
This is an architectural decision, not asceticism.
The chicken-and-egg problem
A platform you have to deploy in order to deploy infrastructure has an awkward first step. The control panel has to run somewhere, so you need infrastructure for the infrastructure.
The usual answer is to host the panel at the vendor. That creates another problem: your ability to manage your own infrastructure depends on someone else’s service being up, and the description of your infrastructure lives with them.
A binary breaks that recursion. It runs on a laptop, on a virtual machine, on a continuous integration runner: anywhere there is a file system and git.
What follows in practice
An update is replacing a file. Not a database schema migration, not matching agent and server versions, not a maintenance window.
Rolling back to the previous version is also replacing a file. This matters more than it seems: a tool that cannot be rolled back quickly is frightening to update, so it gets updated rarely, so the version gap grows.
No network dependency on an outside service. The tool needs access to the target cloud and to your repository. Nothing else.
The same behaviour locally and in continuous integration. The same file, the same commands, the same output.
What the binary does not have
A multi-user panel with roles. A central log for the whole organisation. A permanent reconciliation loop: on the simple track there is none at all, and on the production track reconciliation is done by ArgoCD in your cluster, not by our service.
These are real limitations, and in some organisations they will be decisive. We prefer to name them rather than describe them as a “simplified model”.
Where the state lives
Since there is no server, the state lives in the project: configuration at the root of the repository, local state in a separate directory, the desired state of applications in the GitOps repository.
A local GitOps run is built so that an external Git server is optional: if the given folder is empty, the tool creates the working tree, a local remote repository, the source file, a commit and the push.
This is not a way around GitOps and not a fallback. It is a local canonical source for anyone who does not yet have their own Git server, with the same behaviour as with an external one.
Who it fits
A small team that does not want a platform department. An organisation whose data sovereignty requirement outweighs the convenience of central management. A project that must keep deploying if the tool’s vendor disappears.
The last point is the most honest reason to choose a single file. A binary you have already downloaded will keep working.