Infrastructure
Infra GHA — self-hosted GitHub Actions on Fly.io
Org-level GitHub Actions runner infrastructure with Fly.io pools, live status, cache systems, and queue enforcement.
// stack
// area
// short answer
Infra GHA is a self-hosted GitHub Actions runner fleet on Fly.io with pool selection, queue visibility, cache services, and workflow enforcement for faster and more predictable CI.
3
Runner pools
Tiny, medium, and small/light pools serve different job classes.
faster CI
Primary outcome
Right-sized runners and cache layers reduce repeated cold work.
status app
Control plane
Queue and pool state are visible.
Infra GHA is the shared CI infrastructure behind TeamK2K repos: self-hosted GitHub Actions runners on Fly.io, a status dashboard, pool controls, remote cache systems, and guardrails for consumer workflows.
The project turns CI from a hidden cost center into visible infrastructure. Runner pools, queue pressure, cache behavior, and consumer workflow contracts are observable rather than left to GitHub queue mystery.
The refreshed case study uses the runner fleet and enforcement diagrams as first-class artifacts so readers can understand the system shape before reading implementation detail.
Problem
GitHub-hosted CI can be slow, expensive, and opaque when multiple repos need builds, tests, Docker, browsers, and deploys. The pain is not only runtime; it is not knowing whether jobs are waiting for capacity, using the wrong runner size, or missing cache contracts.
The organization needed shared infrastructure that could serve consumer repos without turning every repo into its own CI experiment.
System
The runner fleet runs on Fly.io with different pools for different job shapes. A status app observes queue pressure and pool state, while composite actions help consumer repos choose the right labels, setup, cache, and deploy patterns.
The system includes node_modules cache support, Turborepo remote cache infrastructure, pool guards, workflow linting, and documentation that keeps CI contracts explicit.
What shipped
The repo includes runner Docker images, Fly machine configs, hooks, cache services, a status dashboard, and reusable GitHub Actions composites. The refreshed case study adds the missing narrative layer around why those pieces exist.
The gallery includes runner fleet and enforcement diagrams so the operational model is visible at a glance.
SEO angle
Search volume was sparse for the exact Fly.io runner phrase, but the page targets a high-intent technical query. The copy should prioritize implementation clarity over broad traffic.
// search questions
Why use self-hosted GitHub Actions runners?
Self-hosted runners give teams more control over machine size, cache strategy, installed dependencies, and cost profile. They are useful when hosted runners are too slow, too expensive, or too opaque for heavy CI.
Why run GitHub Actions runners on Fly.io?
Fly.io makes it practical to run regional machines with configurable sizes and lifecycle control. For CI, that enables warm pools, on-demand capacity, and infrastructure that can be observed and tuned.