argoproj/argocd-example-apps: fifteen examples that are also a live deployment

Every table row is an API endpoint reporting a real sync state

The README looks like a documentation table and is not one. Each of the fifteen rows carries a status badge, and the link definitions at the bottom of the file show what those badges are. A row for the application of apps points at a badge endpoint built from two query parameters, a revision flag and a name:

https://cd.apps.argoproj.io/api/badge?revision=true&name=sync-example-apps

So the badge is not a static image in the repository. It is a request to an Argo CD instance, and the revision parameter means the response reflects the commit currently deployed rather than the commit in the branch. Each row also links an application page on the same instance, such as the page for the example ApplicationSet at the applications path. That changes what this repository is. It is not a set of files with a readme; it is a set of applications registered against a running Argo CD installation, continuously reconciled from this repository, with the README acting as a status page for that deployment. The instruction at the top of the file confirms the intent, inviting you to register this repository to your own instance, or to fork it and push your own commits to explore the model. So the examples double as a GitOps test fixture. If you fork the repository, every one of these applications becomes a probe for your own instance, and the badge pattern is how you would build your own status page.

One guestbook application, expressed five ways

Five of the fifteen directories are the same application, a hello world guestbook, written out in five different configuration management styles. There is a plain YAML version, which is the baseline with no tooling at all. There is a Helm chart version. There is a raw Jsonnet version, and a second Jsonnet version that adds support for top level arguments, so you can parameterise the same source. And there is a Kustomize version. That is the most useful pedagogical device in the repository, because it turns an abstract question into a controlled comparison. The question a team actually has is which of these they should use, and a set of five directories with the same application in each answers it structurally rather than prosaically: you can register all five, look at what each produces, and see which one the team can maintain. The Jsonnet pair is the sharpest of the comparisons, because the difference between them is a single feature, top level arguments, and that is exactly the difference between a config format you can parameterise and one you cannot. The Helm pair is the other one worth comparing, since one version is a chart you would write yourself and the helm-dependency directory covers the different case of overriding a chart that someone else maintains.

ApplicationSet generators, including one that is broken on purpose

The ApplicationSet directory is the densest example in the repository, and its description is a list. It carries one example per generator type: List, Cluster, Git, Matrix, Merge and Pull Request. Alongside those it includes an intentionally broken Git generator, a progressive sync example, and examples of an ApplicationSet in any namespace. Six generator types is the whole surface of the mechanism, and having each one in its own case means you can see what configuration produces which behaviour rather than inferring it from documentation. The deliberately broken entry deserves more attention than it gets, and it is the one piece of advice in this article that matters before you do anything else. If you register this repository wholesale into an Argo CD instance, the broken Git generator comes with it and will produce a resource that fails to sync. That is the point of the example, and it is a good one, since the failure state of a generator is otherwise hard to see. But it means a repository-wide registration is not a clean starting point for a production instance. Register the applicationset directory on its own if you want to study it, and expect one red status. The progressive sync and any-namespace examples are the two newer capabilities in the same directory, and both address problems that appear once you have more than one cluster: rollout pacing across a fleet, and managing resources outside the namespace an application lives in.

Sync waves and PreSync/PostSync hooks, which is where ordering lives

Three directories deal with ordering, and together they cover the part of GitOps that is genuinely hard. The pre-post-sync directory demonstrates the Argo CD PreSync and PostSync hooks, which run before and after a synchronisation. The sync-waves directory demonstrates sync waves with hooks, which is how you make a set of applications apply in a defined sequence. And the helm-hooks directory demonstrates native Helm hooks. The distinction between the last two is the one that catches people. A Helm hook is a hook expressed in the chart and interpreted by Helm, so it has Helm's semantics. A PreSync or PostSync hook is interpreted by Argo CD itself, so it applies to any application regardless of how its manifests are produced, including the plain YAML and Jsonnet examples in the same repository. So if your config management path is Jsonnet, Helm hooks are not available to you, and the Argo CD hooks are the mechanism you use. Sync waves are the third layer, and they are about relationships between applications rather than steps within one: a database migration application has to complete before the application that reads the migrated schema syncs, and waves express that ordering across separate applications. Read together, these three directories answer the question that makes GitOps hard in production, which is not whether the manifests apply but in what order.

Config management plugins, demonstrated in two directories

Two directories demonstrate a different kind of extension. The plugins/kasane example shows config management plugin usage with a named tool, and the plugins/customized-helm example shows plugin usage with a kustomized Helm chart. The distinction from the other fifteen directories is that a config management plugin is not a format. It is an external binary that Argo CD invokes to produce manifests, which means the tool is responsible for its own output and its own dependencies, and the plugin is configured in the application rather than declared in the manifests. That is an escape hatch with a real trade. The upside is that you can generate manifests from a tool that already exists in your organisation, including a proprietary generator, instead of rewriting them by hand. The cost is that the generation step now happens outside the reconciliation loop in a way you have to think about: the plugin is invoked on the cluster or in the Argo CD pod, it has to be installed there, and its version is not managed by the application's manifests. The two examples are chosen well for this. One is an existing third-party tool, so you can see the integration shape without a new dependency, and the other is a customised chart, which is the case where a plugin earns its keep because you are transforming a chart you do not control. The helm-dependency directory in the main table covers the same problem from the other direction, so you can compare the plugin route with the supported one.

Sixteen directories, fifteen table rows, and a microservices demo borrowed from elsewhere

Count the top-level directories against the table and there is a mismatch worth knowing about. The listing holds seventeen directories once the plugins directory is included, which is fifteen example directories plus a container of two plugin examples, and one of them is not in the table. The lightweight directory has no row in the visible table, which means either it is documented further down the file or it is an example that was added without a table entry. Either way, the practical lesson is the same: the table is not a complete inventory, so a repository-wide registration is a slightly larger operation than the table suggests. Two other things in the listing shape what you get. The sock-shop directory is not written by this project at all; it is an existing microservices demo application, linked from its own site, and it is here because it has enough moving parts to make a realistic target for sync behaviour. That is a good choice for a test fixture, since a hello world app will not exercise the paths, rollback or wave logic you actually want to see. And the sock-shop application, along with everything else here, is deployed to a shared public instance, which is a reminder that these examples run somewhere real. If you fork the repository for your own testing, you are forking a configuration that is currently reconciling production-adjacent namespaces, and it is worth checking that the badges are all green before you start pushing.

Editorial conclusion

Use this repository as a fixture for learning or testing Argo CD behaviour, because every example is deployed against a live instance and the README reports the actual sync revision, so a reader can see whether the thing they are about to register is healthy before they register it. Do not register the whole repository into a production Argo CD instance as a first step, because the ApplicationSet example includes a deliberately broken Git generator and sixteen directories are registered where the table lists fifteen, so you will get a failing resource by design. Two things to check first. Decide which config management path you actually use, because the same guestbook application appears five times over and only one of them is yours. And read the ApplicationSet row before the guestbook one, because that is where the generators live and where the intentional failure sits. If you want a baseline environment for testing sync behaviour, forking this repository and pushing your own commits is the documented path, and the badges tell you when your change has landed.

Frequently asked questions

Official sources

1. argoproj/argocd-example-apps on GitHub
2. Issues
3. README