Argo CD for infrastructure as code
Argo CD is a GitOps controller for Kubernetes, and its official server is the second pick for infrastructure-as-code work. It owns one specific question in an IaC loop: does the running cluster match the desired state declared in Git, and what would a sync change. Spacelift ranks first here because it gates and applies changes across a broader IaC surface; Argo CD takes the next spot for the Kubernetes-deployment slice of that picture.
For a team whose declared infrastructure ends up reconciled into a cluster, this is the server that reads the live application state and the drift between it and Git. An agent can see what is out of sync before anything is applied.
How Argo CD fits
The reads carry most of the value for reasoning about a change. list_applications and get_application surface each app's sync and health status, get_application_resource_tree shows the resource hierarchy, get_application_managed_resources lists what the app owns, and get_application_workload_logs plus get_resource_events explain why a workload is unhealthy. list_clusters enumerates the registered clusters. When the agent is ready to move, sync_application reconciles an app to the state in Git, and create_application, update_application, and delete_application manage the app definitions themselves; get_resource_actions lists what actions a given resource supports.
The honest scope is narrow on purpose: this is Kubernetes GitOps, not general IaC. It does not plan or apply Terraform, manage cloud resources outside a cluster, or gate changes with policy across stacks. Spacelift covers that broader management-and-apply role, which is why it leads. Kubernetes' own server is the lower-level cluster API for operations Argo CD does not model, and Docker sits underneath at the container and image layer. Reach for Argo CD when your IaC pipeline lands in Kubernetes through GitOps and you want an agent reading sync status and drift; pair it with the others for the layers above and below.
Tools you would use
| Tool | What it does |
|---|---|
| list_clusters | Lists all clusters registered with Argo CD. |
| list_applications | Lists and filters Argo CD applications. |
| get_application | Retrieves detailed information about a single application, including sync and health status. |
| create_application | Creates a new Argo CD application. |
| update_application | Modifies an existing application. |
| delete_application | Removes an application. |
| sync_application | Triggers a sync to reconcile an application to the desired state in Git. |
| get_application_resource_tree | Returns the resource hierarchy for an application. |
| get_application_managed_resources | Returns the resources managed by an application. |
| get_application_workload_logs | Retrieves logs from an application's pods and deployments. |
FAQ
- What does the Argo CD server let an agent see?
- Through get_application and list_applications it reads each app's sync and health status, and get_application_resource_tree shows the resource hierarchy, so an agent can tell whether the cluster matches the state declared in Git and what drift exists.
- Can it apply a change, or only read state?
- Yes. sync_application reconciles an application to the desired state in Git, and create_application, update_application, and delete_application manage the app definitions. The reads, though, are where it does the most useful reasoning.
- Why is Spacelift ranked ahead of Argo CD for IaC?
- Spacelift gates and applies changes across a broader IaC surface, including Terraform-style workflows. Argo CD covers the Kubernetes-deployment slice through GitOps, which is narrower, so it ranks second for this task.