Runners

Runs On

Runs On

Assistance designs and operates self-hosted CI/CD runner capacity inside the agreed cloud, network, and repository boundary. This page explains the user-facing operating model for runs on: what Assistance can operate, what the customer owns, and how onboarding, support, changes, and escalation work.

When to use this#

Use this when CI/CD jobs need self-hosted capacity, stronger isolation, predictable performance, private-network access, or managed troubleshooting.

Good fits include:

  • teams that need a documented operating boundary before production changes;
  • retained DevOps, SRE, DevSecOps, or platform support where day-2 ownership must be explicit;
  • audit, release, migration, or incident work where decisions and evidence need to be traceable.

This is not a generic vendor manual. Vendor-specific commands belong in the customer runbook only when they are part of the agreed workflow.

What Assistance operates#

Within the agreed engagement boundary, Assistance can operate or support:

  • runner pool design, labels, scaling rules, image baseline, secrets boundaries, monitoring, patching, and queue/failure triage;
  • onboarding checklists, implementation plans, and production-readiness reviews;
  • monitoring signals, alert routing, runbook updates, and incident triage;
  • planned change requests, maintenance-window preparation, and rollback notes;
  • handoff documentation so customer teams understand how to request help and approve changes.

What the customer owns#

The customer remains responsible for:

  • business priorities, launch timing, acceptance criteria, and internal approvals;
  • cloud, SaaS, identity, repository, and billing accounts unless a different ownership model is contracted;
  • application code, data classification, user access approvals, and product communications;
  • legal, regulatory, procurement, and risk decisions based on Assistance-provided evidence.

Engagement models#

ModelBest forTypical Assistance role
Assessment or auditTeams that need a short, evidence-backed planReview current state, identify risks, and provide prioritized recommendations
Implementation projectTeams making a defined platform, delivery, security, or docs changeDesign, build, migrate, validate, and hand over the workflow
Retained operationsTeams that need ongoing DevOps, SRE, DevSecOps, or platform supportOperate agreed components, manage changes, and drive continuous improvement
Emergency responseTeams facing an outage, blocked release, security event, or urgent migrationStabilize, coordinate escalation, document recovery, and produce follow-up actions

Onboarding workflow#

  1. Intake — confirm systems, owners, environments, repositories, providers, risk level, and success criteria.
  2. Assessment — review current runbooks, access, alerts, deployment flow, security controls, and known incidents.
  3. Operating boundary — agree what Assistance operates, what the customer owns, support hours, severity definitions, and approval paths.
  4. Implementation — apply the agreed changes with reviewable pull requests, change records, and rollback plans.
  5. Go-live or handoff — validate the workflow, publish runbooks, confirm escalation contacts, and schedule the first review.
  6. Operate and improve — use incidents, failed changes, support tickets, and audits to maintain an improvement backlog.

Support and change requests#

Route requests through the agreed support channel with environment, affected service, business impact, urgency, recent changes, and relevant logs or screenshots.

Request typeExamplesExpected workflow
Standard changeconfiguration update, runner label, access review, docs updateTriage, scope, approve, schedule, implement, and record outcome
Urgent changeblocked release, failing production pipeline, capacity exhaustionClassify severity, stabilize, communicate cadence, implement safest recovery path
Advisory requestarchitecture question, compliance evidence, migration optionClarify decision, provide recommendation, document assumptions and trade-offs
Incidentoutage, suspected compromise, severe data or delivery impactOpen incident channel, assign roles, preserve evidence, recover service, publish follow-up notes

Not included by default#

Assistance does not own repository code, job logic, third-party CI service availability, or cloud-provider billing unless contracted separately.

Any stronger SLA, regulated compliance claim, 24/7 coverage, legal responsibility, or provider-account ownership must be written into the statement of work or support agreement.

Getting started#

Open a support or onboarding request with the service area, current environment, desired outcome, deadline, and known risks. Assistance will confirm the operating boundary before making production-impacting changes.