Moving kubectl apply steps in GitHub Actions or GitLab CI to Argo CD

Moving kubectl apply steps in GitHub Actions or GitLab CI to Argo CD: what the move involves

The move replaces push deploys with a pull model. Today a CI job holds cluster credentials and runs kubectl apply or helm upgrade against the cluster. After the move, the job's last step commits a change to a config repository, and Argo CD pulls that commit and applies it from inside the cluster. The effort depends on how many pipelines deploy, how many environments each one targets, and how many Helm charts or Kustomize overlays sit behind each step. A team with one service and two environments faces a very different job from a team with dozens of services promoted through staging and production.

No documented converter turns pipeline YAML into Argo CD objects, so this is a design and rewrite exercise, not a mechanical translation. Each kubectl apply step has to be traced to the manifests it applies, each helm upgrade step to its chart, release name, values files and any hooks, and each secret or variable the job injects to a source that Argo CD can reach safely. Those findings decide the config repository layout, which Applications exist, and which pipeline steps disappear. Ask any partner to inventory every deploy job and its cluster credentials before quoting, because that inventory sets the scope more than the number of repositories does.

Most of the cost sits in design and cutover, and most of it is one-time. Recurring costs come from keeping the config repository and Argo CD upgraded, and from the CI minutes that still run builds. Confirm your own CI billing position before you plan, because GitHub has changed its Actions pricing and billing plans in 2025 and 2026, and the GitHub Actions billing documentation sets out the current rates and included minutes that apply to your plan. Ask the partner to state which pipelines, environments and charts are in scope, how cutover is staged, and who owns the config repository afterward.

Which CI deploy steps map cleanly to Argo CD and which do not

This table compares each deploy step in a GitHub Actions or GitLab CI pipeline with its Argo CD equivalent, or marks it as a step that stays in CI. Read the migration note in each row first, since it states what changes in the repository, the pipeline and the cluster credentials.

Pipeline step	Argo CD equivalent	Migration note
kubectl apply of manifests	Application syncing a path in the config repository	Commit the manifests to the config repository and let Argo CD apply them. Remove the cluster credentials from CI once no job applies directly.
kubectl set image	Pull request that changes the image tag in the config repository	Image tags become a versioned file change reviewed like any other. Automated tag updates need a separate tool or CI job that opens the pull request.
helm upgrade --install	Application using a Helm source with values files in Git	Move values into the config repository. Release history moves from Helm records to Git history, so confirm rollback steps with the team before cutover.
kubectl rollout status	Application health and sync status in Argo CD	Argo CD reports Progressing and Healthy states. Pipelines that wait on rollout need a status check or a notification instead of a blocking command.
Environment secrets in CI	Secrets managed on the destination cluster, not in the pipeline	Pipeline secrets that hold cluster credentials are retired. Application secrets need a separate design, since Argo CD must not store them in Git in plain form.
Manual approval job	Pull request approval on the promotion branch or path	Approvals move to repository rules such as required reviewers on the environment directory. Confirm who may merge to production paths.
Post-deploy smoke tests	Remains in CI, triggered after Argo CD reports Healthy	Smoke tests stay as CI jobs. Trigger them from an Argo CD notification or poll application status, since Argo CD does not run test scripts.
Ad hoc scripts that patch live objects	No equivalent	Live patches conflict with Git as the source of truth. Convert each patch into a committed change or retire it, because Argo CD may revert it.
Pipeline-only variables used in manifests	No equivalent unless moved into Git or Helm values	Variables that exist only in the runner must be written into committed values or resolved by a plugin. Undocumented variables are the usual cause of drift.
Deploy jobs needing runner tools such as custom kubectl or cloud CLI	No equivalent in the cluster	Tools used only to authenticate or fetch config stop being needed. Check whether any step depends on a runner-installed binary before removing the runner.

How to lay out the config repository for GitOps promotion

Separate the application source repository from a config repository that holds only the desired state of each environment. CI builds and tests the image, then opens a pull request against the config repository that changes an image tag, typically in a Kustomize overlay or a Helm values file. Argo CD reads that config repository, not the CI system, so the pull request becomes the promotion record. Promotion from staging to production should also be a pull request, which moves approval into the same review tool your engineers already use. Without this split, the CI runner still needs cluster credentials to deploy, which defeats the purpose of the migration.

Choose between a directory per environment and a branch per environment with the operational cost in mind. Directories keep every environment visible in one checkout, let a single pull request show the difference between staging and production, and map cleanly to Argo CD Applications that point at different paths. Branches isolate environments more strictly, but they make comparison harder, invite drift through manual merges, and complicate shared base changes. Most teams that reach a Kustomize or Helm structure find directories easier to review. Helm values files and Kustomize overlays fit either model: a shared base or chart version lives once, and each environment overrides only image tags, replica counts and endpoints. Confirm your choice against the Argo CD documentation for your version before you commit the layout.

Treat the config repository as trusted input. The Argo CD repo-server runs Helm and Kustomize against repository content, so a malicious change can influence what runs in the cluster or attempt to read files outside the intended tree. Protect the default branch with required reviews, restrict who can merge to production paths, and keep CI tokens that open promotion pull requests scoped to that one repository. Review chart and Kustomize changes with the same care as code. Confirm with your Argo CD version how out-of-tree file access and repository credentials are configured, and record which repositories Argo CD is allowed to read.

The migration sequence: inventory, pilot, parallel run, cutover and decommission

The sequence moves one deployment path at a time from CI-held cluster credentials to Argo CD pulling from Git, so each environment has exactly one system writing its resources at any moment. Each step ends with a check you can verify before moving on.

Inventory pipelines, credentials and target resources
Your platform team lists every workflow or pipeline that touches a cluster, including the kubectl apply and helm upgrade steps, the kubeconfig or token secrets they read, the namespaces and resource kinds they write, and any jobs that run kubectl patch, scale or delete outside the normal deploy path. Note which environments each job targets and who can change the pipeline definition. The output is a table that maps each job to its cluster, namespace, credential and owner. The step is done when someone outside the team that wrote the pipelines can read the table and find no deploy path that is missing from it.
Choose a low-risk pilot service
Pick one service in a non-production environment that has a stable manifest set, a single owning team and a clear rollback path. Avoid services that share namespaces with others, depend on hand-applied resources or run database migrations as part of the deploy. Agree with the owning team which pipeline job will be retired first and who signs off the result. The output is a written pilot decision naming the service, the environment, the owner and the exit criteria. The step is done when the owner has accepted those criteria in writing.
Build the config repository and Applications for the pilot
Create the config repository layout for the pilot, with a base directory for shared manifests and one overlay per environment, following the structure your team chose for promotion by pull request. Define an Argo CD Application for the pilot in the target environment, with the repository registered as a Kubernetes Secret, the destination cluster and namespace set, and automated sync turned off at first so the first sync is reviewed by hand. Compare the rendered output against what the pipeline currently applies. The output is an Application that shows a clean diff with no unexpected deletions. The step is done when the diff is explained line by line and accepted by the owning team.
Run the parallel period with one active path
For the pilot environment, keep exactly one path active for each resource set. Two common arrangements work: the pipeline keeps deploying and Argo CD runs in observe-only mode with sync disabled, or the pipeline job for the pilot is disabled and Argo CD owns the resources. Never leave both enabled against the same namespace, because each system will revert the other's changes and the result looks like drift or flapping. Record which path is authoritative in the repository README and in the Application annotations. The output is a written ownership record per environment. The step is done when a test change shows up through exactly one path and the other path reports no drift.
Turn on webhook-driven refresh
Configure the Git host to send push events for the config repository to the Argo CD API server, so Argo CD refreshes the Application when a commit lands rather than waiting for the default polling interval. Confirm the webhook secret is set, that the API server endpoint is reachable from the Git host, and that delivery failures are visible to the team. Keep polling enabled as a fallback so a missed event does not leave an Application stale. The output is a pull request merged to the config repository that appears in Argo CD within a short, observed interval. The step is done when you have seen a successful refresh triggered by a webhook delivery, not by a manual refresh.
Cut over each environment in turn
Move environments one at a time, starting with the lowest risk and ending with production. For each environment, disable the pipeline deploy job, enable automated sync or a manual sync gate on the Application, and record the cutover in the change log. Keep a documented rollback that re-enables the pipeline job and turns off sync, and rehearse it in a lower environment first. Confirm that promotion now happens by merging a pull request that changes the image tag or chart version in the environment overlay. The output is an environment whose changes arrive only through Git. The step is done when the next production change has been made by a pull request and shows as synced with no manual kubectl action.
Remove kubeconfig secrets and deploy jobs from CI
After each environment has run through Argo CD for a period your change process accepts, delete the deploy jobs from the GitHub Actions or GitLab CI definitions, remove the kubeconfig or cluster token secrets from the CI platform, and revoke those credentials on the cluster side. Keep build and test jobs in CI, and make sure CI can still write the image tag to the config repository through a scoped token or deploy key. Confirm no remaining workflow references the old secrets. The output is a CI configuration with no cluster credentials and a list of revoked identities. The step is done when a search of the pipeline definitions and the CI secret store finds no cluster access left.

GitHub Actions and GitLab CI: what changes in each pipeline

In a GitHub Actions pipeline, deployment usually sits in a job that checks out the repository, authenticates to the cluster and runs kubectl apply or helm upgrade. After migration, the build job still compiles, tests and pushes an image, then opens a pull request against the config repository that changes an image tag or chart value. The deploy job and the cluster credentials it needs are removed.

Deploy jobs: Remove jobs or steps that run kubectl apply, kubectl rollout or helm upgrade against any cluster. Keep the test and image build jobs unchanged.
Repository and environment secrets: Kubeconfig files, service account tokens and cluster certificates stored in repository or environment secrets should be revoked at the cluster, then deleted from GitHub. Check environment protection rules for leftover references.
Config update job: A final job writes the new image digest into the config repository and opens a pull request. Give it a token or GitHub App with write access to that repository only.
Promotion approvals: Approvals that used to sit in environment protection rules move to review on the config repository pull request, where the change history is kept.
Workflow triggers: Deploy workflows that run on push or manual dispatch should be disabled once Argo CD owns the target namespace, so two systems do not change the same resources.

Before you disable the old deploy path, list every workflow, environment and secret that still references a cluster and confirm each one has a replacement or a removal date.

A GitLab CI pipeline usually defines a deploy stage that runs on a protected branch or tag and reads cluster access from CI/CD variables. Some projects also use a cluster connection inside GitLab, which links the project to a Kubernetes cluster for deployments. Migration removes the deploy stage and every cluster path from the project, so the GitLab project no longer holds a route into the cluster.

Deploy stage: Remove the stage or job that runs kubectl or helm against the cluster. Keep the build and test stages that produce a tagged image.
CI/CD variables: Kubeconfig content, service account tokens and cluster CA certificates stored as project or group variables should be revoked at the cluster first. Deleting the variable without revoking the credential leaves it usable.
Kubernetes integration: If the project or group has a cluster connection, disconnect it and confirm no environment still points at that cluster for deployments.
Config update stage: Add a stage that commits the new image reference to the config repository and opens a merge request. Use a project access token limited to that repository.
Promotion approvals: Move approvals for each environment to merge request approval rules in the config repository, so each promotion has a reviewer and a recorded change.

Confirm that no protected or group-level variable still holds cluster credentials and that the runner network can no longer reach the cluster API.

Webhook-driven refresh and how pull requests replace deploy jobs

Once the CI job stops running kubectl apply or helm upgrade, something else has to notice that the config repository changed. Argo CD can poll Git, but a webhook from the Git host lets it refresh an Application as soon as a merged pull request lands on the target branch, so the cluster follows the repository without waiting for the next reconciliation cycle. In practice, the webhook endpoint on the Argo CD API server must be reachable from GitHub or GitLab over TLS, and it must be configured with a shared secret so Argo CD can reject payloads that did not come from the Git host. Confirm the exact webhook setup, the payload types each host sends, and the secret field names against the current Argo CD documentation for your version before you build the pipeline around it. Keep polling enabled as a fallback so a missed webhook delays a sync rather than losing it.

Promotion between environments then becomes a pull request against the config repository. A change to the staging image tag or the production values file is reviewed, approved and merged like any other code change, and the Git history records who approved it and which commit reached each environment. This is the audit trail that replaced the CI job log. Plan branch protection so production paths require named reviewers, and decide whether production syncs run automatically on merge or wait for a manual sync in the Argo CD UI or CLI. Access follows the Argo CD RBAC model: projects limit which repositories and destination clusters an Application can use, and roles decide who may sync, override or delete. The CI system should hold only a Git token that can open pull requests, not cluster credentials.

The Argo CD API authenticates requests only with JSON Web Tokens, so automation that triggers syncs needs an account with a scoped role and a token that expires. The security documentation also states that Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, which keeps repository secrets out of pipeline output when you script around the API. Treat the CI runner as a lower-trust location than the cluster, and review which workflows can write to the config repository, since a merged change is what reaches production. Confirm token lifetimes, role bindings and webhook secret rotation with your security team before go-live.

What makes this migration take longer or shorter

Six drivers set the effort for moving CI deploy steps to Argo CD. Most of them compound: a large number of pipelines running Helm into many clusters with strict approvals takes far longer than a few raw-manifest services on one cluster. Check each driver against your own estate before you ask for a quote.

Number of pipelines and services

Each workflow or pipeline that runs kubectl apply or helm upgrade becomes a set of Application definitions, a config repository path and a promotion route. Effort grows with the count of distinct deploy jobs, not with the count of repositories, because shared reusable workflows or templates can be converted once and reused. Inventory every job that touches a cluster, including scheduled jobs and one-off hotfix pipelines, before estimating. Confirm which of them are still in use.

Clusters and environments

Every cluster and environment adds a registration, a credential path and an Argo CD sync policy to decide. Moving from one cluster with two namespaces to several clusters with separate production and disaster recovery targets changes the work from a single cutover into a staged one, with a rollback path per environment. Ask whether Argo CD will run in each cluster or centrally, because that choice changes the network paths and the number of controllers involved.

Helm charts versus raw manifests

Raw manifests map directly to Argo CD Applications pointing at a directory. Helm releases need values files, chart versions and release names to be mapped, and any hooks or post-install jobs must be checked for how they behave under Argo CD sync. Helm pipelines that pass values with --set flags from CI are the slowest to convert, because those values must first be moved into version-controlled files. Plan extra time for each chart that CI currently templates on the fly.

Approval and compliance evidence

Approvals that today happen as manual gates in CI must move into pull request reviews, branch protection and, where needed, Argo CD sync windows or project restrictions. If auditors expect records of who approved each production change, the config repository history has to carry that evidence from day one. Confirm the required approvers, the retention period for change records and whether a separate approval step must remain, since these answers decide how much process design is required.

Secret and credential reshaping

Removing cluster credentials from CI is the main security goal, but it also means every secret the pipeline used to inject must have a new source. Image pull secrets, database passwords and API keys need an approach that keeps values out of Git, such as an external secrets operator or a sealed secret pattern decided per secret type. Inventory which CI variables hold cluster tokens, which hold application secrets and which are shared across repositories, because each group needs a different path.

Team familiarity with GitOps

Teams that already review infrastructure changes through pull requests and understand reconciliation loops will adopt the new flow quickly. Teams that treat the cluster as something they push to will need time to learn how drift, sync status and manual rollbacks behave under Argo CD, and they will need a runbook for the first incidents. Factor in training and a period of parallel running. The Argo CD upgrade notes also matter here, because a team that has not tracked minor releases will need to check version support before moving production workloads.

Cost and effort drivers for the move

This table separates the one-time work of moving CI deploy steps into Argo CD from the recurring work of keeping it running. Read the one-time rows to size the project and the recurring rows to plan staffing after cutover. Sizing is qualitative, so use the quote questions at the end to turn each row into a written scope.

Driver	What it covers	What drives it up or down
Config repository design (one-time)	Deciding the layout of base manifests, per-environment overlays, image tag fields and who may approve changes to each path	Number of services and environments, whether teams share one config repo or split per team, and how many Helm charts or Kustomize overlays already exist
Argo CD install and repository access (one-time)	Installing Argo CD, registering the config repository with a read-only credential and wiring the webhook into GitHub or GitLab	Whether the install is HA from the start, how many clusters it targets, and whether the Git host is reachable from the cluster network
SSO and RBAC setup (one-time)	Connecting an identity provider or Dex, mapping groups to Argo CD projects and roles, and disabling the built-in admin user	Number of identity groups, whether approvers already exist as groups in the identity provider, and how many teams need separate projects
CI credential removal and pipeline rewrite (one-time)	Deleting kubeconfig and cluster tokens from CI secrets, replacing kubectl apply or helm upgrade steps with commits that update the config repo	Count of pipelines and branches that deploy, number of cluster credentials stored in CI, and any deploy steps that run database migrations or smoke tests
Pilot and cutover (one-time)	Running one service through the new path, then moving remaining services in ordered waves while CI deploys are switched off	Service criticality, whether two deploy paths must run in parallel, and change windows set by your change management process
Argo CD minor releases (recurring)	Argo CD ships a minor release four times a year, once every three months. Each one needs a test in a non-production cluster before a planned upgrade	Number of Argo CD instances, custom health checks or plugins, and how much of the upgrade notes your team must act on
Patch releases (recurring)	Only the three most recent minor versions receive patch releases, so the installed version must stay within that window	Whether patching is a scheduled task or an emergency task, and how quickly your change process approves a restart of the controller
Webhook and credential rotation (recurring)	Rotating the webhook secret, the Git read credential and the SSO client secret, and confirming webhook delivery after each change	Number of repositories and clusters registered, and whether credentials are issued by hand or from a secrets manager

What usually goes wrong and how to prevent it

Most failures in this move come from the overlap period, from credentials that outlive the cutover, and from changes that bypass Git. Each risk below has a specific check you can run before the CI deploy steps are removed.

Two controllers reconciling the same resources

During a parallel run, the CI job and Argo CD can both write the same Deployment, Service or ConfigMap, so each sync reverts the other's changes and the workload flaps. Assign each namespace or application to exactly one deployer before the first Argo CD sync, and disable the CI deploy step for that target in the same pull request that adds the Application. Check that no Application shows unexpected diffs caused by a pipeline run.

CI keeps cluster credentials after cutover

Kubeconfig secrets and service account tokens stored in GitHub Actions or GitLab CI variables remain valid after the pipeline stops using them, so the CI platform stays a path into the cluster. Revoke the service account, delete the stored kubeconfig and cluster variables, and rotate any token that was ever exposed. Confirm the removal with a scan of repository and group secrets, not only the workflow files.

Untrusted repository content reaching the repo-server

The Argo CD repo-server runs Helm and Kustomize against repository content, so a pull request that adds a chart dependency, a Kustomize remote base or a file path outside the application can read or change what is deployed. Restrict which repositories each Argo CD project may use, require review on config repository changes, and limit out-of-tree file access. Treat the config repository's branch protection as a deployment control.

Argo CD 3.0 changes breaking team access

Teams moving from 2.14 or earlier to 3.0 must move repository definitions from argocd-cm into Kubernetes Secrets, and Dex-based RBAC now matches the federated_claims.user_id claim. Update repository configuration and policy.csv before upgrading, and test a deploy from a non-admin account. Also confirm that update and delete permissions apply only to the Application itself and that logs access needs an explicit logs, get permission.

Audit trail lost in squashed commits

Teams often squash-merge promotion pull requests, which keeps only the final image tag and hides who approved each environment change and which CI run built the image. Require merge commits or record the pipeline run and approver in the commit message for config repository changes, and keep the image digest in the diff. Confirm that your auditors can trace a running version back to a reviewed pull request.

Drift from manual kubectl changes

Engineers who patch a Deployment during an incident leave the cluster different from Git, and Argo CD will either revert the fix or show the application as OutOfSync depending on sync settings. Decide in advance whether self-heal is enabled per application, document the emergency procedure, and require the same change to be committed to Git after the incident. Restrict direct write access to target namespaces so manual edits are the exception.

Questions teams ask before moving CI deploys to Argo CD

What does moving CI deploys to Argo CD cost, and what drives the price?

The cost is mostly people time: platform engineering to design the config repository and cluster registration, security review of the credential change, and pipeline rewrites on the CI side. Costs recur in the form of upgrades, Argo CD patching and on-call ownership, which continue after cutover. The main cost drivers are the number of pipelines and services, how many clusters and environments are involved, how many distinct approval flows exist today, and how much of the current deploy logic lives in shell scripts. Any price comes from a written scope, so ask for a quote that separates one-time design and cutover work from ongoing support. Your CI platform bill may also change. GitHub's Actions billing documentation lists per-minute rates beyond included quotas, and self-hosted runner usage is free under that documentation, so ask how your CI minutes will shift once deploy jobs stop running.

How long does a move from kubectl apply to Argo CD take?

No duration is given here because it depends on the scope. The effort follows the number of services, the number of clusters, how many environments you promote through, and whether Helm charts or Kustomize overlays already exist. A proof of concept on one service behaves very differently from a cutover of a whole product line. Ask for a timeline tied to a written list of pipelines, clusters and environments, plus a staged cutover plan that moves one namespace or service at a time. Keep the old deploy job in place until the Argo CD sync has run successfully in each environment, so rollback remains a pipeline run rather than a rebuild.

What must our team provide before the work starts?

You need to provide four things: access to the target clusters with rights to install Argo CD and register destinations, owners for each application repository who agree to the new commit flow, named approvers for production changes, and a decision on how identity will be handled. Repository owners decide where image tags are updated and who may merge to each environment branch. Approvers define which pull requests gate production. Your identity team should confirm how people will sign in, since Argo CD supports SSO through its bundled Dex or directly through an existing OIDC provider, according to the user management documentation. Also confirm who will own Argo CD after go-live, because it is a platform service that needs upgrades and patches.

Can our internal platform team do this migration alone?

Often yes, if the team already runs Kubernetes in production, understands Git-based workflows and has time to learn Argo CD's sync, project and RBAC model. The work is hardest where the team has to make design decisions for the first time: config repository layout, promotion rules and how the Argo CD instance is hardened. Internal teams often underestimate the cutover risk, in which two systems reconcile the same resources, and the security review of a change from pipeline-held credentials to a controller in the cluster. A fixed-scope partner engagement can cover the design, build, and cutover in writing, which makes the handover explicit. Decide early which parts your team will own after handover so the scope reflects that.

Is GitHub Actions or GitLab CI easier to move to Argo CD?

Neither is harder for Argo CD itself, because Argo CD watches a Git repository and does not care which CI system wrote to it. The difference is in how the pipeline is trimmed and how webhooks are wired. With GitHub Actions, the pipeline builds images and commits an updated tag to the config repository, while Argo CD refreshes from Git. With GitLab CI, the same pattern applies, and GitLab's self-managed options and Runner model may change where the webhook and job logic run. Your choice should depend on where your source and pipelines already live, not on Argo CD. Confirm the hosting model, data residency and runner placement with your Git provider first, since those affect how pipeline credentials are scoped.

How do we remove CI credentials from the pipeline safely?

Remove them in stages, not in one change. First, deploy Argo CD and confirm it can reach each target cluster using its own registered credentials. Second, switch each pipeline from applying manifests to committing an image tag or manifest change to the config repository, and keep the old credential valid during a parallel run. Third, revoke the CI kubeconfig or service account token once no pipeline needs it, and delete any stored secrets in the CI platform. Review repository credentials too: Argo CD reads them from Kubernetes Secrets since version 3.0, according to the upgrade notes, so plan where they live. Also restrict who can edit the config repository, because a commit there deploys. Argo CD's security documentation notes that the repo-server runs Helm and Kustomize on repository content, so only trusted repositories should be connected.

Does the move satisfy our change management and audit requirements?

A pull request history, required approvals and Argo CD's sync records can serve as evidence for change control, but the evidence only holds if the controls are set up deliberately. Argo CD does not produce an audit report or attestation, and independent auditors decide whether your design meets their criteria. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask your assessor early which evidence they expect: who approved each production change, which commit was deployed, and who could change the Argo CD configuration itself.

Where to confirm platform behavior before you start

Start by confirming which Argo CD version your cluster runs and which versions receive patches. The release process and cadence documentation states that only the three most recent minor versions receive patch releases, so an older install may be outside the window where fixes arrive. Read the Argo CD upgrade notes for 2.14 to 3.0 before you finalize the design, because they change RBAC so that update and delete permissions apply only to the application itself, require an explicit logs, get permission for log access, and make annotation-based resource tracking the default. Those changes affect the service account your CI or Argo CD setup uses to check status, so confirm them against your own installed version rather than assuming the defaults.

Next, check the access model in the user management documentation and the security documentation. Confirm that the built-in admin account is disabled with admin.enabled set to false, that the CI system has no Argo CD login beyond what the design requires, and that repository credentials are stored as Kubernetes Secrets, since Argo CD 3.0 removed them from argocd-cm. Also confirm how your repo-server handles untrusted Helm or Kustomize content, because the config repository you create will be rendered there. Then review your CI platform's own documentation for how its secrets are scoped to environments and branches, and how it sends webhook events, including the signing or secret token it uses. Record which secrets the pipeline still holds after the change, and confirm the webhook secret and target URL in both systems before the first sync is tested.

How DeployOpen scopes, delivers and supports this migration

DeployOpen starts by mapping every kubectl apply and helm upgrade step in your existing pipelines to a Git-based desired state in Argo CD. The work is planned as a fixed-scope engagement, built in your own cloud accounts or data centers, and handed over with documentation your team can run.

How we scope

Inventory every pipeline job that touches a cluster, including credentials, namespaces, and Helm release names.
Agree the config repository layout, environment list, and which team approves promotion pull requests.
Record the written scope, deliverables, and timeline before any cluster or pipeline change begins.
Confirm which Git host, runner model, and network path Argo CD will use to reach your repositories.

How we build

Install Argo CD with SSO, project boundaries, and the admin account disabled once SSO works.
Convert each pipeline deploy step into an Application, with the CI job reduced to build and image publish.
Configure webhooks for fast refresh and test that a merged pull request syncs the target environment.
Remove stored cluster credentials from CI variables only after a verified sync path exists for each environment.

How we hand over

Document the config repository structure, promotion steps, and rollback by revert commit.
Provide runbooks for webhook failures, OutOfSync applications, and rotating repository and SSO credentials.
Walk your platform and security teams through the audit trail that Git history and Argo CD sync records provide.
Deliver the written record of what was removed from CI and which credentials were revoked.

How we support

Plan upgrades around the three most recent minor versions that receive patch releases, as the project's release process states.
Review Argo CD upgrade notes for RBAC and repository configuration changes before each version move.
Ongoing support, upgrades, and continuous testing are available as a retainer after handover.
Confirm backup and recovery steps for the Argo CD configuration and cluster registrations with your team.

Moving kubectl apply steps in GitHub Actions or GitLab CI to Argo CD