Runners

Runner engagement model comparison

Runner engagement model comparison

Managed runner work can start as a short assessment, a defined implementation project, retained operations, or urgent response. Use this comparison to choose the right Assistance engagement model for runner fleets serving GitHub Actions, GitLab runners, Gitea Actions, and Forgejo Actions.

All models use the same shared responsibility principle: Assistance can operate the runner layer inside an agreed boundary, while the customer keeps ownership of repositories, workflow intent, approvals, data classification, cloud/SaaS accounts, and legal or compliance decisions.

Engagement models at a glance#

ModelBest forTypical outputsNot a good fit when
Assessment or auditYou need a fast, evidence-backed view of current runner risks, cost drivers, or migration options.Current-state findings, prioritized recommendations, sizing estimate, security observations, evidence gaps.You expect Assistance to deploy or operate production runners immediately.
Implementation projectYou already have a target outcome, such as moving from hosted runners to self-hosted capacity or adding private-network builds.Fleet design, runner deployment, label/tag scheme, validation results, runbooks, rollback notes, handoff pack.The scope is changing weekly or day-2 ownership is not agreed.
Retained operationsYou need ongoing DevOps, SRE, DevSecOps, or platform support for runner capacity.Monitoring, triage, patch/change workflow, support reporting, continuous improvement backlog, evidence updates.You only need a one-time recommendation or do not have an internal owner for approvals.
Emergency responseReleases are blocked, runner capacity is failing, or a security/network incident needs coordinated recovery.Stabilization plan, incident notes, recovery actions, follow-up risks, recommended permanent fixes.The issue is not urgent and can follow a normal planned change path.

Compare by customer need#

NeedAssessmentImplementationRetained operationsEmergency response
Choose between GitHub Actions, GitLab runners, Gitea Actions, and Forgejo ActionsStrong fitFit when a decision is already madeAdvisory onlyOnly if platform choice blocks recovery
Design runner fleet topology, sizing, labels/tags, and imagesRecommendationFull design and buildIterative improvementMinimal viable recovery design
Improve cache, artifact, and dependency behaviorFindings and optionsImplement approved strategyTune from operational dataOnly to unblock failed jobs
Define secrets and private-network boundariesGap analysisImplement agreed controlsReview and maintainContain exposure or restore access
Add monitoring, support, and change workflowsRecommendationsConfigure initial workflowPrimary operating modeIncident communications and follow-up
Produce evidence and handoff artifactsEvidence packHandoff packUpdated operational recordsIncident and recovery records

Platform considerations#

  • GitHub Actions engagements usually focus on runner groups, labels, organization/repository boundaries, environment protection, and job routing. See GitHub Actions.
  • GitLab runners engagements usually focus on runner scope, tags, executors, protected runners, cache/artifact behavior, and group/project registration. See GitLab runners.
  • Gitea Actions engagements usually focus on self-hosted runner registration, labels, Actions compatibility expectations, network placement, and operational maturity around smaller installations. See Gitea Actions.
  • Forgejo Actions engagements usually focus on self-hosted runner registration, labels, repository or instance boundaries, and the same security/operations expectations used for other managed fleets. See Forgejo Actions.

If multiple platforms are in scope, Assistance documents where labels, tags, permissions, secrets, and failure modes differ so teams do not assume that one platform's runner behavior applies to another.

For managed git server engagements, the routing model is also different by server:

Managed git serverRunner or verification routing to compare
GitLab option runbookGitLab Runner scopes, tags, protected runners, executors, cache, and artifacts.
Gerrit option runbookEvent-driven verification workers behind Jenkins, Zuul, Tekton, or custom adapters that report Gerrit labels.
GiteaGitea Actions self-hosted runner labels and registration scope; validate Actions compatibility on the installed version.
ForgejoForgejo Actions self-hosted runner labels and registration scope; validate workflow, token, artifact, and cache behavior on the installed version.

Use this as a decision aid. Keep setup and troubleshooting details in the platform pages and runbooks.

Scope and responsibility comparison#

AreaAssessment or auditImplementation projectRetained operationsEmergency response
Fleet designRecommend target state and risks.Design and implement approved target state.Maintain and evolve based on usage.Design only what is needed to stabilize.
Sizing and cost inputsEstimate from current jobs and queue data.Validate with representative workloads.Review trends and propose adjustments.Identify immediate bottlenecks.
Labels/tagsIdentify current inconsistencies.Create or migrate routing conventions.Govern changes and drift.Add temporary routing only if needed.
ImagesReview baseline and update risks.Build or document approved baseline.Patch and coordinate updates.Roll back or replace broken images.
Caching/artifactsAssess retention, leakage, and performance.Implement approved cache/artifact pattern.Tune cleanup, storage, and failure handling.Disable or adjust unsafe/broken paths.
SecretsReview exposure boundaries.Implement agreed scoping and handoff notes.Support rotations and access reviews.Preserve evidence and reduce exposure.
Network/private accessMap dependencies and risks.Configure approved connectivity and allowlists.Maintain changes through workflow.Restore or isolate critical access.
Monitoring/troubleshootingRecommend signals and runbooks.Configure initial dashboards and alerts.Triage queues, failures, and incidents.Lead recovery triage and follow-up.

See runner security hardening, runner monitoring and support, and troubleshooting for the operating pages that support these responsibilities.

Pricing inputs by model#

This guide does not invent exact prices. Assistance scopes commercial effort from observable inputs:

  • platform count and whether GitHub Actions, GitLab runners, Gitea Actions, Forgejo Actions, or multiple platforms are included;
  • repository/group/organization count and environment count;
  • runner size, expected concurrency, queue targets, storage, artifacts, cache, bandwidth, and private connectivity;
  • image maintenance depth, toolchain complexity, security review, and evidence requirements;
  • support hours, response targets, reporting cadence, change volume, and incident history;
  • urgency, migration risk, and whether emergency stabilization is required before planned work.

Assessment work is usually scoped around discovery and recommendations. Implementation work is scoped around delivery milestones. Retained operations are scoped around recurring responsibilities and support expectations. Emergency response is scoped around urgency, severity, and stabilization effort.

Evidence and handoff expectations#

ArtifactAssessmentImplementationRetained operationsEmergency response
Current-state findingsYesAs neededUpdated from operationsIncident-specific
Target architectureRecommendedImplemented designMaintainedFollow-up recommendation
Runner inventoryOptionalYesKept currentRecovery snapshot
Label/tag matrixOptionalYesGovernedTemporary changes recorded
Secrets boundary notesGap analysisYesReviewed periodicallyExposure notes if relevant
Monitoring linksRecommendationYesPrimary evidenceIncident timeline support
Change and rollback notesRecommendationYesRequired for changesRequired for recovery actions
Known limitationsYesYesUpdatedYes

These artifacts support customer assessment and operational continuity. They are not a substitute for customer legal, regulatory, procurement, or risk approval.

Limitations common to every model#

Assistance does not guarantee third-party CI platform availability, own customer repository code, rewrite CI workflows without scope approval, assume cloud-provider billing ownership, or make formal compliance/legal determinations by default. EU-focused controls and evidence can be prepared for customer review, but formal certifications or regulated compliance claims require an explicit separate process and authority.

Stronger SLA terms, 24/7 coverage, emergency-only access, account ownership, or regulated evidence obligations must be written into the statement of work or support agreement.

Choose the next step#

If the target state is unclear, start with an assessment. If the design is agreed, start an implementation project. If production runners already exist and need day-2 ownership, choose retained operations. If releases or security are actively blocked, use emergency response and convert follow-up actions into a planned runner engagement afterward.