What an Argo CD implementation involves and who usually runs it
Argo CD carries no license fee. The Apache License 2.0 covers the software, and the project does not sell a paid edition, so the cost of an Argo CD rollout comes from design, build, integration and handover work. For a platform or security team, that work is the difference between a controller that runs in a lab and a delivery path that auditors, application teams and on-call engineers can rely on. The cost question is therefore really a question about how much of that work your own staff can absorb in the time you have. Most teams start looking at GitOps for a small set of reasons. Deployments are scripted kubectl or Helm runs launched from CI pipelines, with credentials held in the pipeline and little record of what is actually running in each cluster. Clusters multiply across regions, business units or environments, and each new one repeats the scripting work. Audit requirements then ask who changed what, when, and whether the running state matches an approved change. Argo CD answers those questions by reconciling clusters against Git, but only if repository layout, project boundaries, cluster registration and access controls are designed first. In-house delivery suits a team that already runs Kubernetes in production, has engineers comfortable with Helm, Kustomize and Kubernetes RBAC, and can staff the work without pulling people off product delivery. Many teams split the work instead. A partner or internal specialists handle the design decisions (repository structure, the project and RBAC model, SSO, the high availability install), while the platform team takes over day-to-day operation and application onboarding. The split keeps the decisions that are hard to reverse in front of experienced people, and it leaves operational ownership with the team that will still be there after the project closes. Before comparing options, confirm three things with your own team: which clusters will be onboarded first and what their network reachability looks like, who owns identity and group mapping, and who will approve changes to the Argo CD configuration itself. Those answers determine how many people the work needs and which skills are missing. They also make a fixed-scope quote easier to write, because the scope can name the clusters, identity provider and approval path instead of leaving them open.
What a fixed-scope Argo CD implementation includes
A written scope for Argo CD usually names a fixed set of work packages, each ending in a deliverable the client keeps. The cards below describe what each package covers, what the client receives, and what to check before signing, so the scope can be compared with an internal estimate line by line.
Repository layout and Git structure
This package decides how configuration is split across Git repositories or directories, how environments and clusters are separated, and where Helm or Kustomize sources live. The client receives the repository structure, a branching and promotion convention, and a short contributor guide written for their own teams. Check whether the scope names which repositories are created and who owns merge approval.
Argo CD install and high availability
The install covers the Argo CD components in the target cluster, configured from version-controlled manifests. A high availability option is scoped only where the cluster can host it, since the HA manifests need at least three nodes for pod anti-affinity and IPv6-only clusters are not supported. The client receives the install manifests, sizing notes and the HA decision record. Confirm node count and IP stack before quoting.
Projects and RBAC mappings
Argo CD projects define which repositories, destination clusters and namespaces an application team can use, and RBAC rules define what each role may do. The client receives project definitions and a documented RBAC mapping that lists each group, its role and its permitted actions. Ask how update and delete rights are scoped, because since Argo CD 2.14 to 3.0 those rights apply to the application itself and logs access needs an explicit permission.
Cluster onboarding
Onboarding registers each target cluster with Argo CD, sets the credentials Argo CD uses to reach it, and confirms that the least privileged service account works for each destination. Cost grows with the number of clusters, their network reachability and how many environments need separate credentials. The client receives a cluster inventory, the credential model and a test record per cluster. Ask who creates the cluster-side service accounts.
SSO integration
SSO connects Argo CD to an existing identity provider, either directly over OIDC or through the bundled Dex for connectors such as SAML, LDAP or GitHub. The work includes group mapping to RBAC roles and disabling the built-in admin user once SSO works. The client receives the identity configuration, a login test record and confirmation that admin.enabled is set to false. Confirm which identity provider is in use and who can approve its application registration.
ApplicationSets and runbooks
ApplicationSets generate applications from templates when a fleet has many clusters or tenants, which is where most templating effort sits. Runbooks document day-two operations, including the tested recovery procedure for rebuilding Argo CD from Git and Kubernetes objects. The client receives the ApplicationSet templates where they are in scope and written runbooks with a recorded recovery test. Ask whether runbooks cover upgrades, which are often a separate support item.
What drives Argo CD implementation cost and duration
This table lists the factors that most often change the effort of an Argo CD rollout, why each one matters, and one way to keep it contained. Read it before requesting a quote, because the same scope written with different answers to these questions can produce very different plans. The main takeaway is that identity, repository trust and fleet size usually shape the work more than the installation itself.
| Driver | Why it changes effort | How to keep it contained |
|---|---|---|
| Clusters and environments | Each cluster needs registration, network reachability, a scoped service account and its own health checks. Each added environment multiplies testing of promotion paths. | Start with the clusters in scope for the first release and add the rest in waves, each with a written onboarding checklist. |
| Applications and teams | More applications and owning teams mean more Projects, more RBAC mappings and more repository onboarding conversations. | Group applications by ownership into a small number of Projects and agree a standard application template before onboarding teams. |
| Identity provider complexity | Direct OIDC is usually a configuration exercise. Bundled Dex connectors for SAML, LDAP or GitHub add group mapping, claim checks and more failure modes to test. | Confirm the identity provider and group model early, and prefer one direct OIDC integration when the provider supports it. |
| Number and trust level of repositories | Each repository needs credentials, access rules and review. Repositories with untrusted content increase the work needed to limit what the repo-server can read or render. | Keep an allow-list of approved repositories and separate platform configuration from application source repositories. |
| Helm and Kustomize use | Rendering happens on repository content inside the repo-server. Charts with many dependencies, custom plugins or value overlays need more testing and version pinning. | Pin chart and Kustomize versions, limit plugins to those reviewed, and keep overlays simple in the first phase. |
| ApplicationSet fleet patterns | Generators that build many Applications from clusters, directories or pull requests reduce repetition but make a single template error affect the whole fleet. | Start with one generator for one fleet, test the generated output in a non-production cluster and review template changes like code. |
| High availability requirements | HA manifests need at least three nodes because of pod anti-affinity rules. Sharding, Redis handling and failover tests add setup and verification work. | Confirm node count and the availability target in writing, then test controller and repo-server failover before cutover. |
| Compliance evidence needs | Assessors may ask for records of access approvals, change history, role assignments and backup restores. Producing that evidence is extra design and reporting work. | Agree the control list and evidence format at the start so the controls are built to produce the records once. |
| Existing GitOps or deploy tooling | Running Flux, CI-driven kubectl or Helm scripts alongside Argo CD means adopting or retiring existing resources and keeping two sources of truth during transition. | Decide ownership of each existing resource before cutover and set a date to retire the old tool for each cluster. |
How an Argo CD rollout moves from design to handover
The sequence below moves a team from an inventory of how deployments work today to an Argo CD control plane that operators can run, recover and hand over. Each phase closes with a named output, so the client can see what has been accepted before the next phase begins.
Inventory current delivery and access
The partner and your platform team list every path that currently puts workloads into clusters: CI jobs running kubectl or Helm, existing GitOps tooling, manual changes and the identity sources people use today. The team also records cluster count, network reachability, Git hosting, secrets tooling and who approves production changes. The output is a delivery inventory with owners and open risks, reviewed and signed off by your team before design begins.
Design the target model
Using the inventory, the partner drafts the target design: repository layout (for example, separate application, environment and platform repositories), Argo CD project boundaries per team or environment, the RBAC model mapped to your existing groups, and the resource tracking method. The design is written as a short decision record for each choice, with the trade-offs named. Your architecture and security owners approve the record. The output is that approved design document and a repository skeleton.
Build in a non-production environment
The partner installs Argo CD in a non-production cluster, configures repository credentials as Kubernetes Secrets, creates the projects and RBAC policies from the design, and migrates a small set of representative applications. Where ApplicationSets are in scope, they are tested here against sample cluster and path generators. The output is a working non-production instance, a test log of sync, rollback and access checks, and a list of configuration changes made.
Onboard clusters and cut over SSO
Each production cluster is registered with Argo CD using the credentials and project scope from the design, and applications are moved in agreed waves with the previous delivery path kept available until each wave is verified. Identity is switched from local accounts to your identity provider, either through a direct OIDC connection or through bundled Dex, and the built-in admin user is disabled once SSO access is confirmed. The output is a cutover record per wave and a tested login and group-mapping matrix.
Test high availability and backup recovery
The partner deploys the high availability manifests on a cluster that meets their node requirements, then tests controller sharding, component restarts and a failed Redis cache, which Argo CD treats as disposable. Backup and restore of the Kubernetes objects Argo CD depends on is exercised in a rebuilt test cluster, with the restore time recorded from your own measurements. The output is a test report with each failure mode, its observed behavior and the recovery steps that were confirmed.
Hand over with runbooks
The partner delivers operational runbooks covering onboarding a new cluster, adding a team project, rotating repository credentials, responding to a failed sync, the upgrade procedure for the three supported minor versions and the recovery sequence tested earlier. Your operators run one supervised change themselves before the engagement closes. The output is the runbook set, the configuration and repository documentation, and a signed handover acceptance that names what remains with your team and what is covered by any support agreement.
What a fixed-scope Argo CD quote should spell out
DeployOpen does not publish a price list. A quote follows from the written scope, so the scope document has to be specific enough that two partners would price the same work. Start with the clusters and environments in scope: which clusters Argo CD will manage, whether it runs in a dedicated management cluster or inside each target cluster, and which environments (development, staging, production) receive the install. Next, name the identity provider and the connector type, either a direct OIDC connection or the bundled Dex with SAML, LDAP or GitHub. Then state the number of applications to onboard, the repository model (monorepo, one repository per team, or a mix), and how many repositories and credentials must be registered. Because Argo CD 3.0 requires repositories to be defined as Kubernetes Secrets, the quote should say who creates those Secrets and how they are rotated.
The quote should also settle the technical targets that change effort most. Name the high availability target. The HA manifests need at least three nodes because of pod anti-affinity rules, so confirm that the target clusters have that capacity and state whether any IPv6-only cluster is involved, since those are not supported. Say whether application controller sharding is expected. State whether ApplicationSets are included and, if so, which generators and how many templates are in scope, since each generator adds design and testing work. Acceptance tests should be listed as pass conditions: a sample application syncs from Git, a restricted user is denied a sync they should not run, SSO login works, the admin user is disabled with admin.enabled set to false, and a restore from backup completes. Finally, list the documentation set, such as the RBAC matrix, onboarding steps and recovery runbook.
Out-of-scope items belong in the quote as explicitly as the in-scope ones. Common exclusions are migration from Flux, Jenkins or scripted kubectl and Helm deploys, which is separate work, ongoing support and upgrade retainers, changes to the Git hosting platform, certificate authority or DNS, and the application code that Argo CD deploys. Then write the assumptions about client access. A typical list covers administrative access to the target clusters and Git hosts, permission for DeployOpen staff to register an OIDC application or coordinate with the identity team, named approvers for production changes, available non-production environments for testing, and the change windows for cutover. Each assumption that fails late in the project moves cost and schedule, so ask the quote to state what happens if an assumption does not hold.
Finally, ask for line items to be split by timing. One-time items include design, build, onboarding, acceptance testing, documentation and knowledge transfer. Recurring items are whatever ongoing support or upgrade retainer you choose, and they should appear separately with their own terms. The Argo CD project is released under Apache-2.0 and has no paid edition from the project itself, so the software carries no license fee, but the quote should not imply that running the platform is free. Hosting of the control plane, the cluster capacity behind the HA replicas, Git hosting, and the internal time your team spends on approvals and upgrades after go-live are separate costs. Under the project's release process, a minor version ships once every three months and only the three most recent minors receive patches, so ask which version will be installed and who applies each patch cycle.
Which Argo CD work teams keep in-house and which they outsource
This table compares seven areas of an Argo CD rollout by the skills each one needs and whether teams usually keep the work in-house or hand it to a partner. Read each row against your own staff: the more people who already run Argo CD and the cluster platform well, the more rows tend to stay internal. Most teams keep application-level design and day-two operations, and outsource the one-time security review and recovery test where an outside view adds the most.
| Work area | Skills needed | Usually in-house or outsourced |
|---|---|---|
| Repository and application design | Git branching, Helm or Kustomize layout, environment promotion rules | In-house when app teams already own their manifests; outsourced for an initial layout and standards |
| Kubernetes platform operations | Cluster administration, networking, storage, node upgrades, Argo CD HA install | In-house if a platform team exists; outsourced for the first HA build and cluster onboarding |
| RBAC and identity integration | Argo CD AppProjects, RBAC policy, OIDC or Dex configuration, group mapping | Often outsourced for the first setup, then owned in-house as group mappings change |
| Security review of repo-server and secrets handling | Threat modeling for Helm and Kustomize execution, repository allow-lists, Kubernetes secret management | Usually outsourced as an independent review, with fixes owned in-house |
| ApplicationSet templating | Generator design, template testing, cluster and repository naming conventions | Outsourced for the initial pattern; in-house for routine additions once the pattern is documented |
| Backup and recovery testing | Kubernetes object backup, restore procedures, rebuild drills from Git | Outsourced for the first documented test; scheduled drills kept in-house |
| Day-two operations | Monitoring, quarterly minor upgrade testing, incident response, access reviews | Usually in-house; a support retainer is an option for upgrade and patch coverage |
What goes wrong in Argo CD rollouts and how to prevent it
Most Argo CD rollout problems trace back to a few early decisions: who holds access, which repositories the repo-server may render, how the cluster is sized, and whether state can be recovered. The cards below describe recurring failure modes and one prevention step for each. Use them as checks in the implementation plan and as items to confirm in any fixed-scope quote.
Broad RBAC and an enabled admin user
The user management documentation recommends using the built-in admin user only for initial setup and disabling it with admin.enabled set to false once local users or SSO are configured. Leaving it on gives anyone who holds that password an account that bypasses your identity provider. Check the RBAC policy for wildcard grants, and confirm each team's role covers only its own projects. Plan SSO and role mapping as a named phase in the quote.
Untrusted repository content
The security documentation notes that the repo-server runs Helm and Kustomize on repository content, so a repository you do not control can influence what gets rendered and applied. Treat write access to a repository as a deployment privilege. Limit which repositories each project may use through an allow-list, and review Helm charts and Kustomize overlays that reference files outside their own directory. Ask the partner to scope this in the hardening work.
HA on a cluster that cannot host it
The high availability documentation says HA manifests need at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported. A cluster that falls short can complete an install yet fail to schedule the replicas that give HA its value. Confirm node count, failure domains and IP stack before choosing the HA install, and make the cluster check part of planning. If the cluster does not qualify, the plan should say so before budget is committed.
Resource tracking changes after upgrade
The 2.14 to 3.0 upgrade notes make annotation-based resource tracking the default, so applications whose tracking settings were never reviewed can show drift, ownership changes or unexpected pruning after the move. Inventory which applications depend on the existing tracking behavior before upgrading. Run the upgrade against a staging copy of a representative set of applications, and compare sync status and pruning results. Include that test in the upgrade scope.
Repositories defined in the wrong place
Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap, so repositories must be defined as Kubernetes Secrets. Repository entries left in the old location do not carry over, and applications that depend on them stop syncing. Inventory every repository definition, recreate each one as a Secret, and confirm every affected application syncs before removing the old entries. Ask whether the quote includes this step for existing installs.
No tested recovery of Argo CD state
Argo CD keeps its state in Kubernetes objects and treats Redis as a disposable cache, so recovery depends on backing up those objects alongside the Git repositories and secrets that define them. A backup that has never been restored is an assumption, not a recovery plan. Ask for a restore test into a separate cluster that confirms applications reconcile, and record the results in the handover documentation.
How the Argo CD scope changes by starting point
Teams that deploy with kubectl or Helm from CI pipelines usually have the widest scope. Deployment logic lives in pipeline code, so the first large task is writing the desired state into Git. Controller installation is often the smallest part of the work. Most of the effort moves into repository design, ownership of each path and the mapping of today's pipeline permissions to Argo CD projects and roles.
The work usually concentrates in these areas:
- Desired state extraction: Scripts often hold ordering logic, environment values and secret references that must be expressed as declarative manifests.
- Repository layout: Decide early whether to use one repository per team, per environment or a shared structure, and who approves changes to each path.
- Projects and RBAC: Map existing service accounts and pipeline permissions to Argo CD projects before any application is created.
- Secrets handling: Pipeline-injected credentials need a model that keeps secret values out of Git, and the choice should match your existing secrets standard.
- Helm and Kustomize inputs: Confirm which charts and overlays render today and pin their versions so reconciliation results are repeatable.
Check how many pipelines write to each cluster and whether any step relies on imperative commands that cannot be expressed in Git. Those steps decide how much of the plan is design work before any build work starts.
Replacing an existing GitOps tool changes the work from installation to ownership of live objects. Resources that another controller already reconciles must move to Argo CD without being deleted and recreated during cutover. The detailed adoption steps belong to the migration topic, but the scope decisions below must be made in the plan, because they change the timeline and the quote.
The decisions that move earlier are these:
- Ownership during overlap: Decide which controller owns each resource at each stage, since two reconcilers acting on one object cause churn and drift reports.
- Tracking method: Annotation-based resource tracking is the default in the 2.14 to 3.0 upgrade line, so confirm how labels or annotations left by the old tool will be handled.
- Repository restructuring: Paths built for the old tool's Kustomization or HelmRelease objects usually need remapping into Argo CD Applications or ApplicationSets.
- Cutover sequence: Agree the order of clusters and namespaces, and which teams are frozen from manifest changes during each window.
- Rollback path: Keep the previous controller's definitions available until the new state is verified in each target.
Ask for the cutover order and the rollback steps in writing before you agree a fixed scope, because both determine how much testing and coordination the quote must include.
A single managed Kubernetes cluster keeps the Argo CD control plane, the workloads and their failure domain in one place. Effort concentrates on the install profile, the access model and the upgrade routine for one installation. Many clusters shift the important decisions to cluster registration, network reachability, credential storage and the blast radius of a single misconfiguration.
The main differences are these:
- Install profile: A single cluster can start with the standard install or the high availability manifests. The HA manifests need at least three nodes because of pod anti-affinity rules, so confirm node capacity before choosing.
- Central or per-cluster control plane: A central instance manages many targets and needs a clear reachability model. Per-cluster instances multiply upgrades, SSO configuration and backups.
- Cluster credentials: Each registered cluster adds credentials that must be stored and rotated. Argo CD redacts these from API responses and logs, but the storage and rotation process is still your responsibility.
- ApplicationSet design: Many clusters usually call for generators that create applications from a cluster list or directory structure, which adds design and test effort.
- Controller sharding: As the number of managed applications grows, the application controller can be sharded across replicas, which changes sizing and monitoring.
Before quoting, confirm how many clusters are in scope now and in the next planning cycle, because cluster count drives the ApplicationSet design and the sizing of the control plane.
In a connected environment, Argo CD pulls manifests from Git providers and charts or images from public registries. In an air-gapped network, the repositories, Helm charts, container images and any remote Kustomize bases must be mirrored inside the boundary before the first sync. That mirroring work becomes a standing process, not a one-time copy, because every new Argo CD release and every application update must be transferred again.
The following areas change in scope:
- Repository mirroring: Internal Git servers must hold every repository Argo CD reads, and the mirror must be updated under a documented transfer process.
- Image and chart mirroring: Charts, images and their dependencies must be complete. Missing transitive images are a common cause of failed first syncs.
- Repository definitions: Since Argo CD 3.0, repositories are defined as Kubernetes Secrets rather than in the argocd-cm ConfigMap, so the internal URLs and credentials are set in those Secrets.
- Upgrade transfers: Each quarterly minor release and each patch release needs its images and manifests moved through the approved channel and tested inside the boundary.
- Repo-server risk: The repo-server runs Helm and Kustomize on repository content, so the internal repositories must be controlled and their contents reviewed.
Confirm the transfer method, the approval path for imports and who owns the mirror before the plan is finalized, because these decide the recurring effort and the security review.
In regulated environments, the scope grows from working deployments to evidence that controls operated as described. Argo CD provides relevant capabilities, such as SSO integration, Git-based change history and TLS between components, but DeployOpen prepares systems, controls and evidence for an assessment without issuing audit reports or certifications. Independent auditors and certification bodies make that determination, so the evidence plan should be agreed with your assessor early.
The work that moves earlier includes:
- Identity and admin access: Configure SSO and disable the built-in admin user with admin.enabled set to false once local or SSO users are in place, and keep records of that change.
- Change evidence: Git history can show who approved each manifest change, so define branch protection, review rules and the link between tickets and commits.
- Repository and source controls: Restrict which repositories and chart sources Argo CD can read, and document the reasons for each allowed source.
- Audit trail: Confirm how Kubernetes events and Argo CD logs are retained, who can read them, and how they are exported for review.
- Supported versions: Only the three most recent minor versions receive patch releases, so the upgrade cadence must be part of the control evidence.
Ask your assessor which artifacts they accept and in what format before the scope is written, because that list determines the evidence work included in a fixed-scope quote.
What your team must provide before an Argo CD project starts
Before design starts, your team must give us working access to the clusters Argo CD will manage and the accounts that let it install and read configuration. For the install, provide Kubernetes access with an administrator role that reaches cluster scope on the host cluster and on each target cluster. Installation creates custom resource definitions, cluster-level role bindings and namespaces, so a role limited to one namespace will fail partway through. Confirm which clusters are in scope, who holds the kubeconfig for each, and whether the install runs through your pipeline or is applied by hand. On the source side, name an owner on the Git hosting platform who can create the repositories, deploy keys or access tokens, and branch protection rules that Argo CD will read from. Identity is the second dependency. Name an administrator for your identity provider who can register an OIDC application for Argo CD, set the redirect URLs, and release the group claims that will map to Argo CD roles. Decide before design whether Argo CD connects directly to an existing OIDC provider or through the bundled Dex, because that choice changes the registration steps. Plan to keep the built-in admin user only for initial setup, since the user management guidance recommends disabling it once SSO or local users are working. Also decide whether high availability is required. The HA manifests need at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported. If your clusters cannot meet that, record a single-replica install as an accepted risk and confirm who signs it off. Name owners before design, not during the build. You need a platform owner who accepts responsibility for installation and upgrades, a named owner for each application team, and a named owner for each Argo CD project that groups applications and destinations. Write down the change approval rules: which changes to Git-managed configuration need a second reviewer, who may merge to the production path, and whether production sync is automatic or gated by an approver. Then choose the secrets management approach. Since Argo CD 3.0, repository credentials must be defined as Kubernetes Secrets, so decide whether secret values come from an external secret store, are encrypted before they reach Git, or stay outside Git entirely. Finally, set a backup target and retention period for the Kubernetes objects that hold Argo CD configuration, and confirm that the backups can be restored into a clean cluster. Provide a non-production cluster that is close enough to production to test sync behavior, RBAC and upgrades, along with a draft of the repository layout you intend to use. Choose the Argo CD minor version to target. The release process supports only the three most recent minor versions with patch releases, so confirm the current version list on the project's release page before you commit to one. Ask for a written scope that lists these inputs, the owner for each, and the date each decision must close. A quote is only as firm as its assumptions, so the scope should state which items your team supplies and which items DeployOpen configures. Confirm every supplied item in writing before design begins, because gaps at this stage carry directly into the design.
Argo CD implementation questions buyers ask before hiring help
How much does an Argo CD implementation cost?
Argo CD is released under the Apache-2.0 license and the project has no paid edition, so there is no software license line in the budget. The cost is labor for design, build and handover, the infrastructure that runs the Argo CD control plane and the clusters it manages, and any support or upgrade agreement you choose to buy. Labor is the largest variable and rises with cluster count, identity integration complexity, repository model and the number of teams onboarded. Design and build work is one-time, while upgrades, monitoring and support recur. DeployOpen's engagements are fixed-scope, so a quote follows from a written scope that lists phases, deliverables and timelines. When you compare bids, ask each provider to separate the implementation fee, any infrastructure you pay directly to cloud or hardware vendors, and recurring support.
How long does an Argo CD rollout take to complete?
The timeline is set in the phase plan of the written scope and depends on three main drivers. The first is cluster count, since each cluster needs registration, access and onboarding checks. The second is identity integration: connecting Argo CD directly to an OIDC provider is usually simpler than bridging SAML, LDAP or GitHub through the bundled Dex. The third is the repository model, including how many repositories exist, how they are laid out and whether existing Kubernetes resources must be adopted or migrated. Ask for each phase's entry and exit criteria, the dates on which you must supply access or approvals, and the change windows that gate production cutover. Any duration quoted before the scope is agreed should be treated as a planning assumption to confirm, not a commitment.
What access and people does an Argo CD engagement require from us?
The engagement needs four kinds of input from your side. First, cluster access: administrative credentials for each target cluster during the build, with a plan for narrowing them afterward. Second, Git access to the repositories that will hold application and platform manifests, including write access for the layout changes the design requires. Third, identity provider administration, so an OIDC client or Dex connector can be registered and groups can be mapped to Argo CD roles. Fourth, named owners: a platform lead who approves design decisions, a security reviewer who signs off on RBAC and secrets handling, and an operations contact who receives handover. You will also need a nonproduction cluster for testing. Confirm the owner for each item before the written scope is signed, because delays in access are a common cause of schedule slips.
Can our own platform team install and run Argo CD without a partner?
Yes, if your team already runs Kubernetes operations and understands Kubernetes RBAC. The team should make the decisions listed in the readiness section before installing anything: repository layout, project boundaries, the SSO model, the high availability scope and how repository credentials will be stored. Argo CD 3.0 requires repositories to be defined as Kubernetes Secrets, so that choice affects every later change. The team also needs an upgrade routine, because the project patches only the three most recent minor versions and ships a minor release roughly every three months. A partner is most useful when the team lacks time or capacity for the build, when identity integration spans several providers, or when the rollout must meet a fixed date. Compare your team's capacity against the phase plan before deciding.
When do ApplicationSets and high availability change the scope of an Argo CD rollout?
Each adds scope for different reasons. ApplicationSets add scope when the number of generated Applications is large, when clusters or teams are created dynamically, or when templated Applications must follow a pattern. Each template and generator needs design, tests and RBAC checks, because a change to a template can affect many Applications at once. High availability adds scope through the number of environments that must survive a node or component failure, the sharding of the application controller across replicas, and the recovery plan for Kubernetes objects that hold Argo CD's state. Ask the provider to list which ApplicationSets and environments are in the fixed scope and which are optional phases, and to state what the high availability work includes, such as testing failover and documenting the restore procedure.
Does high availability for Argo CD require a minimum number of nodes?
Yes. The Argo CD high availability documentation says the HA manifests need at least three nodes because they use pod anti-affinity rules to spread replicas, so a two-node cluster cannot run the HA install as documented. The documentation also states that IPv6-only clusters are not supported. Argo CD keeps its data in Kubernetes objects, and Redis is a disposable cache, so losing Redis does not mean losing configuration. The application controller can be sharded across replicas to spread load across clusters. Before planning the work, confirm your node count, network model and the storage and backup approach for the Kubernetes objects that hold Argo CD's configuration. Those answers determine how much of the high availability scope applies to your environment.
What should a fixed-scope Argo CD implementation quote include?
A usable quote lists the scope in writing: the clusters, repositories, identity providers and Argo CD projects covered, plus any ApplicationSets and high availability work. It should break the engagement into phases with deliverables, acceptance criteria and dates, and state which dates depend on your access or approvals. Ask for named assumptions, such as the number of environments and the identity provider version, and named exclusions, such as migration from another GitOps tool or ongoing support. Documentation and handover should be listed as deliverables with their contents. Recurring items, including upgrades and support, should appear as separate options with their own scope. Any figure in the quote should trace to the scope, so you can see what changes the price if the scope changes.
How DeployOpen scopes, delivers and hands over Argo CD work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and Argo CD work follows the same method. Engagements are fixed-scope, so the phases, deliverables and timelines for your rollout are agreed in writing before any build work starts.
How we scope
- Inventory the clusters, Git hosts, identity provider and existing deploy tooling that Argo CD must work with.
- Agree the repository layout, Argo CD project boundaries and the RBAC model in writing before build starts.
- Confirm which clusters onboard in each phase and whether ApplicationSets are in or out of scope.
How we build
- Install Argo CD in the high availability layout only if your clusters have the three or more nodes the HA documentation requires.
- Connect SSO directly to your OIDC provider or through bundled Dex, and test group-to-role mapping before cutover.
- Test RBAC, repository access and sync behavior in a non-production cluster, then document the results for your reviewers.
How we hand over
- Deliver runbooks for onboarding clusters, adding repositories, rotating credentials and disabling the admin user.
- Document the Argo CD version, configuration and every deviation from the agreed scope in the handover pack.
- Walk your platform and security teams through the setup and record who owns each operational task afterward.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if you want DeployOpen to stay on the release path.
- Plan upgrades against the three most recent minor versions that receive patch releases, with breaking changes tested first.
- Confirm in the support terms who handles quarterly minor releases, patch rollouts and RBAC or tracking changes.
