Runners

Managed runners overview

Managed runners overview

Assistance provides managed self-hosted CI/CD runner capacity as part of facilitated local-development and delivery-platform workflows. The service is for teams that need predictable builds, private-network access, clearer security boundaries, and day-2 operations support. It covers runner fleets for GitHub Actions, GitLab runners, Gitea Actions, and Forgejo Actions when the platform, cloud account, network, and repository boundary are agreed during onboarding.

The promise is practical rather than magical: Assistance designs, deploys, monitors, patches, and troubleshoots the runner layer so customer teams can keep shipping. The customer still owns the application code, workflow intent, repository policy, secrets approval, risk acceptance, and business approvals.

What the service includes#

Managed runners usually combine design, implementation, operations, and handoff work:

  • runner fleet architecture for one or more CI platforms, including pools, isolation model, labels or tags, image baseline, scaling policy, and environment split;
  • implementation through reviewable changes, documented bootstrap steps, and production-readiness checks;
  • monitoring, queue/failure triage, patch planning, security hardening, and support workflows;
  • cache, artifact, image, and dependency strategy aligned to the customer's repositories and network boundaries;
  • evidence and handoff artifacts so customer owners can assess controls, approve changes, and operate their side of the model.

Start with managed runner onboarding if you are preparing a new fleet, or use runner engagement model comparison when deciding between an audit, implementation, or retained operations model.

Supported CI platforms#

PlatformRunner termsTypical use
GitHub Actionsself-hosted runners, runner groups, labelsPrivate builds for GitHub repositories and organizations where job routing is controlled with labels. See GitHub Actions.
GitLab runnersrunners, tags, executorsGitLab projects, groups, or instances where tags select build capacity. See GitLab runners.
Gitea Actionsself-hosted runners, labelsLightweight Git hosting environments that need Actions-compatible execution close to private services. See Gitea Actions.
Forgejo Actionsself-hosted runners, labelsForgejo-hosted repositories that need self-managed Actions capacity and clear operational ownership. See Forgejo Actions.

Assistance can support more than one platform in the same engagement, but each platform needs explicit registration, token ownership, label/tag conventions, and failure escalation paths.

Local-development platform patterns#

Runner fleets are often delivered together with Managed Git Server, Managed Mattermost, artifact/cache services, and environment-parity runbooks. In that model, Assistance documents the whole local-development boundary: where code is hosted, where builds run, where delivery notifications go, who approves secrets, and how incidents or change requests are handled.

Managed git server runner patterns#

When Assistance also operates the git server, runner design is documented as part of the platform handoff rather than treated as a detached CI project.

Managed git serverCustom runner patternStart here
GitLabGitLab Runner tags, project/group/instance scope, protected runners, and executor choice control where jobs run.GitLab option runbook and GitLab runners
GerritGerrit emits change and patch-set events; verification workers usually sit behind Jenkins, Zuul, Tekton, or a custom CI adapter that reports labels back to Gerrit.Gerrit option runbook, runner troubleshooting, and monitoring
GiteaGitea Actions uses runs-on labels for self-hosted runner selection; registration scope and Actions compatibility are environment-specific.Gitea Actions
ForgejoForgejo Actions uses runs-on labels for self-hosted runner selection; validate workflow syntax, token behavior, cache, and artifact support on the installed version.Forgejo Actions

Use this table for navigation only. The platform pages remain the source of truth for setup, token handling, examples, and troubleshooting details.

Shared responsibility model#

AreaAssistance usually ownsCustomer usually owns
Runner infrastructureFleet design, provisioning pattern, image baseline, scaling guidance, patch workflow, monitoring integrationCloud or hosting account, budget approvals, region/provider decisions, account-level policies
CI platform integrationRunner registration plan, label/tag scheme, queue triage, platform-specific runbook notesRepository and organization administration, workflow definitions, protected branches, approvals
Security boundaryHardening recommendations, least-privilege runner access, secret exposure review, evidence collectionData classification, user access approvals, secret values, risk acceptance, legal/compliance decisions
OperationsSupport intake, incident triage, change records, rollback notes, handoff documentationBusiness priority, release decisions, internal communication, product ownership

Assistance does not claim formal certifications or legal compliance for the customer environment. Assistance can provide evidence, EU-focused control recommendations, configuration records, and operational artifacts that customer security, procurement, and legal teams can assess.

Runner fleet design choices#

A managed runner design normally makes these choices explicit before production use:

  • Isolation model — dedicated customer fleet, environment-specific pools, or more granular pools for sensitive workloads.
  • Sizing and concurrency — baseline CPU, memory, disk, network, and maximum concurrent jobs based on actual pipeline behavior and queue targets.
  • Labels and tags — stable routing names for platform, operating system, architecture, environment, privilege level, and special capabilities.
  • Images — approved base images, toolchain installation method, update cadence, vulnerability response, and ownership for custom build images.
  • Caching and artifacts — cache location, retention, poisoning risk, artifact storage, bandwidth limits, and cleanup policy.
  • Secrets boundary — which jobs can access which secrets, how secrets are injected, and how logs/artifacts are reviewed for leakage risk.
  • Network access — egress policy, private service reachability, DNS, allowlists, VPN or private connectivity, and whether runners can reach production systems.
  • Failure handling — queue saturation thresholds, stuck runner cleanup, job retry guidance, platform outage escalation, and rollback triggers.

Security-specific controls are tracked with runner security hardening, monitoring with runner monitoring and support, and failure investigation with troubleshooting.

Onboarding journey#

  1. Intake — confirm platforms, repositories, current pipeline pain, owners, environments, regions, private access needs, and deadline.
  2. Assessment — review existing workflows, runner usage, secrets, network dependencies, cache/artifact behavior, incident history, and support expectations.
  3. Design — agree fleet topology, labels or tags, image baseline, sizing, scaling, security boundaries, observability, and handoff artifacts.
  4. Implementation — deploy runners, register them with the CI platform, validate sample jobs, document changes, and prepare rollback notes.
  5. Production readiness — test representative workloads, confirm monitoring and support channels, record known limitations, and get customer approval.
  6. Operate and improve — review queue times, failures, cost drivers, security findings, and requested changes on the agreed cadence.

Pricing inputs#

Exact prices depend on the signed statement of work and hosting choices. Assistance scopes managed runners using inputs such as:

  • number of platforms, repositories, organizations/groups, and environments;
  • expected concurrency, runner sizes, storage, bandwidth, and private connectivity;
  • required support hours, response targets, reporting cadence, and change volume;
  • image maintenance complexity, security review depth, and evidence/handoff requirements;
  • whether the work is an assessment, implementation project, retained operations engagement, or emergency response.

Do not treat this page as a price list. Use it to prepare the technical and operating inputs needed for a quote.

Evidence and handoff artifacts#

Typical deliverables include architecture notes, runner inventory, label/tag matrix, platform registration records, secrets boundary notes, monitoring dashboard links, alert routing, support intake template, change/rollback records, and known limitations. These artifacts help customer teams evaluate controls and operate their responsibilities after handoff.

Clear limitations#

Assistance does not own customer application code, CI workflow logic, third-party CI platform availability, cloud-provider billing, procurement approvals, or legal/regulatory determinations unless explicitly contracted. Stronger SLA terms, 24/7 coverage, regulated compliance commitments, provider-account ownership, and emergency-only access models must be written into the engagement agreement.

Getting started#

Open an onboarding request with the CI platforms, repositories, current runner setup, required private access, expected concurrency, support expectations, deadline, and known risks. Assistance will confirm the shared responsibility boundary before making production-impacting changes.