The Problem with Opaque Rendering

▶ Watch (0:20)

Before rendered manifests, Argo CD took a Git change, ran Helm, Kustomize, or JSONnet, and applied thousands of lines of YAML to the cluster. Users never saw that intermediate output. The rendering step was opaque. They could not tell exactly what hit the cluster or trace a failure back to a specific manifest state. That missing visibility is what pushed teams toward the rendered manifest pattern in the first place.

Why the Rendered Manifest Pattern Adds Maintenance Burden

▶ Watch (0:52)

The rendered manifest pattern fixes visibility but adds a custom render pipeline between Git and Argo CD. At Intuit, that pipeline is Jenkins running Kustomize and pushing to Git. It lacks a UI, does not retry on transient network failures, and requires ongoing maintenance. Every team building this column builds it from scratch. Crenshaw’s goal was to pull that work into Argo CD itself as a supported, first-class feature instead of leaving it as custom internal code.

How Source Hydrator Works

▶ Watch (1:52)

Source Hydrator adds two fields to the Argo CD application spec. Copy the existing repo, targetRevision, and path fields into spec.sourceHydrator.drySource. Then add a syncSource field pointing to where the rendered manifest.yaml should be pushed and synced from. Argo CD renders using the same code it has always used, pushes a flat manifest file to Git, and syncs from that location. The result is a full audit trail: every rendered state is stored in Git and reviewable.

Intuit’s 50-Instance Deployment as a Live Example

▶ Watch (3:19)

Crenshaw’s configuration is adapted from what Intuit runs in production today to deploy Argo CD itself across 50 instances in six waves. Wave zero targets an instance called Argo. The Argo CD UI gains an additional toolbar that walks left to right: hydrated location, push destination, and sync confirmation. This makes the full pipeline visible in one screen, replacing the invisible middle step that caused confusion before the feature existed.

The “Hydrate To” Branch and GitOps Promoter

▶ Watch (4:00)

Source Hydrator includes a hydrateTo option that pushes rendered manifests to a different branch than the sync source. That gap between branches lets teams insert security checks or additional automation before promotion. Intuit uses this with a recently open-sourced tool called GitOps Promoter, which automatically opens and merges pull requests from the hydrateTo branch to the sync source branch, automating environment promotion without manual steps.

Notable Quotes

the problem is you have to maintain that render column. That’s custom internal code. At Intuit, it’s Jenkins. Michael Crenshaw · ▶ 01:25

dry just means don’t repeat yourself. It’s pre-hydrated manifests. Michael Crenshaw · ▶ 02:56

we’ve got 50 Argo CD instances. One of them is literally confusingly called Argo. Michael Crenshaw · ▶ 03:19

Key Takeaways

  • Source Hydrator replaces custom render pipelines by building the step into Argo CD itself.
  • Enabling the feature requires copying three fields and adding one syncSource destination.
  • The hydrateTo option, combined with GitOps Promoter, automates full environment promotion via pull requests.

About the Speaker(s)

Michael Crenshaw is a Senior Staff Software Engineer on the Argo CD team at Intuit and the most active contributor to the Argo project. He focuses on security and performance improvements in Argo CD and helps maintain Intuit’s roughly 50 Argo CD instances and approximately 30,000 Argo CD applications.