A common misconception in the DevOps industry is that adopting GitOps means replacing existing Continuous Delivery (CD) tools or techniques. An either-or decision and never the two shall meet.
The reality is much more nuanced. Teams that remove the need to make a binary choice between CD and GitOps open up the opportunity to get the best of both worlds.
Bob Walker puts it plainly:
“I can’t tell you the number of times I think people have kind of misconstrued that by adopting GitOps, you no longer have to adopt CD. It’s a binary decision. It’s an either-or.”
GitOps + Continuous Delivery - The best of both worlds
What is Argo CD?
Argo CD is the leading GitOps tool for Kubernetes deployments, used in around 60% of all Kubernetes deployments (Source: CNCF’s 2025 Argo CD End User Survey). It’s a declarative Continuous Delivery tool that uses Git repositories as the source of truth for defining the desired state of your applications. Argo CD automatically syncs your applications to the target environments.
How Argo CD deployments work
Traditional Argo CD deployments work differently from typical CD pipelines. Instead of directly deploying artifacts, you update manifest files (or Helm charts, or Kustomize files) in a Git repository.
With Argo CD in Octopus, we make the commit for you, and you have the flexibility to choose the sync strategy in Argo that works best for your scenario. It can be automatic, manual, or you can add a step in the deployment process to sync.
As Bob explains, “A traditional deployment with Argo is you update some sort of manifest file in a git repository or helm chart or a customized file, and then that tells Argo it needs to do the work, it needs to do the synchronization on top of it.”
The repository strategy question
When adopting GitOps, an early decision for teams is whether to store Kubernetes manifests in the same repository as their application or keep them separate.
Bob highlights a crucial concern: “There’s this question of should you actually separate these out? Is that more of a best practice? Because when it exists in the same repository as your source code, you could potentially make a change to your source code that inadvertently could maybe change production.”
GitOps Strategy: Should manifests live in the same repository as source code?
Separate repositories are typically the safer approach, and you can apply more granular permissions when your manifests live in their own repository. In the scenario where everything is stored in one repository, everyone with code access automatically has production deployment access, creating compliance and security risks.
Bringing Argo CD into Octopus Deploy
Deployment targets and automatic discovery
Argo CD instances serve as deployment targets in Octopus. To connect Argo CD applications to Octopus projects, you need to install the Octopus Kubernetes Agent and add annotations to your Argo CD application definitions, indicating the corresponding project and environment. You also need to install a gateway we provide that links Argo CD with Octopus. We determine the projects and environments based on the annotations - the gateway reads those annotations. The system will automatically discover and link everything in the background, similar to how target roles function in Octopus.
Bob describes the experience: “When it comes to the actual step itself, the experience is very similar to any other step in your deployment process. It’s really the different configuration values and what the actual step does that’s going to be different, but in terms of editing or adding or doing anything along those lines, it’s the exact same experience.”
Argo CD and Octopus: Auto-discovery with annotations
Process Templates and Platform Hub
With Platform Hub, you can create Process Templates that standardize how your organization deploys to Argo CD. These templates can include pre-deployment steps, post-deployment actions, and compliance requirements.
Bob explains the compliance angle: “We can have policies that will say okay, if we’re deploying to Kubernetes you have to use Argo, you have to use these steps, you have to use this process template. So we’ll warn you at first if you’re not compliant, and then we’ll potentially block you from the deployment.”
This provides the standardization and compliance control that larger enterprises require, while maintaining flexibility.
Argo CD + Platform Hub: Enforce GitOps standards with Process Templates and Policies
Why Octopus chose Argo CD
Two compelling reasons drove the decision.
Argo CD dominance in the Kubernetes space
Argo CD is an incredibly popular tool for Kubernetes deployments. With approximately 60% market share, Argo CD is five times more popular than the second-ranked alternative.
As Steve notes: “When we look to the data, Argo was five times more popular than the second-place tool. And we cross-validated that with Linux Foundation data in terms of contributions and pull requests closed and all of those other stats as well.”
Octopus stewardship
Octopus Deploy isn’t just integrating with Argo; they’re actively stewarding it. Three of the top five committers to the Argo project work at Octopus Deploy, and the company maintains a dedicated open source team exclusively focused on Argo.
Bob emphasizes the commitment: “We are hugely invested in Argo and making sure that it is successful. And so not having Argo in Octopus kind of felt silly at this point.”
This isn’t a single-company effort, though. Multiple organizations collaborate on Argo’s development, which Bob sees as crucial: “That’s one of the big benefits of what a good open source should be. We don’t have one particular company that can dictate everything about it.”
Why Octopus integrated with Argo CD - our open source commitment
Limitations of Argo CD
While Argo CD is highly effective for GitOps synchronization, it has some limitations that become evident when scaling Argo use across an enterprise organization.
Lack of environmental progression: Argo CD doesn’t inherently recognize that your development, testing, and production applications represent different stages of the same release.
No release immutability: There is no built-in concept of a versioned release that can progress through various environments.
Limited RBAC for progression: Implementing role-based access control (RBAC) that specifies, for example, “this person can deploy to development and testing but not production,” can be challenging without resorting to complex Git-based workarounds.
Bob summarizes: “We can link those disparate applications together and then have a concept of a release that’s immutable and say, okay, this is the container for this release, this version. And that’s what I’m gonna deploy to dev. Okay. That looks good. And I just want to put it to test and so on and so forth.”
The open source sustainability question
Open source isn’t free: The hidden costs of dependencies and maintenance
The discussion addressed a vital issue in open source adoption: sustainability and ongoing maintenance.
Bob shared a previous experience: “That happened to us at Octopus, where one of the core packages that we relied on, I believe, was Nancy FX. They just stopped working on it. And so we had to go through and change out all the code that was using that to something that was provided by Microsoft.”
This reinforces the importance of Argo’s community and diversity of corporate supporters. Having the assurance that the project will be sustained and developed is critical for organizations that depend on open source platforms.
Steve adds perspective: “Open source can cause you to have to go and change your code in order to replace that open source project. Open source isn’t free because effectively, at any point, open source can cause you to have that cost.”
Useful links and resources
- Argo CD deployment with Octopus documentation
- Argo CD in Octopus deep dive demo video
- Octopus Platform Hub documentation
- Process Templates guide
- Argo CD official documentation
Check out the full episode below.
Happy deployments!
