Case Study: Designing a GitLab Runner for a Managed Application Environment

CI/CD infrastructure is easy to overlook in application architecture.

A development team may see a GitLab Runner as simply the mechanism that executes a pipeline. Architecturally, however, the runner is a privileged component: it executes code, receives credentials, and may need network access to the environment it is deploying to.

That makes its placement and permissions part of the solution architecture.

For an application such as an object-management system, the challenge was to enable automated deployment through GitLab while keeping a clear separation between source control, build execution, application infrastructure and operations.

The architectural boundary

The simplified flow looks like:

Developer
    │
    ▼
 GitLab
    │
    │ pipeline
    ▼
GitLab Runner
    │
    │ controlled deployment access
    ▼
Application Environment
    │
    ├── Application
    ├── Configuration
    └── Data / dependencies

The important component in the middle is the runner.

It cannot be treated as just another application server. A pipeline needs enough access to deploy, but granting the runner broad network or administrative access creates an unnecessary trust relationship.

The architecture therefore needs to answer:

What can the runner reach? Which credentials can it use? Where does it run? Who manages it? What happens if a pipeline is compromised?

Least privilege applies to CI/CD as well

A common mistake is to secure the application while giving the deployment mechanism extensive privileges.

That effectively creates a back door.

The runner should have only the connectivity and permissions required to perform its deployment role. Its access should be bounded by network segmentation, scoped credentials and the target environments it actually needs to reach.

This also affects runner placement.

Putting a runner inside a trusted network segment simply because it needs deployment connectivity can unintentionally extend the trust boundary of the entire CI/CD system.

A better approach is to explicitly model the runner as part of the security architecture.

        GitLab
           │
           │ pipeline
           ▼
   ┌────────────────┐
   │ GitLab Runner  │
   │                │
   │ build / deploy │
   └───────┬────────┘
           │
     limited trust
           │
           ▼
   ┌────────────────┐
   │ Target         │
   │ environment    │
   └────────────────┘

The runner is trusted to perform a specific function, not trusted with everything around it.

Separating build and runtime responsibilities

Another important architectural distinction is that the component responsible for building or deploying software should not automatically become responsible for running it.

The runner executes the delivery process.

The application environment runs the resulting application.

Operations remains responsible for the running environment, while engineering owns the implementation and pipeline logic.

This gives the architecture a clean separation:

That separation becomes particularly valuable when the application moves between environments or when deployment responsibilities change.

The HLD decision

At HLD level, the goal is not to document every GitLab configuration parameter.

The HLD establishes the important architectural decisions:

• CI/CD is an explicit part of the solution architecture.
• The runner has a defined trust boundary.
• Deployment access is restricted to the required targets.
• Application runtime responsibility remains separate from pipeline execution.
• Credentials and connectivity are designed around least privilege.
• Operational ownership of the resulting environment is explicit.

The technical design can then define the concrete runner configuration, network rules, secrets handling and deployment mechanism.

This is the same principle as elsewhere in solution architecture:

the HLD establishes the boundary; the TD makes it implementable.

The broader lesson

CI/CD is often introduced after the application architecture has already been designed.

That is backwards.

The moment automated deployment can access an environment, the CI/CD system becomes part of the environment’s security and operational model.

A GitLab Runner is effectively a controlled execution point between development and production infrastructure.

Treating it as such leads to much clearer decisions around network access, credentials, isolation and ownership.

Key insight: A CI/CD runner is not just a developer tool. It is a privileged integration component, and its trust boundary belongs in the architecture.