When consolidating Argo CD instances into one control plane makes sense
Consolidation makes sense when several Argo CD installs have grown per team or per cluster, each with its own admin password, its own local users, its own repository definitions and its own idea of who may deploy where. Access reviews then mean checking every instance separately, and the same policy drifts between them. A single shared installation, with AppProjects that bound each team's repositories, destinations and cluster-scoped resources, and roles bound to SSO groups, gives one place to define and audit that access. It is less suitable when teams need hard isolation from each other's control plane, when clusters sit in networks that cannot reach a central instance, or when a single instance would become a shared failure point the organization is not prepared to operate.
The short answer on effort is that the work is mostly design and sequencing, not installation. Project boundaries per team, the mapping from identity provider groups to project roles, and an ordered cutover that prevents two Argo CD instances from reconciling the same resources usually take more time than standing up the new control plane. The total depends on how many applications, repositories and clusters are in scope and how many teams must agree on their boundaries. Ask any partner to size the inventory first, because that inventory drives the rest of the plan.
Argo CD is licensed under Apache-2.0 and has no paid edition from the project itself, so the cost of consolidation is implementation and operations effort inside your own infrastructure, not a license fee. Expect one-time costs for design, migration and testing, and recurring costs for upgrades, controller tuning and access reviews. When you request a quote, ask what is included in the inventory, how project and RBAC design is reviewed with your teams, how the cutover is rehearsed, and who owns the control plane after handover. The Argo CD projects guide is the natural starting point for your own team's review.
How a shared Argo CD tenancy model is designed
A multi-tenant Argo CD install rests on four decisions made before any Application moves. Each card names one decision, the risk it controls and what to confirm in your environment before migrating teams onto the shared control plane.
AppProjects per team
An AppProject is the boundary that limits what a team's Applications can do. Scope each project to the source repositories the team owns, the destination clusters and namespaces it may deploy into, and the cluster-scoped resources it may create. Without these limits, one team's Application can deploy into another team's namespace or request cluster-wide objects. Confirm the list of repositories and namespaces each team actually uses, and who approves changes to a project definition.
Project roles bound to SSO groups
Project roles map permissions such as sync or override to identity groups, so access follows the identity provider rather than hand-managed local accounts. Map each team's SSO group to the role in its project, and keep platform administrators in a separate group with cluster-level rights. Confirm the group names and claims your identity provider emits, because a mismatch here silently grants or denies access. Also confirm that the local admin account is disabled once SSO works.
Applications outside the control plane namespace
Applications in any namespace lets teams create their own Application objects without touching the control plane namespace where Argo CD runs. This reduces platform team tickets, but it also means every namespace allowed to hold Applications becomes part of the trust model. Decide which namespaces may host Applications, bind each one to a project, and restrict who can create objects there. Confirm this feature is enabled in your Argo CD version and that your team namespaces follow a naming convention the policy can match.
Whether controller sharding is needed
The application controller reconciles clusters and applications, and one controller replica can become the bottleneck as cluster count grows. Argo CD supports sharding the controller across replicas with the ARGOCD_CONTROLLER_REPLICAS setting and the legacy, round-robin or consistent-hashing methods. Decide based on measured controller load, not guesses. Confirm the number of clusters and Applications you will consolidate, the reconciliation delays your teams already see, and the node capacity available for extra replicas.
Which Argo CD objects and settings carry over and which need rework
This table maps each object and setting from the source Argo CD instances to its place in the shared installation, and marks which items move as-is and which need rework. Read the rows as a checklist for each source instance before cutover, and treat any row marked for rework as a task with an owner.
| Object or setting | In the shared instance | What to do | Watch for |
|---|---|---|---|
| Applications | Created in the shared control plane, in a namespace allowed by the target project | Re-create or re-home each Application under its team project, then remove it from the source instance | Applications cannot be in two instances at once without two controllers reconciling the same resources |
| Repository definitions | Kubernetes Secrets in the shared namespace, not entries in argocd-cm | Rework: convert each repository to a Secret and scope it to the projects that need it | Argo CD 3.0 removed repository configuration from argocd-cm, so copied ConfigMap entries will not load |
| Cluster registrations | Cluster Secrets referenced by destination in each project | Re-register each cluster, check credentials, and limit destinations per project | Clusters registered in two instances are a double-reconciliation risk during cutover |
| Local accounts | Retire most of them in favor of SSO groups; keep one break-glass path | Rework: move people to SSO and set admin.enabled to false once SSO is working | The built-in admin user is meant for initial setup only, so keep its use documented and rare |
| RBAC policies | Project roles bound to SSO groups, with policy rules in the shared RBAC configuration | Rework: rewrite each rule by team and group, then test with a non-admin account | Dex-based RBAC matches on the federated_claims.user_id claim in 3.0, so rules copied from older versions may not match |
| Update and delete permissions | Apply only to the application itself, not to its child resources | Rework: check that each team role still grants what its workflows need | Teams may find deletes or updates blocked after the move, which looks like a broken rollout |
| Logs access | Requires an explicit logs, get permission on the application | Rework: add the logs, get permission to each team role that reads pod logs | Without it, teams see the application but cannot read logs during an incident |
| Sync and tracking settings | Annotation-based resource tracking is the default in 3.0 | Verify sync options and tracking mode per Application before moving it | Mixed tracking methods across instances can cause resources to be claimed by the wrong Application |
| Plugin definitions in argocd-cm | Not carried over as-is; need sidecar Config Management Plugins | Separate work: write plugin.yaml, discovery rules and parameters, then test before cutover | Plugins in argocd-cm no longer work after 2.8, so they block a clean move until rebuilt |
Choosing between shared control plane, sharded controllers and remaining split
A single shared Argo CD installation fits an organization with a small number of clusters, a modest number of applications, and teams that can share one API server, one repo-server pool and one application controller. Consolidation here mostly means moving Applications into the shared instance, creating one AppProject per team, and binding each project's roles to SSO groups. The control plane stays simple to operate, but every team shares its failure domain, so a bad upgrade or an overloaded repo-server affects all of them at once.
- Operational footprint: One upgrade path, one set of backups and one place to review RBAC, which is often enough for a platform team of modest size.
- Project boundaries: Each AppProject limits source repositories, destinations and cluster-scoped resources, so teams cannot deploy into each other's namespaces by accident.
- Shared failure domain: A controller or repo-server problem slows every team, so confirm how much disruption each team can absorb.
- Credential exposure: Every registered cluster credential lives in one installation, which raises the value of that installation as a target.
- Scale ceiling: Confirm the cluster and application counts you expect with the Argo CD high availability guide before assuming one controller is enough.
Before choosing this shape, confirm the cluster count, application count and team count with your own inventory, and check that the version you plan to run is still supported under the Argo CD release process.
A shared installation with controller sharding fits many clusters or a large application count, where one application controller becomes the bottleneck. Argo CD can run multiple application controller replicas that divide clusters between them, configured through the ARGOCD_CONTROLLER_REPLICAS setting. The sharding method is a separate decision. The supported options are the legacy method, round-robin and consistent hashing, and the right choice depends on your version and cluster layout.
- Replica count:
ARGOCD_CONTROLLER_REPLICASsets how many controller shards run, and it should match the number of replicas you deploy. - Method selection: The legacy, round-robin and consistent-hashing methods distribute clusters differently, so test the distribution with your real cluster set before committing.
- Rebalancing: Adding or removing clusters can move work between shards, so plan for a period of reconciliation activity during changes.
- Node sizing: High availability manifests need at least three nodes because of pod anti-affinity rules, and shards add memory and CPU demand on the controller nodes.
- Project boundaries still apply: Sharding changes where controllers run, not who may deploy where, so AppProjects and SSO group roles remain the access model.
Confirm the sharding method and the controller settings against the Argo CD high availability guide for the exact version you will run, because option names and defaults can change between releases.
Keeping a per-cluster instance fits cases where a boundary is required by policy rather than by scale. Examples include a production cluster that must be administered separately from development clusters, an environment with its own change approval chain, or a segmented network where the Argo CD instance must sit inside that segment. In this shape, consolidation is limited to the instances that can share a boundary, and the rest stay separate with their own upgrades, backups and SSO configuration.
- Policy boundary: Document the specific control, such as a change-control rule or network segmentation requirement, that justifies each separate instance.
- Duplicated operations: Each retained instance needs its own upgrade cycle, backups, monitoring and RBAC review, which recurs for every instance.
- Consistent configuration: Keep shared settings, such as the SSO connector and project templates, in version control so that separate instances do not drift.
- Partial consolidation: Merging the instances that do share a boundary can reduce upgrades without crossing a policy line.
- Audit scope: Separate instances produce separate evidence trails, which can simplify or complicate assessments depending on how your auditors define scope.
Ask your security and compliance owners to name the policy behind each separate instance in writing. If no written requirement exists, treat the instance as a candidate for consolidation.
Documented Argo CD features used to consolidate
Consolidation rests on a handful of documented Argo CD mechanisms: projects that bound each team, identity that maps groups to roles, repository and admin settings, and controller sharding for scale. Argo CD has no general import tool for merging instances, so each card covers a mechanism you configure yourself and the checks to run before cutover.
AppProjects as team boundaries
An AppProject limits which source repositories, destination clusters and namespaces, and which cluster-scoped resources, a team's Applications may use. Each source instance's Applications should be mapped to one project per team before anything moves. Check that every project's allowed destinations exclude namespaces owned by other teams, and that cluster-scoped resource allow lists are as narrow as the team needs. An overly broad default project left in place can undo the boundary you planned.
Project roles bound to SSO groups
Project roles hold policies that grant actions on a project's Applications, and they can be bound to groups from your identity provider. This lets each team's role follow its directory group instead of a local account. Map every source instance's local users and per-team permissions to a group before cutover, and test that a member of one group cannot sync or delete another team's Applications.
Applications in any namespace
Applications can be created in namespaces other than the control plane's namespace, provided the instance is configured to watch them and the project allows that namespace. Teams can then manage their own Application objects without access to the Argo CD namespace. Confirm the namespaces Argo CD watches and the namespace limits in each project, since an Application outside the allowed set is rejected.
SSO through Dex or direct OIDC
Argo CD can authenticate through its bundled Dex, using connectors such as SAML, LDAP or GitHub, or directly through an existing OIDC provider. The choice decides which group claims reach Argo CD's RBAC. In recent releases Dex-based RBAC uses the federated_claims.user_id claim, so confirm the claim your provider sends before writing policies. Test with a non-admin account from each team.
Disabling the admin account
The built-in admin user is meant for initial setup. The user management documentation recommends setting admin.enabled to false once local users or SSO are configured. Do this only after you have verified that each team lead and a break-glass operator can sign in through the new path. Record who holds emergency access and where that procedure is stored.
Repository Secrets and controller sharding
Since Argo CD 3.0, repositories must be defined as Kubernetes Secrets rather than in argocd-cm, so every repository your merged instance needs must be recreated as a Secret. For scale, the application controller can be sharded with ARGOCD_CONTROLLER_REPLICAS and the legacy, round-robin or consistent-hashing methods. Choose the sharding method after measuring cluster count per replica, and confirm it against the high availability guide.
Cutover order for moving teams onto the shared control plane
This sequence moves teams from their existing Argo CD instances onto one shared installation in a controlled order, so every application has a single owner and a clear rollback path at each stage. It finishes with the admin account disabled and the source instances removed.
Inventory every instance, application, repository and cluster
Before anything moves, list each source Argo CD instance with its version, the Applications it manages, the Git repositories and Helm or Kustomize sources they read, the destination clusters, and the RBAC rules and local accounts defined in each argocd-cm and argocd-rbac-cm. Record which instance owns each Application so that no resource is claimed twice. The output is a single inventory that the platform team and each team lead have reviewed, with a named owner for every Application and cluster. Ask the source owners to confirm whether any Application relies on repository configuration in argocd-cm, because that format was removed in Argo CD 3.0 and must become Kubernetes Secrets before any move.
Build projects and SSO group roles on the target
On the shared instance, create one AppProject per team that restricts source repositories, destination namespaces and clusters, and cluster-scoped resources to what that team is allowed to deploy. Connect SSO through Dex or a direct OIDC provider, then map identity provider groups to project roles so that access follows group membership rather than local accounts. Confirm the mapping with a test user from each team who can see and sync only their own project. The step is complete when each team's project exists, each group resolves to the expected role, and a user outside a group is denied access to that project.
Register clusters and repositories on the shared instance
Register each destination cluster and each repository on the shared instance, keeping cluster and repository credentials in Kubernetes Secrets and scoping each one to the projects that need it. Use the same repository URLs and revision names as the source instances so that rendered manifests match what is already running. Check that the target can reach every cluster and that the repo-server can fetch every source. The output is a connection test per cluster and per repository, recorded in the inventory. Do not register a cluster in two instances with write access at the same time unless the cutover plan for that cluster says so.
Run the shared instance alongside a pilot team's applications
Choose one pilot team with a small number of Applications and non-critical workloads. Recreate their Applications on the shared instance in a project with auto-sync disabled, then compare the rendered manifests and live resource state against the source instance. Use this window to tune controller sharding if the number of clusters grows, using the documented ARGOCD_CONTROLLER_REPLICAS setting and sharding method for your version. Do not turn on automated sync for the copy until the source Application has been stopped for that team, because two controllers reconciling the same resources can cause flapping. The step is done when the pilot's diffs are empty and the team has signed off on the project's behavior.
Move one namespace or project at a time with a single owner
For each team, cut over one namespace or project at a time. First disable automated sync and pruning on the source Application, then remove it from the source instance without deleting the workloads (for example by removing the finalizer behavior you intend to keep, as your Argo CD version documents), then create the Application on the shared instance pointing to the same Git path, and enable sync there. Confirm that exactly one controller shows the Application as managed. Assign one named owner per resource so that changes go through the owning team's pull request. Move on to the next namespace only after the previous one is stable through at least one sync and a rollback test.
Disable the admin account once SSO works
After every team can sign in through SSO and the RBAC mapping has been verified for each group, set admin.enabled to false in the argocd-cm ConfigMap on the shared instance. Keep a break-glass procedure documented and tested in your own change process, since Argo CD's guidance is to use the built-in admin account only for initial setup. Confirm that a normal SSO login still works and that a non-admin user cannot reach other teams' projects. The output is a recorded configuration change with the approver and the verification results attached to it.
Decommission the source instances
When the inventory shows zero Applications on a source instance and every team has confirmed their workloads are healthy on the shared control plane, remove the source Argo CD installations. Before deletion, export each source's configuration and keep it under change control for the period your own retention policy requires. Remove the source instances' cluster registrations so that no stale instance retains write access to a destination cluster. Close the inventory with a final check that each cluster is reconciled by exactly one controller and that every Application has a documented owner. Confirm the backup of the shared instance's configuration is in place before closing the project.
Questions teams ask before consolidating Argo CD
What drives the cost of consolidating several Argo CD instances?
The cost follows the amount of configuration that has to move and be verified, not the number of tools involved. The main drivers are how many Argo CD instances are being merged, how many Applications and ApplicationSets each one holds, how many clusters are registered, how complex the SSO setup is, and how many custom plugins or Helm and Kustomize patterns the repo-server must render. Each added team with its own project boundaries and RBAC rules adds design and testing work. A written quote should itemize the inventory phase, the target design, the migration waves, the testing, and the handover. Ask which parts are one-time (design, migration, cutover) and which recur (upgrades, patching, reviews of new projects and roles).
How long does an Argo CD consolidation take?
Duration depends on the scope you agree in writing and on how many instances and clusters are involved, so no general timeline applies. An engagement with a few small instances and one identity provider is shorter than a merge of many per-cluster installs with plugins and separate Git hosts. Timing also depends on your change windows, the number of teams that must sign off on projects, and how many cutover waves you schedule. Most engagements are fixed-scope, so ask for the timeline as a line item in the quote, with the milestones and the client dependencies that could move it.
What do we need to provide before work starts?
Plan to provide four things before design begins. First, an inventory of every Argo CD instance, its version, its Applications, its registered clusters and repositories, and its plugins. Second, read access to the Git repositories that hold the manifests and Helm values. Third, an administrator on the identity provider who can create or change groups and OIDC or Dex connectors. Fourth, agreed change windows for each cluster and team, plus named owners who approve project and RBAC changes. Missing inventory is the most common reason a fixed-scope estimate changes, so ask the partner to list these inputs in the quote and to state what happens if they arrive late.
Can our internal platform team consolidate Argo CD on its own?
A capable platform team can do it internally if it has time, Kubernetes and Argo CD operating experience, and people who understand each team's delivery path. The work is mostly planning and verification: mapping each team to an AppProject, deciding which destinations and source repositories each project may use, binding project roles to SSO groups, and sequencing the cutover so two controllers never manage the same resources. The risk lies in the parts that are easy to get wrong under deadline pressure, such as RBAC defaults, repository credentials and sharding settings. Many organizations split the work: internal staff own the decisions and approvals, and an external team handles the build, testing and runbooks.
How does SSO complexity change the consolidation effort?
SSO adds effort when the instances use different authentication methods or when group membership is inconsistent across identity sources. Argo CD can use its bundled Dex with connectors such as SAML, LDAP and GitHub, or connect directly to an OIDC provider such as Okta, Auth0, Microsoft, Keycloak or Google Workspace. Each instance may have been wired differently, so the target design must choose one path and map every existing group to a project role. With Argo CD 3.0 and later, Dex-based RBAC matches on the federated_claims.user_id claim, so claim mapping must be checked during testing. Ask the partner to inventory identity connectors, group names and admin accounts, and to confirm that the built-in admin account will be disabled after SSO works.
Why does plugin usage raise the cost of merging instances?
Custom plugins make each instance a unique build, so they need testing before any Application moves. Plugins that depend on configuration in the argocd-cm ConfigMap no longer work after 2.8, and the migration to sidecar Config Management Plugins has to be planned and tested per plugin. Plugins also run on the repo-server, which executes Helm and Kustomize against repository content, so their file access and trust boundaries must be reviewed as part of the design. Ask for a plugin inventory with versions and owners, and for a quote line that covers rewriting, testing and rollback for each plugin.
What should a fixed-scope quote for consolidation include?
A useful quote states the scope in writing before work starts, names every instance, cluster and team in scope, and lists the deliverables with acceptance criteria. Look for the target architecture, the project and RBAC design, the SSO integration, the sharding and high availability settings if the controller load requires them, the cutover order, rollback steps, operator documentation and a handover session. The quote should separate one-time work from any retainer for upgrades, support or continuous testing. DeployOpen does not publish a price list, so ask for the quote to follow from the written scope and to state what changes would trigger a change request.
What goes wrong during an Argo CD cutover?
The most common failure is two controllers reconciling the same resources at once, which causes drift, churn and confusing sync state. Other frequent problems include projects that are too broad, so a team can deploy to clusters it should not reach, RBAC that grants more than intended because update and delete rules now apply to the Application itself and logs need an explicit permission, and sharding configured without matching the cluster count. Consolidation should move one set of Applications at a time, disable the old instance's automated sync before handover, and keep a tested way back. Ask the partner how each wave is verified and how long the old instances stay available for rollback.
What usually goes wrong when Argo CD instances are merged
Merging Argo CD instances fails in predictable places: during the parallel run, in project boundaries, in identity mapping, at the moment local access is removed, and in how repositories reach the repo-server. Each card names one of these risks, why it matters during consolidation, and the check that prevents it.
Two controllers reconciling the same resources
During the parallel run, the old and new Argo CD instances can both manage the same Applications and target resources. Each controller then reverts the other's changes, which shows up as sync loops and flapping objects. Before the first Application moves, confirm that each resource has exactly one owning instance, disable auto-sync on the source side for the moving set, and check that the destination Application points at the same repository path and revision before the source Application is removed.
Over-broad project destinations
A project that allows any destination namespace or cluster lets one team's Application deploy into another team's namespace. Merged instances often inherit wildcard destinations from the older setup, so the boundary exists on paper only. Review each AppProject's destinations, source repositories and cluster-scoped resource allowances during migration, and test a deliberate cross-team deploy in a non-production cluster to confirm it is rejected.
RBAC rules that break after the claim change
Argo CD 3.0 changed Dex-based RBAC to use the federated_claims.user_id claim, so group mappings written against older claims can stop matching users. Access may silently disappear for some teams or appear for the wrong ones. Before cutover, log in as a representative user from each team, verify their effective permissions with the CLI, and compare the policy against the upgrade notes.
Lost access when admin is disabled early
Disabling the built-in admin user before SSO has been tested in the consolidated instance can lock out every operator. The user management guidance expects admin to be disabled only after local users or SSO are configured. Keep the admin account enabled through the whole cutover, test SSO logins for each group in a separate browser session, and disable admin only after a second administrator has confirmed access.
Untrusted repositories reaching the repo-server
The repo-server runs Helm and Kustomize against repository content, so a repository that a team should not be able to use can execute build logic or read files outside its path. Shared access in a merged instance makes this easier to reach by accident. Limit which repositories each project may use, register repository credentials as Secrets scoped to their project, and review any Helm or Kustomize options that allow out-of-tree file access.
What the effort depends on in a consolidation
The biggest driver of duration is how many moving parts each source instance carries before anyone touches the target. Count the teams, clusters, and Applications per instance first, because every registered cluster, every repository, and every Application that has to be re-pointed adds verification work. Teams that already use AppProjects per team need a mapping exercise rather than a rebuild, while instances where everything lives in the default project need projects designed from scratch, including the source repository allow-lists and destination rules in each AppProject. Plugin and Helm usage matter as much as counts. Custom manifest plugins defined in argocd-cm, Helm releases installed outside Argo CD, and Kustomize overlays that reference files outside their directory each need a decision on how they will behave once they run on a shared repo-server. The repo-server runs Helm and Kustomize on repository content, so mixing repositories from several teams on one installation also changes the review you need before a repository is allowed in.
SSO and the version gap set the second half of the effort. Each source instance may authenticate through its own Dex connector or a direct OIDC provider, and the consolidated installation has to settle on one identity path and map groups to project roles before the first team moves. Plan the RBAC mapping against the user management documentation, and confirm how group claims arrive from your identity provider, since Argo CD 3.0 changed Dex-based RBAC to use the federated_claims.user_id claim. The version gap is often the largest unknown. Check every source instance against the current patch line on the Argo CD releases page, and read the upgrade notes for each minor version crossed before merging. Confirm with the release process documentation which minor versions still receive patches, because an instance that falls outside that window will need an upgrade before it can be consolidated, and that upgrade adds its own testing cycle.
What drives the cost and duration of a consolidation
This table compares the factors that move the effort of merging several Argo CD instances into one control plane, and the direction each one pushes the work. Read it to see which inputs to put in front of a partner or internal team before asking for a quote, and which costs are paid once versus carried every year.
| Driver | Effect on effort | One-time or recurring | How to keep it down |
|---|---|---|---|
| Number of source instances and clusters | More instances means more project, RBAC and cluster registration mapping to reconcile; effort rises with each source | One-time (design and migration) | Group instances by owning team and merge in waves instead of all at once |
| Number of applications and repositories | Each Application must be recreated or adopted without a sync gap; repository credentials move to Secrets in the target | One-time (migration), recurring if drift checks persist | Inventory first, retire unused Applications and repositories before migrating |
| SSO and group model maturity | Unclear or unmapped IdP groups force manual role design and extra testing of each team's access | One-time (design), recurring if group membership changes often | Define groups to project roles in a written matrix before cutover |
| Use of argocd-cm plugins | Plugins defined in argocd-cm must be rewritten as sidecar plugins before the target can run them | One-time (plugin rewrite and testing) | Count plugins early and migrate them on the source version first |
| Version spread across instances | Instances on different minor versions need upgrades to a common release, and upgrade notes may add breaking-change work | One-time (alignment), recurring (upgrade cadence) | Align all sources to one supported minor before consolidation; the project supports only the three most recent minors with patches |
| Controller sharding need | Many clusters may require sharding settings and tuning, adding design and load testing | One-time (setup), recurring (capacity review) | Size shards from measured controller load rather than assumptions |
| Cutover constraints such as change freezes | Freeze windows limit cutover dates and force parallel running, which lengthens the schedule | One-time (cutover) | Agree freeze calendars and a rollback window in writing before scoping |
| Client staffing and ownership | Fewer internal Argo CD operators means more handover, documentation and review time | One-time (handover), recurring (operations and upgrades) | Name owners per team and per cluster before the build starts |
How DeployOpen scopes and delivers a consolidation
DeployOpen plans and implements consolidation of several Argo CD instances into one control plane inside your own infrastructure. We start from a written scope that names the instances, clusters, teams and cutover order, then build, test, document and hand over the shared installation.
How we scope
- We inventory each existing Argo CD instance, its version, its clusters, repositories and Applications before proposing a target design.
- The written scope names which teams get a project, which SSO groups map to which roles, and which clusters move first.
- Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any cutover work starts.
- Ongoing support, upgrades and continuous testing after handover are available as a retainer, quoted separately from the build.
How we build
- We design AppProjects per team with source repository, destination and cluster-scoped resource restrictions agreed with each owner.
- We configure SSO group bindings and disable the built-in admin user once named access is verified through the new identity path.
- We size controller sharding for the cluster count and test the chosen sharding method in a staging installation first.
- We migrate Applications in batches and verify sync status, health and RBAC behavior against each team's test scenarios.
How we hand over
- You receive the target architecture, project and RBAC definitions, and the cutover runbook with rollback steps per batch.
- Repository, cluster and credential configuration is documented as Kubernetes objects so your team can review it in Git.
- We walk your platform and team leads through day-two tasks such as adding a project, a cluster or a shard.
- Test results, known gaps and open decisions are recorded in the handover pack so your team can own the installation.
How we support
- Support after handover covers patch and minor version planning against the upstream release cadence, with upgrade work scoped separately.
- We review project and RBAC changes on request so that new teams do not gain broader access than their scope allows.
- Retainers can include periodic testing of the shared installation, recovery drills and review of sharding as clusters are added.
- Your team confirms which support level, response expectations and change windows apply before the retainer starts.
