Skip to content
Casey Labs

Overview

Before getting into GitLab settings, Terraform workspaces, or Kubernetes runners, it helps to name the problem.

Most software teams need the same basic delivery capabilities. They need somewhere to store code, a way to review changes, a pipeline that builds and tests the application, a way to scan for risk, a path to deploy safely, and enough operational feedback to know whether the system is healthy. In small organizations, these pieces often grow one repository at a time. In larger organizations, that creates drift: every team has a slightly different pipeline, permissions model, deployment path, and security exception process.

A secure code delivery platform is a shared way to solve that problem. It gives teams a normal path for building and releasing software, and it makes the organization’s required controls part of that path.

What platform engineering means

Section titled “What platform engineering means”

Platform engineering is the practice of building shared internal capabilities as a product for other engineering teams. The users are developers, security engineers, SREs, infrastructure engineers, and release managers. The product is not one tool. It is the combination of workflows, documentation, automation, support boundaries, and reusable building blocks that make common work easier.

For example, a platform team might provide:

  • repository templates
  • CI/CD components
  • standard deployment patterns
  • approved base images
  • Terraform modules
  • observability defaults
  • incident runbooks
  • policy checks
  • self-service onboarding

A good platform makes the recommended path easier than inventing a custom one. Platform teams often call this a paved road or golden path. It is not meant to prevent every variation. It gives teams a default that already handles the repetitive parts well.

What DevOps adds

Section titled “What DevOps adds”

DevOps is the operating model behind much of this work. It connects software delivery and operations instead of treating them as separate worlds. A team should own more than code. The delivery process should include build automation, test feedback, infrastructure review, deployment safety, monitoring, and incident response.

In this guide, DevOps shows up in several ways:

  • code changes go through merge requests
  • pipelines provide fast feedback
  • infrastructure changes are planned and reviewed
  • policy is tested like code
  • production releases produce evidence
  • reliability is measured with SLOs and runbooks

The aim is not to rename every team or adopt a slogan. It is to make the path from change to production visible and repeatable.

Why GitLab is central

Section titled “Why GitLab is central”

GitLab is the workflow layer in this platform. It hosts source code, merge requests, CI/CD pipelines, security policies, approval gates, protected branches, and release evidence. That makes it the place where developers experience most platform controls.

GitLab is not the only system involved. Terraform manages durable infrastructure state. EKS runs CI jobs. OPA or Sentinel evaluates policies. SRE practices define whether the platform is reliable enough to trust. But GitLab is where a developer sees the platform in daily work: open a merge request, wait for required checks, respond to findings, and merge through the approved path.

GitLab governance matters because manual project setup does not scale. If GitLab groups, projects, branch protections, approval rules, and policies are modeled as code, the baseline can be reviewed and improved over time.

What supply chain security means

Section titled “What supply chain security means”

Software supply chain security is about the integrity of the path from source code to production. Source code is only one input. Dependencies, base images, build tools, runners, package registries, artifact stores, signing keys, deployment credentials, and release approvals all influence what eventually runs.

A supply chain program needs both prevention and evidence.

Prevention reduces the chance of a bad change or compromised dependency reaching production. Examples include protected branches, required review, dependency scanning, secret detection, isolated runners, pinned build images, and restricted credentials.

Evidence helps answer questions later. Which commit produced this artifact? Which pipeline ran? Which runner executed the build? Which dependencies were included? Was the artifact signed? Can the deployment system verify that it is using the intended image digest?

This guide uses SBOMs, provenance, signatures, and immutable artifact references as practical evidence outputs. They are not magic. They become useful when the platform requires them consistently and makes them available to deployment, audit, and incident workflows.

The reference platform

Section titled “The reference platform”

The reference implementation uses these layers:

Architecture diagram showing identity, GitLab, HCP Terraform, approved package sources, EKS runners, AWS IAM, evidence, and operations for the secure code delivery platform.

Layer Role
GitLab Source control, merge requests, CI/CD, security policies, approvals
HCP Terraform Infrastructure planning, state, policy checks, and approved applies
Policy-as-code Testable rules for CI, infrastructure, and exceptions
AWS EKS Isolated execution substrate for GitLab Runner
Monitoring EKS cluster health, runner metrics, GitLab delivery metrics, alerts, SLOs, and runbooks
SRE practices SLOs, dashboards, runbooks, incidents, and review loops

The design rule is that the repository is the source of truth. GitLab settings, Terraform workspaces, runner tiers, policy controls, and operating expectations are modeled as reviewable code first. External UIs are useful execution surfaces, but they are not the authoritative design record.

Reading the guide

Section titled “Reading the guide”

The next post starts with source of truth because that decision shapes everything else. If the platform cannot say where the intended state lives, every later control becomes harder to reason about.

After that, the guide moves from architecture to enforcement:

  1. Establish the repository as the design record.
  2. Split responsibilities across control planes.
  3. Govern GitLab projects and policies.
  4. Provide a paved-road CI path.
  5. Govern infrastructure with HCP Terraform.
  6. Isolate CI execution on EKS.
  7. Monitor EKS, GitLab Runner, and GitLab delivery metrics.
  8. Use supply chain evidence and SRE practices to keep the platform trustworthy.
  9. Pull the moving pieces together in the conclusion.

The examples are intentionally baseline examples. A real enterprise will add identity integration, service catalogs, exception workflows, environment-specific deployment systems, and deeper policy coverage. The foundation should still be the same: clear ownership, reviewable code, testable policy, isolated execution, and measurable operations.

Reference baseline

Section titled “Reference baseline”

The implementation baseline was checked against primary documentation and registries on June 29, 2026. Current registry values at that point included GitLab Terraform provider 19.1.0, TFE provider 0.78.0, AWS provider 6.52.0, Kubernetes provider 3.2.0, Helm provider 3.2.0, and GitLab Runner Helm chart 0.90.1.

Primary references used across the series: