# How to Get Started with Argo CD Core Features: A Complete Guide > Learn to get started with Argo CD core features. Install, configure the CLI, and create your first Application for declarative GitOps continuous delivery on Kubernetes. - Repository: [Argo Project/argo-cd](https://github.com/argoproj/argo-cd) - Tags: getting-started - Published: 2026-07-14 --- **Install the Argo CD control plane using the official manifest, configure the CLI tool, expose the API server, and create your first Application from a Git repository to enable declarative GitOps continuous delivery for Kubernetes.** Argo CD is a declarative GitOps continuous delivery system for Kubernetes that automates application deployment and lifecycle management. According to the argoproj/argo-cd source code, the core workflow involves installing the control plane into the `argocd` namespace, configuring CLI access, and synchronizing applications from Git repositories to target clusters. This guide walks through the essential steps based on the official implementation in [`docs/getting_started.md`](https://github.com/argoproj/argo-cd/blob/main/docs/getting_started.md) and the supporting manifest files. ## Install the Argo CD Control Plane The first step to get started with Argo CD core features is deploying the control plane components to your Kubernetes cluster. The project provides a single comprehensive manifest that installs all necessary resources into the `argocd` namespace. Execute the following commands to create the namespace and install the server components: ```bash kubectl create namespace argocd kubectl apply -n argocd \ --server-side --force-conflicts \ -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml ``` The `--server-side` flag is critical for bypassing the 262 KB annotation limit imposed by client-side apply, which is essential when applying large Custom Resource Definitions like `ApplicationSet`. This approach ensures the `argocd-server` Deployment defined in [`manifests/base/server/argocd-server-deployment.yaml`](https://github.com/argoproj/argo-cd/blob/main/manifests/base/server/argocd-server-deployment.yaml) and its associated Service in [`manifests/base/server/argocd-server-service.yaml`](https://github.com/argoproj/argo-cd/blob/main/manifests/base/server/argocd-server-service.yaml) deploy correctly. ## Configure the Argo CD CLI The **Argo CD CLI** (`argocd` binary) serves as the primary interface for automation and scripting. You can install it via Homebrew or download directly from the releases page: ```bash brew install argocd ``` The CLI implementation resides in [`cmd/argocd/app.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd/app.go), which handles application management commands including `app create` and `app sync`. For authentication workflows, the [`login.go`](https://github.com/argoproj/argo-cd/blob/main/login.go) file in [`cmd/argocd/commands/login.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd/commands/login.go) implements the `argocd login` command used to establish sessions with the API server. ## Expose the API Server and UI By default, the Argo CD API server is only reachable from within the cluster via the `argocd-server` Service. To access the web UI and API endpoints externally, you must expose the service using one of three methods. ### LoadBalancer Method The most common approach for production environments is changing the Service type to `LoadBalancer`: ```bash kubectl patch svc argocd-server -n argocd \ -p '{"spec": {"type": "LoadBalancer"}}' ``` This modifies the Service definition found in [`manifests/base/server/argocd-server-service.yaml`](https://github.com/argoproj/argo-cd/blob/main/manifests/base/server/argocd-server-service.yaml) to provision a cloud load balancer. ### Port Forwarding for Local Development For local testing and debugging, use `kubectl port-forward` to access the UI without exposing it externally: ```bash kubectl port-forward svc/argocd-server -n argocd 8080:443 ``` Then navigate to `https://localhost:8080` in your browser. ## Authenticate and Secure the Installation Argo CD generates an initial admin password automatically during installation. This credential is stored in the `argocd-initial-admin-secret` Secret within the `argocd` namespace. Retrieve the password using the admin command: ```bash argocd admin initial-password -n argocd ``` After obtaining the password, authenticate with your exposed endpoint: ```bash argocd login --username admin --password ``` Replace `` with the external IP address or hostname assigned to your LoadBalancer. You should change this initial password immediately after first login to secure the installation. ## Register External Clusters (Optional) When deploying to clusters other than the one hosting Argo CD, you must register the target cluster. The CLI command creates a ServiceAccount named `argocd-manager` and binds it to an admin-level ClusterRole in the target cluster. First, list available contexts: ```bash kubectl config get-contexts -o name ``` Then register the desired context: ```bash argocd cluster add ``` This step is optional when deploying only to the local cluster where Argo CD is installed, as it automatically uses `https://kubernetes.default.svc` as the destination server. ## Create Your First Application Argo CD manages Kubernetes resources through the **Application CRD**, defined in [`pkg/apis/application/v1alpha1/types.go`](https://github.com/argoproj/argo-cd/blob/main/pkg/apis/application/v1alpha1/types.go). This Custom Resource represents a Git-tracked application and defines the source repository, path, and destination cluster. Create the guestbook example application using the CLI: ```bash argocd app create guestbook \ --repo https://github.com/argoproj/argo-cd-example-apps.git \ --path guestbook \ --dest-server https://kubernetes.default.svc \ --dest-namespace default ``` This command creates an Application resource that tracks the specified Git repository path and targets the default namespace in the local cluster. The Application CRD stores these specifications declaratively, allowing Argo CD to monitor the repository for drift. ## Synchronize and Deploy Newly created applications begin in an `OutOfSync` state because the cluster resources have not yet been created. To deploy the application, trigger a synchronization: ```bash argocd app sync guestbook ``` This command initiates a server-side `kubectl apply` of the manifests from the Git repository, creating the necessary Kubernetes resources and bringing the cluster state into alignment with the desired state defined in Git. The synchronization logic executes against the API server, which then applies the resources to the target cluster. You can also trigger sync operations through the web UI by selecting the application and clicking **Sync**. ## Summary - **Install Argo CD** using the official manifest with `--server-side` apply to handle large CRDs in the `argocd` namespace - **Configure the CLI** via Homebrew or direct download to enable programmatic interaction with the API - **Expose the server** using LoadBalancer services, Ingress resources, or local port forwarding depending on your environment - **Authenticate** using the initial password from `argocd-initial-admin-secret` and change it immediately after first login - **Register external clusters** using `argocd cluster add` to create the necessary ServiceAccount and RBAC bindings - **Define Applications** using the Application CRD to map Git repositories to Kubernetes destinations - **Synchronize** applications to deploy resources using server-side apply operations ## Frequently Asked Questions ### What is the difference between Argo CD Application and ApplicationSet? An **Application** manages a single Git repository path and targets a specific cluster and namespace, as defined in [`pkg/apis/application/v1alpha1/types.go`](https://github.com/argoproj/argo-cd/blob/main/pkg/apis/application/v1alpha1/types.go). An **ApplicationSet** is a higher-level CRD that generates multiple Application resources across different clusters or namespaces from a single template, enabling multi-cluster deployments and tenant isolation. ApplicationSets require the same server-side apply during installation due to their large CRD size. ### How does Argo CD handle large CRDs during installation? Argo CD uses **server-side apply** (`--server-side --force-conflicts`) to bypass the 262 KB annotation limit imposed by traditional client-side apply. This is essential for large Custom Resource Definitions like ApplicationSet, ensuring the control plane components install successfully without encountering resource size limitations. ### Can I use Argo CD without the CLI? Yes, though the CLI provides the most efficient interface for automation. You can manage applications entirely through the web UI or by creating Application resources directly using `kubectl` and YAML manifests. The CLI commands in [`cmd/argocd/app.go`](https://github.com/argoproj/argo-cd/blob/main/cmd/argocd/app.go) simply provide a convenient wrapper around the Kubernetes API for creating and synchronizing these resources. ### What permissions does Argo CD require for external clusters? When registering an external cluster using `argocd cluster add`, the CLI creates a ServiceAccount named `argocd-manager` in the target cluster and binds it to a ClusterRole with admin-level permissions. This allows Argo CD to deploy resources across all namespaces in the target cluster. You can customize these permissions by manually creating the ServiceAccount and RBAC rules with restricted access if full admin rights are not required.