Runners

Managed runner onboarding

Managed runner onboarding

Use this page to prepare a managed runner engagement with Assistance. It explains what information to gather, what decisions will be made, and what evidence should exist before a runner fleet is treated as production-ready.

Assistance supports managed runner onboarding for GitHub Actions, GitLab runners, Gitea Actions, and Forgejo Actions. The details differ by platform, but the onboarding shape is the same: define the shared responsibility boundary, design the fleet, validate representative jobs, document the operating model, and agree how support and changes work.

Service promise#

Assistance can design, deploy, operate, monitor, patch, and troubleshoot self-hosted runner capacity inside the agreed customer boundary. The outcome should be a runner fleet with clear routing labels or tags, documented security assumptions, known sizing limits, support paths, and handoff artifacts.

The customer keeps ownership of repository code, workflow logic, user approvals, risk decisions, cloud/SaaS accounts, and legal/compliance assessment unless a contract states otherwise.

Onboarding inputs#

Bring as much of this information as possible to the first intake:

InputWhy it matters
CI platformsConfirms whether the scope includes GitHub Actions, GitLab runners, Gitea Actions, Forgejo Actions, or a combination.
Repository scopeIdentifies organizations, groups, projects, protected branches, and workflow owners.
Current painSeparates speed, isolation, private access, cost, reliability, and governance problems.
Workload shapeEstablishes operating systems, architectures, toolchains, containers, Docker-in-Docker needs, job duration, and peak concurrency.
Private accessDocuments databases, package registries, deployment targets, VPNs, DNS, allowlists, and production access boundaries.
Secret classesClarifies which jobs need tokens, cloud credentials, deploy keys, signing material, or environment secrets.
Support modelDefines support channel, severity levels, hours, escalation contacts, change approvals, and reporting cadence.
Evidence needsLists diagrams, inventories, access records, test results, monitoring links, and handoff notes needed for internal assessment.

Onboarding journey#

1. Intake and scope#

Assistance confirms the platforms, repositories, owners, environments, expected timeline, business impact, and success criteria. This step also records what is outside scope so the runner service does not accidentally become ownership of application code, deployment approvals, or platform billing.

2. Current-state assessment#

The assessment reviews existing workflows, hosted runner usage, self-hosted runner history, queue times, failed jobs, secrets, images, cache behavior, artifact retention, private network dependencies, and incident history. For GitHub Actions and GitLab runners, include existing labels or tags. For Gitea Actions and Forgejo Actions, include how runners are registered and where Actions compatibility differs from the team's GitHub/GitLab expectations.

3. Fleet design#

The design records the choices that make the fleet operable:

  • topology — one fleet per environment, per sensitivity level, per platform, or per workload class;
  • sizing — CPU, memory, disk, network, maximum concurrency, autoscaling targets, and queue-time goals;
  • labels or tags — stable names for routing by platform, OS, architecture, environment, privilege, and special capability;
  • images — base image source, toolchain install method, custom image ownership, update cadence, and rollback plan;
  • caching and artifacts — cache key strategy, storage location, retention, cleanup, and poisoning or leakage controls;
  • secrets boundary — who owns secret values, which jobs can request them, and how logs/artifacts are checked for accidental exposure;
  • network access — egress policy, private DNS, VPN/private links, allowlists, and production reachability;
  • observability — health checks, queue depth, job failure signals, disk pressure, stale runner cleanup, and alert routing.

Use runner security hardening, runner monitoring and support, and troubleshooting to turn these decisions into operating controls.

4. Implementation and registration#

Assistance deploys the approved runner pattern, registers runners with the agreed platform, applies the label/tag scheme, validates sample jobs, and records the exact registration and rollback approach. Platform-specific notes belong in the relevant runbook, such as GitHub Actions, GitLab runners, Gitea Actions, or Forgejo Actions.

5. Production-readiness review#

Before go-live, Assistance and the customer confirm:

  • representative build, test, release, and deploy jobs run on the intended runner labels or tags;
  • secrets are scoped to the intended repositories, environments, and job types;
  • private network access works only where approved;
  • cache and artifact behavior matches retention and cleanup expectations;
  • monitoring, alerts, support channel, severity definitions, and escalation contacts are active;
  • known limitations, open risks, and follow-up actions are documented.

6. Handoff and operations#

Handoff should leave customer teams with a runner inventory, label/tag matrix, architecture notes, image baseline, cache/artifact policy, secrets boundary notes, monitoring dashboard links, support intake template, change workflow, rollback notes, and evidence pack for internal review.

Ongoing operations use the agreed support and change workflows. Standard changes might add labels, adjust concurrency, rotate tokens, update images, or change network allowlists. Urgent changes might address a blocked release, saturated queue, stuck runner, suspected secret exposure, or platform outage.

Pricing and planning inputs#

Assistance does not publish exact managed runner prices in this guide. Commercial scope depends on concrete inputs:

  • number of CI platforms and runner fleets;
  • number of repositories, groups, organizations, and environments;
  • expected concurrency, runner sizes, storage, bandwidth, and private connectivity;
  • support hours, response expectations, reporting cadence, and change frequency;
  • image maintenance, security review, compliance evidence, and handoff depth;
  • whether the engagement is assessment, implementation, retained operations, or emergency response.

These inputs help produce a grounded quote without inventing prices that may not match the customer environment.

Compliance and evidence boundaries#

Assistance can provide configuration records, architecture notes, access-review evidence, monitoring screenshots or links, change logs, incident notes, and EU-focused control recommendations for customer assessment. Assistance does not claim that a runner fleet is formally certified, legally compliant, or sufficient for a specific regulation unless that assessment is separately performed by the appropriate customer or third-party authority.

Start the engagement#

Open an onboarding request with platforms, repositories, current runner state, desired outcomes, deadline, private access needs, expected concurrency, and support expectations. Assistance will confirm the boundary and produce the next implementation or assessment step before production-impacting work begins.