GitLab Now Works as a Full AWS Control Plane
Quick Reads
- GitLab combines OpenTofu, CI/CD, and Argo CD into one end-to-end AWS automation workflow.
- Infrastructure is defined as code and deployed to Amazon EKS automatically.
- Argo CD handles GitOps-based application delivery with no manual cluster access required.
- The setup was originally demoed live at AWS Summit Madrid 2025.
- Source code is publicly available via the SATEC Public Demo Group on GitLab.
Setting up cloud environments manually is slow, error-prone, and hard to repeat. GitLab is changing that. In a new engineering tutorial published August 18, 2026, GitLab and partner Clober, part of the SATEC group, demonstrate how teams can use GitLab as a complete GitLab AWS control plane, automating everything from network provisioning to live application deployment.
The approach brings together three tools: OpenTofu for infrastructure, GitLab CI/CD for pipeline orchestration, and Argo CD for GitOps-based delivery. Together, they eliminate manual steps across the entire cloud lifecycle.
This is not a theoretical setup. It was originally presented as a live demo at AWS Summit Madrid 2025, and the full source code is publicly available in the SATEC Public Demo Group on GitLab.
Why Infrastructure as Code and GitOps Matter
Manual cloud configuration creates inconsistency. Infrastructure as Code (IaC) fixes that by making environments reproducible, version-controlled, and fully automated. GitOps then extends those principles to application delivery. Instead of pushing changes directly to Kubernetes clusters, teams define a desired state in Git. Argo CD then continuously reconciles the cluster to match that state.
The benefits are clear. Rollbacks become as simple as reverting a commit. Teams review and approve changes through merge requests. And developers never need direct cluster access. As a result, security improves alongside speed.
GitLab ties all of this together in one platform, combining source code management, CI/CD pipelines, Terraform state management, and a built-in Container Registry.
Provisioning AWS Infrastructure with OpenTofu
The first pipeline handles infrastructure. OpenTofu, the open-source fork of Terraform, provisions a full AWS environment declaratively. It creates the VPC, subnets, gateways, routing tables, and an Amazon EKS cluster spread across multiple availability zones.
Critically, no values are hardcoded. Instead, the setup uses GitLab CI/CD variables such as TF_VAR_region, TF_VAR_cluster_name, and AWS_SECRET_ACCESS_KEY. These are stored as protected and masked variables in GitLab under Settings > CI/CD > Variables. This keeps the pipeline flexible and the credentials secure. Once the EKS cluster is ready, this first pipeline automatically triggers a second one.
Installing Kubernetes Tools Automatically
The second pipeline takes over without any manual steps. It uses OpenTofu with the Helm provider to install three core Kubernetes components: Argo CD for GitOps management, CertManager for automated TLS certificates, and Ingress NGINX Controller for traffic routing. Each Helm release is defined in code, meaning upgrades and rollbacks follow the same infrastructure change process. Once those tools are in place, a third pipeline fires automatically to begin application deployment.
Deploying the App via GitOps and Argo CD
The third pipeline uses the kubeconfig generated by OpenTofu to connect to the EKS cluster. It then applies Argo CD application manifests that define the desired state of the sample web application. From there, Argo CD takes over, it detects the manifests and synchronizes them with the cluster automatically.
This pipeline also creates the Kubernetes namespace, sets up a Container Registry secret for secure image pulling, and applies repository and certificate issuer configurations. All of it runs through GitLab CI/CD with zero manual intervention.
Building and Packaging the Application
Before Argo CD can deploy anything, the application must first be built and published. A dedicated CI/CD pipeline handles this in the application repository. It builds the Docker image, tags it, and pushes it to the GitLab Container Registry.
After publishing, the pipeline updates the image reference in a separate deployment repository. This separation, application code in one repo, Kubernetes manifests in another, follows clean GitOps principles. Once the deployment repo is updated, Argo CD picks up the change and deploys the new version automatically.
What This Means for Engineering Teams
The GitLab AWS control plane model solves a real problem. Cloud environments today involve too many moving parts managed across too many tools. By centralising provisioning, build, and delivery into one platform, teams gain traceability, speed, and consistency. Every change is versioned. Every deployment is auditable. And the entire workflow, from raw AWS infrastructure to a running application, runs without human handoffs.
For Nigerian engineering teams working with AWS and Kubernetes, this kind of automated pipeline reduces the operational overhead that often slows cloud adoption at scale. Organisations looking to implement similar setups can explore the Clober DevSecOps practice for tailored guidance.
