Running Argo CD core without the API server or UI

Argo CD is released under the Apache License 2.0 and the project offers no paid edition, so the software itself carries no license fee. Your cost comes from the infrastructure that runs the controllers and the people who operate them. Core runs fewer components than the full install, which can reduce the cluster capacity it needs, but the savings are modest compared with the staff time spent on upgrades and access work. The main cost drivers are the number of clusters Argo CD manages, the number of Git repositories it reads, and how many people need to see application state through a UI or API. If your team is small and every change goes through Git, core may stay simple. Ask any partner for a quote that separates one-time setup from recurring upgrade, patching and support work.

The initial install is a single manifest apply, but the ongoing work is what matters. The release process describes a minor release four times a year, and only the three most recent minor versions receive patch releases. That means you must plan an upgrade cycle and keep a test cluster ahead of production. Read the upgrade notes before each minor move. The 2.14 to 3.0 notes changed several defaults: update and delete RBAC now apply only to the application itself, logs access needs an explicit logs, get permission, and annotation-based resource tracking is the default. Repository definitions moved from the argocd-cm ConfigMap into Kubernetes Secrets. Budget engineer time for reading notes, testing each change and rolling it out, and confirm who owns that calendar.

A team can run core without outside help if it already operates Kubernetes in production, understands Git-based change control, and can manage cluster RBAC and secrets. Core removes the API server and UI, so the cluster itself becomes the main control point. Your engineers must be comfortable with kubectl, the Argo CD CLI in its core mode, and the Application and AppProject resources. Check three skills before you decide: writing RBAC rules for Application objects, handling repository credentials as Secrets, and running an upgrade with a rollback plan. If any of these are thin, a fixed-scope engagement can document the runbook and train your staff, and a retainer can cover upgrades. Ask for the written scope before work starts.

Move to the full install when more people need to work with applications than cluster access comfortably allows. The triggers are usually several teams that need separate permissions, a UI for review and troubleshooting, programmatic access through the API for pipelines, or single sign-on for many users. The user management documentation recommends using the built-in admin user only for initial setup, then disabling it with admin.enabled set to false once local users or SSO are configured. Core does not give you that SSO path by itself, so plan the switch before audit or onboarding pressure arrives. Confirm how your identity provider, groups and projects will map to Argo CD roles before you migrate, because moving later means reviewing every existing permission.

Core can run in production when its access model matches your operating model, but the decision needs documented controls rather than an assumption. The security documentation says Argo CD authenticates API requests only with JSON Web Tokens and uses TLS for traffic between its own components. In core, the API server is absent, so your protection shifts to Kubernetes RBAC, network policy and the controls on the namespace where Argo CD runs. The repo-server runs Helm and Kustomize on repository content, so untrusted repositories and out-of-tree file access are a risk to manage. Restrict who can write Application objects and which repositories they can reference. Confirm with the installation guide which components core includes before you sign off on a production design.

In core, applications are Kubernetes objects, so you create, inspect and change them with kubectl and the Argo CD CLI running in core mode. Each Application points to a Git repository, a path and a destination cluster. Argo CD reconciles the cluster to match the repository, so the Git history becomes your change record. Because there is no UI, operators need a shared procedure for checking sync status, reading events and handling a stuck sync. Write that procedure before go-live and test it with a deliberate failure. Confirm the exact core-mode commands and flags in the official installation guide for your release, since command behavior can change between minor versions.

A partner should scope the work in writing before starting, because most engagements are fixed-scope and the quote follows from that document. Ask for these items: the target clusters and their network boundaries, the Git repositories and how credentials will be stored, the access model for operators and automation, the install method and version pinning, backup and recovery steps for Argo CD's own configuration, and the upgrade process for the three supported minor versions. Ask whether the scope covers documentation, handover training and acceptance testing. Ongoing upgrades, patching and continuous testing are available as retainers, so separate those from the build. DeployOpen does not publish a price list. It prepares systems and evidence for compliance reviews, but independent auditors issue any audit reports.