Argo CD vs Flux: which to choose

Argo CD or Flux: when each one is the right GitOps choice

A platform team choosing a Kubernetes GitOps controller should pick Argo CD when it wants one central controller with a web UI, SSO for many operators and a multi-cluster view from one place, and pick Flux when it wants Kubernetes RBAC as the control model, composable controllers and a workflow driven from Git and the CLI. Both are Apache-2.0 projects that graduated in the CNCF in 2022, so the decision rests on operating model rather than maturity. Argo CD runs as a Kubernetes controller with a web UI and integrates SSO over OIDC, OAuth2, LDAP and SAML 2.0 with its own RBAC. Its bundled Dex can front SAML, LDAP or GitHub, or the controller can connect directly to an existing OIDC provider such as Keycloak or Okta.

Argo CD fits when operators need to see application state, sync history and drift in one browser session, when many people across teams must sign in with corporate identity, and when a single pane must cover several clusters. The cost is a central component that needs its own hardening and access model. Confirm the Argo CD high availability guidance, which calls for at least three nodes because of pod anti-affinity rules, and check how admin.enabled will be set to false once SSO is in place. Argo CD 3.0 also moved repository definitions into Kubernetes Secrets, so review any existing argocd-cm configuration before you upgrade.

Flux fits when the platform team wants tenancy enforced by Kubernetes RBAC with impersonation, when it prefers small controllers it can assemble for each cluster, and when engineers are comfortable reviewing changes in Git and working from the command line. Its controllers cover Git, Helm and S3-compatible sources, Helm and Kustomize delivery, notifications and image automation. The decision turns on three questions: who will operate the tooling day to day, how many clusters and tenants you will run, and how much the organization depends on a web UI and SSO for operators. If the answers point to a shared UI with central identity, lean Argo CD. If they point to Git-driven, RBAC-first control, lean Flux, and confirm its installation options with the Flux installation guide for your environment.

Which platform fits which team scenario

This table maps common team scenarios to the GitOps tool that usually fits better and names the condition under which the other tool would be the stronger choice. Read each row against your own cluster count, operator access model and how much of the delivery workflow you want managed from a single web interface.

Scenario	Better fit	Reason and the condition that flips it
One cluster run by a small platform team	Flux	Controllers are installed and driven from Git with no required web UI, which suits a small team comfortable with the command line. Argo CD becomes the better choice if the team wants a visual view of application state for on-call engineers who do not work in Git daily.
Many application teams sharing clusters	Flux	Flux uses Kubernetes RBAC with impersonation, so each tenant's reconciliation runs with its own permissions and isolation follows existing cluster controls. Argo CD fits better if you want one central place to manage tenant projects, with its own RBAC and a shared UI for application teams.
Central platform team operating many clusters with SSO-based access for operators	Argo CD	Argo CD runs as a central controller, manages multiple clusters and integrates SSO over OIDC, OAuth2, LDAP and SAML 2.0 with RBAC, so operators sign in with corporate identity. Flux fits better when each cluster should run its own controllers and the team prefers per-cluster autonomy over a single control plane.
Teams that must keep all control in Git and Kubernetes RBAC	Flux	Flux is built from composable GitOps Toolkit controllers that rely on Kubernetes RBAC and a pull-based design with least-privilege access, so no separate permission model needs to be maintained. Argo CD suits this requirement too, but its own RBAC and central UI add a second authorization layer to review.
Teams that need a web UI and centralized operator visibility	Argo CD	Argo CD ships a web UI for viewing and operating applications across clusters. Flux is driven from manifests and the command line, so a team that needs a dashboard as a core workflow should confirm whether an add-on UI meets its audit and access requirements.
Teams that need Helm and Kustomize handled in a specific way	Flux	Flux's source, Kustomize and Helm controllers are separate components that support Helm, Kustomize and OCI artifacts as first-class sources. Argo CD fits when the team's Helm and Kustomize pattern depends on its application model; confirm how each handles your specific chart hooks, value overrides and rendering before deciding.
Teams that need strict separation of who can change deployment settings	Flux	Flux's per-tenant reconciliation under impersonated service accounts keeps each team's blast radius narrow. Argo CD fits better when operators need to approve or change deployments from a single audited interface; in that case, validate its project-level permissions during a pilot.
Teams with an existing Argo CD estate or Argo Workflows and Rollouts in use	Argo CD	Staying within one project family reduces integration work and keeps team skills aligned. Moving to Flux is the better choice only when a migration cost is justified by tenancy or Git-only requirements, and that cost should be scoped in writing before work begins.

How Argo CD and Flux are built, and what that means for operations

Argo CD and Flux both reconcile Kubernetes clusters from Git, but they divide the work differently. One is a central controller with a web UI and its own user model, the other is a set of composable controllers that lean on Kubernetes RBAC. The cards below show how each design shapes installation, upgrades, access control and failure handling.

Argo CD as a central controller

Argo CD runs as a Kubernetes controller with a web UI and manages multiple clusters from one installation. Users sign in through its bundled Dex, which offers SAML, LDAP and GitHub connectors, or directly through an existing OIDC provider such as Keycloak or Okta. Day-two work includes keeping admin.enabled set to false once SSO is working, and confirming that RBAC rules in the current release match the claims your identity provider sends, since Argo CD 3.0 changed the Dex claim used for RBAC. Ask who owns the central instance and its credentials.

Stateless core with disposable Redis

Argo CD keeps its state in Kubernetes objects, so the API server and repo server can be restarted or replaced without a database to restore. Redis is a cache that can be lost without losing configuration. The application controller is the component that can be sharded across replicas when the number of managed applications grows. For operations, this means backup focuses on the Kubernetes objects and Git history, and capacity planning focuses on the controller. Confirm the sharding approach with your clusters and application count before going to production.

Flux as separate GitOps Toolkit controllers

Flux is built from GitOps Toolkit controllers: the source controller for Git, Helm and S3-compatible sources, the kustomize controller, the helm controller, the notification controller and image automation controllers. Each runs as its own component. Operations teams can upgrade, scale or disable individual controllers, and can add only the ones a cluster needs. The trade-off is more moving parts to monitor, so check which controllers your platform actually runs and how their health is observed.

Pull-based reconciliation with least privilege

Flux uses a pull-based design in which controllers inside the cluster fetch desired state from Git and apply it, and Kubernetes RBAC with impersonation limits what each reconciliation can change. This keeps cluster credentials out of CI systems. For day-two work, review the service accounts each Kustomization or HelmRelease impersonates, because a broad account gives every tenant broad reach. Argo CD also pulls from Git, but its access is governed by its own RBAC layer, so the audit trail and the policy source differ between the two tools.

Flux installation paths

Flux can be installed with flux bootstrap, which is idempotent and commits the Flux configuration to the Git repository, with the Flux Terraform provider, or with the Flux Operator, which offers a declarative API for managing the Flux controllers. Its installation documentation also covers air-gapped installation. Choose the path that matches how your platform team already manages clusters, and confirm that the chosen path supports your upgrade process and your minimum Kubernetes patch version.

Argo CD high availability needs three nodes

The Argo CD high availability manifests require at least three nodes because of pod anti-affinity rules, and IPv6-only clusters are not supported. Teams that run a small test cluster may find that the HA manifests cannot schedule as written, so plan node count before selecting the installation type. Ask your platform team whether the production cluster can host three schedulable nodes that are separate failure domains, and whether the cluster uses IPv4 or dual-stack networking.

How multi-tenancy differs between a central UI and RBAC impersonation

Argo CD keeps tenancy inside one controller. Users sign in through the bundled Dex, which offers SAML, LDAP and GitHub connectors, or directly through an existing OIDC provider such as Okta, Keycloak or Microsoft. Argo CD then applies its own RBAC policies to decide what each user can see and change. Since Argo CD 3.0, Dex-based RBAC matches on the federated_claims.user_id claim, so any policy written against older claim handling needs review before the upgrade. The 2.14 to 3.0 change also limits update and delete RBAC to the application itself and requires an explicit logs, get permission to read logs. Test each role in a non-production cluster before you migrate policies.

Flux delegates tenancy to Kubernetes. Its controllers use Kubernetes RBAC with impersonation, so each reconciliation runs as an identity whose permissions are set by ordinary Role and RoleBinding objects. Platform administrators decide which identities exist and what they can reach, while tenant administrators work only inside the namespaces they were granted. Flux does not add a separate user directory or permission model on top of the cluster. Access reviews therefore use Kubernetes tooling and your cluster audit log. Confirm in your environment which identity each Flux controller impersonates for each tenant, and whether any tenant needs cluster-scoped permissions.

Which model is easier to audit depends on where your auditors look. A central controller with SSO suits organizations whose identity team already runs access reviews, because the questions of who signed in and which roles they hold are answered in one place, and tenants share a single view. Impersonation suits teams whose audit already centers on Kubernetes RBAC and cluster logs, because each change traces to a namespace-scoped role and a named identity. Before you choose, confirm whether the controller can export per-user change history for your auditors, and whether the Kubernetes objects both tools read and write fall inside your audit scope. The Argo CD user management documentation covers the settings to check.

Feature comparison: Argo CD and Flux

This table compares Argo CD and Flux on the features that most affect day-to-day GitOps operation, from licensing and CNCF status to UI, SSO, tenancy and Helm handling. Where the supplied research does not confirm a value for one platform, the cell tells you what to confirm in the project documentation before you decide.

Feature	Argo CD	Flux
License	Apache-2.0. No paid edition from the project itself.	Apache-2.0.
Governance and CNCF status	Part of the Argo project. Graduated in the CNCF on December 6, 2022, after Incubating on March 26, 2020.	Graduated in the CNCF on November 30, 2022.
Latest supplied release	Argo CD 3.5.5, published October 12, 2026, with 3.4.11 and 3.3.16 also maintained. Minor releases ship quarterly; the three most recent receive patches.	Flux 2.9.6, released October 1, 2026, after 2.9.5 on August 31, 2026.
Web UI	Included. Argo CD runs as a controller with a web UI.	No bundled web UI in the supplied facts. Confirm with the Flux documentation and any third-party dashboards you plan to use.
SSO integration	Built-in SSO over OIDC, OAuth2, LDAP and SAML 2.0 with RBAC, via bundled Dex or a direct OIDC provider.	Not covered by the supplied facts. Flux relies on Kubernetes RBAC with impersonation; confirm how your identity provider maps to cluster roles.
Multi-cluster management	Manages multiple clusters from one central controller.	Built from per-cluster GitOps Toolkit controllers. Confirm the recommended multi-cluster layout in the Flux documentation.
Multi-tenancy model	Central controller with its own RBAC. Update and delete permissions apply to the application itself; log access needs an explicit logs, get permission.	Multi-tenancy through Kubernetes RBAC impersonation, so each tenant acts with its own cluster permissions.
Helm handling	Supported through its application model. Confirm chart version and value handling in your target release.	Supported by the helm controller, with Helm repositories as sources.
Kustomize and OCI artifacts	Confirm current support for Kustomize options and OCI sources in the Argo CD documentation.	Supports Kustomize through the kustomize controller and OCI artifacts as sources.
Git provider integrations	Connects to Git repositories. Confirm the provider list in the Argo CD documentation.	Integrates with GitHub, GitLab and Bitbucket and supports multiple Git repositories.
Installation methods	Installed as Kubernetes manifests. Confirm Helm chart and HA manifest options for your environment.	Installed with flux bootstrap, the Flux Terraform provider or the Flux Operator.
Air-gapped installation documentation	Confirm air-gapped install steps in the Argo CD documentation before planning an isolated deployment.	Documentation covers air-gapped installation. Confirm the required image and artifact mirroring steps.

What each platform's license covers and what is paid for

Argo CD is licensed under the Apache License 2.0 (SPDX identifier Apache-2.0), and the project itself does not offer a paid edition. The web UI, SSO integration and multi-cluster management come under that same license, so the license fee is zero. The commercial questions that remain concern people: who patches the installation, who upgrades it and who responds when a sync fails in production.

Upstream patch window: Minor releases ship four times a year, and only the three most recent minor versions receive patch releases. Argo CD 3.5.5 was published October 12, 2026, alongside v3.4.11 and v3.3.16. Check the Argo CD release process before you plan your upgrade cycle.
Project maturity: Argo graduated in the CNCF on December 6, 2022, after entering at the Incubating level on March 26, 2020. Graduation signals governance and maturity, but it does not include a support contract.
Commercial support: Any support from a vendor is a separate agreement that recurs. Confirm in writing which Argo CD minor versions and Kubernetes versions the vendor covers, and whether SSO and RBAC configuration is in scope.
Upgrade effort: The 2.14 to 3.0 upgrade changed RBAC for update and delete actions and logs access, and it moved repository definitions into Kubernetes Secrets. That work is engineering time, whether or not anyone invoices it.

Ask any commercial provider for a written support matrix that lists each covered minor version, its end date and the exclusions.

What drives the running cost of each GitOps setup

Running either GitOps tool costs more than its license, which is free under Apache-2.0 for both. The cost comes from the Kubernetes capacity under it, the people who operate it, the upgrade work that recurs, and the integration you build and keep current. The cards below separate one-time setup from recurring work so you can ask vendors and partners for the right line items.

Kubernetes capacity under each tool

Argo CD's high availability manifests need at least three nodes because of pod anti-affinity rules, so a production Argo CD adds a fixed floor of control capacity before any application runs. Flux runs as a set of controllers in the cluster and has no UI tier, but its own footprint still needs sizing. Ask for the node count and sizing each design assumes, including whether the management cluster is separate from workload clusters. Note that IPv6-only clusters are not supported by Argo CD HA.

Staff skills for each model

Argo CD's operating model centers on its web UI, SSO setup and RBAC policy, so platform staff need to administer OIDC or Dex connectors and application permissions. Flux is driven by Kubernetes RBAC, impersonation and the CLI, which suits engineers already fluent in cluster manifests. Plan for the skill mix you already have. Retraining or hiring for the model you do not choose is a recurring cost that rarely appears in early quotes.

Upgrade cadence and patch windows

Argo CD ships a minor release four times a year, and only the three most recent minor versions receive patch releases, so every installation must move up at least once a year to stay supported. Flux publishes its own release cadence on its releases page, and each upgrade still needs Kubernetes version compatibility checks. Budget the recurring test and rollout cycle for each tool, and ask who performs it and how many environments it covers.

Support options and coverage

Argo CD and Flux are both community projects with no paid edition from the project itself, so vendor support is a separate purchase or a partner retainer. Confirm which versions a support contract covers, how long patches are guaranteed for your release, and who answers when a controller upgrade breaks a sync. Ask for the response scope in writing and whether on-call is included or billed separately.

Git and Kubernetes integration work

Both tools need repository credentials, webhook or polling setup, and rules for how application manifests, Helm charts and Kustomize overlays are organized. Argo CD 3.0 requires repositories to be defined as Kubernetes Secrets, and Flux expects a source resource per repository. Each new team, repository or cluster adds integration work that recurs as the estate grows. Ask who maintains the repository layout and how changes to it are reviewed.

One-time design versus recurring operations

The tenancy model, identity integration, bootstrap, and initial repository layout are largely one-time costs, but they lock in how much change later costs. Recurring costs include upgrades, patch cycles, drift and sync incident response, and on-call coverage for the platform. Ask a partner to separate the fixed-scope design and bootstrap work from any retainer for ongoing upgrades and support, and to state what each line covers.

Where GitOps implementations usually run long

For Argo CD, the effort concentrates in a few settings that are easy to miss in a quick install. Since Argo CD 3.0, repositories must be defined as Kubernetes Secrets, because the argocd-cm ConfigMap no longer holds repository configuration, so any repository list carried over from an older install needs rework. SSO is the second driver. Whether you connect through the bundled Dex or directly to an existing OIDC provider, the work is mapping identity claims to Argo CD RBAC roles, and Dex-based RBAC now keys on the federated_claims.user_id claim. Plan the group-to-role mapping on paper before testing. Finally, the built-in admin user should be disabled with admin.enabled set to false once SSO or local users work, and HA node layout needs at least three nodes for pod anti-affinity. Confirm that your cluster can satisfy that, and that it is not IPv6-only, before you commit to a topology.

For Flux, the effort sits in design decisions made at bootstrap. flux bootstrap is idempotent, but the Git repository layout you choose determines how tenants are isolated, how Kubernetes RBAC impersonation is applied to each tenant's controllers, and who can change which path. Check the installation guide's minimum Kubernetes patch versions (1.34.1 or later for Kubernetes 1.34, 1.35.0 for 1.35, and 1.36.0 for 1.36 and later) against the cluster version you are running, and do not plan production on an end-of-life Kubernetes release. Air-gapped installation is documented, but the mirroring of Flux controller images, Helm charts and OCI artifacts into your registry must be scoped and tested by the client team or its implementation partner. Confirm which installation method (bootstrap, Terraform provider or Flux Operator) your platform team will own. Before work starts, DeployOpen would set out in writing the target cluster list, the GitOps repository structure, the identity provider integration and role mapping, the tenant model, the Git hosting decision, the backup and upgrade approach, and the acceptance tests for each. The client team would supply cluster admin access for the agreed scope, identity provider details such as client registration and claim contents, the Git hosting platform and its access rules, and a named owner for each tenant. Ask for a written statement of which of these items is in scope before any quote is finalized.

Moving a GitOps setup from Argo CD to Flux, or back

This sequence moves desired state from one GitOps controller to the other without losing track of what runs in each cluster, and ends with a documented inventory of what was carried over and what was rebuilt. It applies in either direction, because the Git manifests are the portable part and the controller-specific layers are rebuilt on the other side.

Inventory applications, sources and access
The platform team lists every Argo CD Application, ApplicationSet and AppProject, the Git, Helm or OCI sources each one reads, the target clusters and namespaces, and the sync policy (manual or automated, pruning, self-heal). The same team records who holds Argo CD roles today, which SSO group maps to each role, and which local accounts exist. The output is a signed-off inventory file in Git. It is done when every live Argo CD application appears in the inventory with its source revision and owner, and nothing is left to memory.
Check annotation-based resource tracking
Before mapping anything, the platform team confirms how Argo CD tracks resources it manages. The Argo CD 2.14 to 3.0 upgrade notes say annotation-based resource tracking is the default, so each managed object carries annotations that Argo CD uses to claim ownership. Flux uses its own labels and inventory records, so leftover annotations can confuse ownership checks during cutover. The team lists these annotations on sample objects and plans to remove them when the old controller is retired. It is done when the team can show, for each namespace in scope, which tracking method is in use and which objects carry Argo CD markers.
Map Argo CD objects to Flux resources
Each Argo CD source becomes a Flux source object, such as a GitRepository, HelmRepository or OCIRepository. Each Application that applies Kustomize or plain manifests becomes a Kustomization, and each Helm-based Application becomes a HelmRelease. AppProjects do not map one to one: their source and destination limits are rebuilt as Flux tenant boundaries, using per-namespace service accounts that Kubernetes RBAC impersonation constrains. The mapping document lists each Argo CD object, its Flux equivalent, and any gap, such as a feature with no direct counterpart. It is done when a reviewer can trace every application to one Flux object or to a recorded gap.
Rebuild identity, RBAC and notifications
This step rebuilds what does not transfer as files. Argo CD's SSO through Dex or a direct OIDC provider, its RBAC policy and its notification setup have no direct Flux equivalent. Flux access is decided by Kubernetes RBAC, so the team writes role bindings for each tenant group, and it rebuilds alerts through the notification controller and any dashboards from scratch. The team also confirms how Argo CD's local admin account is disabled, since that setting does not carry over. It is done when a test user from each group can reach only the namespaces and actions the mapping allows, and alert routes fire in a test channel.
Run both controllers on a non-production cluster
On a non-production cluster, the team deploys the Flux manifests from the mapping alongside the existing Argo CD setup, with each Flux object pointed at a separate test path or namespace so the two controllers never write to the same resource. Drift and sync results are compared for a set of representative applications, including one Helm release and one with pruning enabled. The team confirms that Flux reconciles the same Git revisions and that the rendered objects match. It is done when the comparison shows identical rendered output for each test application and the discrepancies are logged and fixed.
Cut over one tenant at a time
On production, the team moves one tenant or namespace group at a time. For each group, it disables automated sync in Argo CD, suspends the matching Argo CD Application, enables the Flux Kustomization or HelmRelease for the same path, and checks that the Flux object reports the expected revision and health. Argo CD's tracking annotations are removed from the cut-over objects so the old controller cannot reclaim them. Only one controller is active for any resource at a time. It is done when each cut-over group reports a ready state in Flux, with no sync conflicts in either controller's logs.
Remove the old controller
Once every tenant has moved, the team deletes the remaining Argo CD Applications and AppProjects without cascading deletes, confirms that the workloads still run, then removes the Argo CD controllers, Redis and Dex deployments and their secrets. Repository credentials held in Argo CD Secrets are revoked or moved to Flux secrets where still needed. It is done when no Argo CD custom resources remain in the cluster, the workloads report healthy, and the inventory shows every application under Flux.
Decommission and document the result
The team archives the Argo CD configuration in Git for audit, records the final state of each tenant, the RBAC bindings in use, and any functionality that was dropped or replaced, and updates runbooks for on-call staff. Access reviews for the Flux setup are scheduled through the team's existing process. The output is a short decommission record that names the owner of the Flux configuration. It is done when the record is filed, the old runbooks are retired, and the on-call team has run one sync and one rollback drill on the new setup.

Questions buyers ask before choosing Argo CD or Flux

What does the implementation effort depend on, and can our team run it alone?

The effort depends mainly on how many clusters and teams the GitOps setup must serve, how much of your Git content already follows a clean layout, and how many Helm charts, Kustomize overlays and secrets workflows need migrating. Argo CD adds a web UI, SSO and RBAC to configure, while Flux relies on Kubernetes RBAC and bootstrapped controllers, so each tool shifts work to different people. Whether your team can run it alone depends on whether it already operates Kubernetes in production and has an owner for upgrades. Ask DeployOpen for a written scope that states which parts your staff keep after handover and which parts the engagement covers, and confirm upgrade and support ownership with the vendor's current release policy.

How long does a GitOps rollout take?

Duration is driven by the number of clusters, the state of existing manifests, the identity integration (for example, connecting Argo CD to an existing OIDC provider or Dex connector), and the change windows your organization requires. Teams with a shared Git hosting setup and a single cluster usually move faster than teams that must migrate Helm releases across several environments, and air-gapped networks add artifact mirroring work. DeployOpen does not publish durations. A fixed-scope agreement sets deliverables and timelines in writing before work starts, so ask for a timeline that lists each phase, its dependencies and the approvals it needs.

What does DeployOpen need from our side before work starts?

DeployOpen needs access that is scoped to the work: cluster access for the target Kubernetes environments, read and write access to the Git repositories that will hold the desired state, and a working identity provider for operator logins if you want SSO. It also needs a named technical contact who can approve changes, and agreed change windows for production clusters. Where Argo CD is chosen, the team should confirm the current Argo CD 3.0 requirements for repository definitions and Dex claims before access is granted. List these items in the written scope so procurement and security can approve each one.

Can we switch between Argo CD and Flux later without rebuilding our Git content?

Partly. Both tools read manifests from Git, so application manifests, Kustomize overlays and plain Kubernetes YAML can usually be reused. Helm handling, however, differs: each tool wraps Helm releases with its own custom resources, and the sync, health and rollback logic lives in those resources. Secrets references, notification rules, image automation and RBAC models also need rework because they are expressed in each tool's own objects. Ask for a written inventory of which parts of your repository depend on tool-specific resources, so the switching cost is visible before you commit.

Is the Argo CD web UI required for operators?

No. Argo CD ships a web UI, and it is the main reason many teams choose it, because operators can see sync status, drift and resource trees without a terminal. Operators can also work through the command line and the Kubernetes API, so the UI is a usability choice rather than a technical requirement. Flux has no bundled web UI in the GitOps Toolkit, so teams that want a visual view must confirm whether a separate dashboard fits their operating model. If your audit or on-call process depends on a browser view, make that requirement explicit in the scope.

How is air-gapped installation handled for each tool?

Air-gapped installation requires that container images, Helm charts, Git repositories and CRD bundles are mirrored into networks that cannot reach public registries. Flux's installation documentation covers air-gapped installation, and Flux can be installed with flux bootstrap, the Terraform provider or the Flux Operator. For Argo CD, confirm the mirroring steps and the high availability manifest requirements, including at least three nodes for pod anti-affinity, against the Argo CD documentation for your version. In both cases, the mirror process, its update cadence and the approval path for new images should appear in the written scope.

What should we ask for in a written scope before signing?

Ask for a document that names the clusters in scope, the Git repositories and their layout, the identity integration, the Helm and Kustomize workflows to migrate, and the air-gapped requirements if they apply. Require a list of deliverables, the acceptance criteria for each, the handover plan, and the change windows and approvals. Ask which Kubernetes versions and tool versions the design assumes and how upgrades will be handled after go-live. Confirm with each tool's vendor the support window for the versions you plan to run, and ask DeployOpen how any ongoing support or upgrade retainer would be scoped separately from the initial work.

How DeployOpen helps teams choose, implement or migrate GitOps

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Argo CD vs Flux, we start from the team's tenancy model, identity requirements and Kubernetes footprint, then build the GitOps layer your organization will actually run.

How we scope

Map which teams, clusters and namespaces the GitOps layer must serve before choosing a controller model
Record identity requirements, including whether SSO through an existing OIDC or SAML provider is needed
Agree a fixed written scope covering deliverables, Helm and Kustomize usage, and timelines before work starts

How we build

Install the chosen controller in your own clusters, using the install method your platform team prefers
Configure repository access, RBAC boundaries and Helm handling to match the tenancy model agreed in scope
Test drift detection, rollback and upgrade paths in a non-production environment before cutover

How we hand over

Document repository layout, RBAC roles, sync policies and the runbook for day-two operations
Walk your platform and security teams through access controls, audit logging and admin account handling
Deliver configuration and evidence in a form your auditors and internal reviewers can trace

How we support

Offer ongoing support, controller upgrades and continuous testing as a retainer, if your team needs it
Track upstream release and support windows so upgrades are planned against your own change calendar
Revisit tenancy, identity and multi-cluster decisions when your organization's scale or policy changes

Argo CD vs Flux