Runnerly · Private working system

Self-hosted runners, without guesswork.

Runnerly is a live, GitHub-authenticated control room for CaeliCode's self-hosted GitHub Actions runners. It combines current runner and job telemetry with GitHub App reconciliation, live browser updates, policy guardrails, and reviewable operational evidence.

Discuss Runnerly See how it works

Status Private working system Access GitHub authentication Live scope Fleet, jobs, policy, evidence

runnerly.caelicode.com authenticated session

Fleet Policy Jobs Evidence

Connection Live

Fleet state Currenttimestamped

Policy view Activeevaluated

Evidence Readyexportable

Sanitized Runnerly fleet operations example
Runner	Labels	Status	Last beat	Current job
runner alias A host details withheld	self-hosted private lane sanitized	Online	recent	private job · redacted
runner alias B host details withheld	self-hosted private lane sanitized	Online	recent	state withheld
workflow_job · queued private repository → workflow	self-hosted assigned lane	Queued	recent	awaiting runner pickup

workflow_job → runner → repository policy identifiers sanitized

Case-study boundary Runnerly and the self-hosted runners visible through its authenticated dashboard are real. Access is private and requires GitHub authentication. Public examples are sanitized reconstructions: they preserve the verified data relationships without disclosing runner names, repositories, jobs, identities, infrastructure, or dynamic fleet totals. This is a staging-system case study, not a customer, adoption, uptime, scale, or certification claim.

What it is

A private operations surface for the runner layer GitHub doesn't manage for you.

The authenticated staging system now combines fleet state, GitHub events, correction loops, policy visibility, and evidence operations. Each public example below preserves the live relationship while withholding private values.

01 · LIVE AND AUTHENTICATED

Runner and job telemetry

GitHub OAuth protects the dashboard. Authorized views display real organization-scoped runners, current status and labels, repository and workflow inventory, and correlated job state. The example is a schema-level reconstruction, not a copied private record.

# Authenticated state shape · values sanitized
{
  "runner":      "sanitized alias",
  "status":      "current GitHub state",
  "labels":      ["self-hosted", "assigned lane"],
  "job":         "private reference withheld",
  "observed_at": "timestamped"
}

02 · LIVE CONTROL LOOP

GitHub App reconciliation

Signed webhook events provide a fast path. GitHub App polling refreshes runner state, while a slower full reconciliation repairs missed events and stale repository or group data. Server-sent events update the signed-in browser when control-plane state changes.

webhookworkflow and repository events

runner refreshstatus · busy state · labels

full reconcilerunners · groups · repositories

browserlive SSE updates

confidencetimestamp each source

03 · LIVE POLICY VIEW

Execution guardrails

Repository visibility is a first-class input. Public repositories remain telemetry-only and are expected to use GitHub-hosted execution. Private repositories can enter an assigned lane through restricted runner-group and workflow settings.

# Live policy model · no private repositories shown
public repository
  expected lane  → github-hosted
  self-hosted job → policy violation

private repository
  specific lane  → allowed path
  broad label    → policy warning

04 · LIVE EVIDENCE OPERATIONS

Exports, audit, and backups

Authenticated operators can review normalized jobs, events, runner correlation, and application audit activity; export selected evidence as JSON or CSV; and create retained SQLite backups with restore tooling.

job contextrepository · labels · runner

event contextdelivery · state transition

exportsJSON · CSV

storagelocal SQLite

boundarynot tamper-proof or offsite

Architecture

GitHub schedules the work. Runnerly makes the runner fleet visible.

The deployed control plane combines GitHub webhooks, GitHub App state reconciliation, local normalized storage, policy evaluation, and a GitHub-authenticated dashboard. GitHub remains the workflow scheduler and source of organization state.

Swipe or scroll horizontally to inspect the architecture at full size.

Live · State inputs

GitHub webhooks supply fast events; GitHub App refresh and reconciliation correct state.

Live · Local record

SQLite stores normalized operational state, application audit events, and backup snapshots.

Live · Operator surface

GitHub OAuth protects the dashboard; SSE updates the browser and JSON/CSV exports preserve evidence.

Guardrails

Working now. Precise about the remaining boundary.

The live staging surface is broader than runner inventory alone. This boundary separates what was observed operating, what exists in code but was not exercised end to end, and what remains future work.

Live and verified

What is operating.

GitHub OAuth and organization authorization
Real runner inventory and workflow-job telemetry
GitHub webhook and App reconciliation paths
SSE live updates for authenticated browsers
Repository, lane, and runner-group policy views
JSON/CSV evidence exports and local backups

Implemented, not exercised

What exists but was not demonstrated.

GitHub App registration-token endpoint
Runner software installation workflow
Optional machine and service telemetry agent
Backup restoration workflow reviewed in code but not exercised
End-to-end enrollment and recovery outcomes

Planned or not claimed

What remains outside the verified system.

Complete create, rotate, drain, and remove lifecycle
Signed per-agent enrollment and credential rotation
Highly available or multi-tenant control plane
Offsite backup durability or tamper-evident storage
External customer deployments or adoption
Compliance certification or scale claims

Verified operating flow

Fast events, periodic correction, one timestamped view.

The current control loop deliberately combines event-driven updates with authoritative refresh. The public checks at right establish the live process and authentication boundary without exposing the dashboard.

Receive GitHub events

Repository, workflow-job, and workflow-run events enter through the configured GitHub webhook and update normalized state.

Live event path

Refresh runner state

GitHub App access supplies current runner status, busy state, labels, and group information independently of job events.

Live correction path

Reconcile and evaluate

A full correction cycle refreshes runners, groups, repositories, and policy inputs so missed events do not become permanent truth.

Live state model

Publish authorized updates

Server-sent events refresh the GitHub-authenticated dashboard; selected evidence can be exported and local state can be backed up.

Live operator path

runnerly · public boundary · verified

# Anonymous request · safe public surface GET /api/health 200 { "ok": true, "service": "runnerly-control-plane" } GET /api/auth/status 200 { "authRequired": true, "authenticated": false, "github": true } # Anonymous request · protected operations GET /api/overview 401 { "error": "unauthorized" } # After GitHub authentication ✓ membership and authorization checked ✓ fleet, jobs, policy, evidence available ✓ browser receives live SSE updates

Operating questions

The boring answers, up front.

Is Runnerly a replacement for GitHub Actions?

No. GitHub Actions schedules workflows and remains the source of organization runner state. Runnerly adds an authenticated operating view, event processing, state reconciliation, policy visibility, and evidence operations around the self-hosted runner layer.

Is Runnerly a real working system?

Yes. Runnerly is deployed privately, authenticates through GitHub, and displays actual organization-scoped self-hosted runners and job state. The dashboard also shows live reconciliation, policy, exports, audit activity, and backups. This public page uses sanitized reconstructions instead of private operational values.

Does Runnerly host my runners?

No. The runners remain self-hosted outside the control-plane host. Runnerly observes and reconciles their GitHub state. An optional host telemetry agent exists in the implementation, but that path was not exercised end to end for this public case study.

What is implemented for runner enrollment?

The implementation includes a GitHub App registration-token endpoint and a runner installation workflow, but enrollment was not exercised end to end during the verification behind this page. GitHub controls the registration token's documented lifetime. Dashboard revocation and identity-bound enrollment were not demonstrated; signed per-agent enrollment remains planned.

Where do state and evidence live?

The current control plane uses local SQLite for normalized state, application audit events, and retained backups. Authorized operators can export selected evidence as JSON or CSV. These records are not presented as cryptographically tamper-evident, and local backups are not an offsite durability claim.

Is Runnerly open source?

No public Runnerly repository or license is currently claimed. The implementation and working dashboard are private. Public evidence is limited to the live health and authentication boundary, this sanitized case study, and the evidence-led engineering note.

What remains planned?

Complete runner lifecycle control, signed per-agent enrollment, high availability, multi-tenant isolation, offsite backup durability, and stronger tamper evidence remain outside the verified system. This page makes no customer, adoption, uptime, scale, or compliance-certification claim.

Private platform engineering

Start with the working system, then inspect its boundaries.

Runnerly combines real authenticated fleet operations with reconciliation, policy visibility, and evidence controls—while keeping planned lifecycle and scale work explicit.

Discuss Runnerly Read the engineering note