RunsOn: High-Performance AWS Self-Hosted Infrastructure for GitHub Actions

The modern continuous integration and continuous deployment (CI/CD) landscape is often characterized by a tension between convenience and cost. While GitHub-hosted runners offer a seamless "plug-and-play" experience, organizations frequently hit a wall where the cost of scaling these runners becomes prohibitive, or the performance of standard virtual machines fails to meet the demands of heavy compilation and testing. RunsOn emerges as a high-performance architectural alternative, specifically engineered to migrate GitHub Actions runner infrastructure into a user's own Amazon Web Services (AWS) account. By shifting the execution environment from GitHub's managed pool to a privately owned AWS ecosystem, RunsOn allows enterprises to regain full control over their compute resources, networking models, and image specifications while drastically reducing operational expenditure.

The core philosophy of RunsOn is the elimination of the "black box" nature of hosted CI. Instead of relying on a third-party provider that requires broad access to sensitive code and secrets, RunsOn utilizes a private GitHub App created specifically for the organization during the setup process. This ensures that the trust boundary remains within the organization's own cloud perimeter. The transition from a standard GitHub-hosted environment to RunsOn is designed to be nearly transparent; users can move from runs-on: ubuntu-latest to a specific RunsOn configuration, such as runs-on: runs-on/runner=2cpu-linux-x64, without needing to rewrite the underlying logic of their workflows, caching mechanisms, or custom actions.

Economic and Performance Advantages of AWS Integration

The migration to RunsOn is primarily driven by the pursuit of extreme cost efficiency and raw hardware performance. In the standard GitHub-hosted model, users pay a premium for the convenience of managed infrastructure. RunsOn disrupts this by leveraging the native pricing models of AWS, including the ability to use Spot Instances, which can lead to catastrophic reductions in monthly CI spend.

The financial impact is substantial. Data indicates that RunsOn is designed to reduce GitHub Actions costs dramatically, with typical savings ranging from 7x to 15x compared to the costs associated with GitHub-hosted runners. For example, real-world implementation by industry professionals has shown cost reductions of approximately 70% to 75%. This is achieved by eliminating the markup associated with managed runners and allowing the user to pay the raw AWS EC2 price.

Beyond cost, the performance gains are measurable. Raw CPU performance on RunsOn is up to 30% higher than that of official GitHub-hosted runners. This increase in throughput directly translates to faster build times. When combined with the ability to deploy "gigantic" spot instances, some organizations have reported that their test suites run up to 5x faster. The impact of this is a tighter feedback loop for developers, reducing the time spent waiting for CI pipelines to clear and increasing overall engineering velocity.

Technical Architecture and Deployment Workflow

RunsOn is engineered for rapid deployment and low operational overhead. Unlike complex Kubernetes-based solutions such as the Actions Runner Controller (ARC), which require significant cluster management, RunsOn is deployed via a streamlined infrastructure-as-code approach.

The installation process is centered around a single CloudFormation template and a set of accompanying public templates available in the project's public repository. This architecture allows a full production-ready environment to be deployed in approximately 10 minutes. The deployment process installs the necessary orchestration logic directly into the user's AWS account, ensuring that the infrastructure is fully owned and managed by the customer.

By owning the infrastructure, users gain flexibility that is unavailable in hosted environments:

• Choice of Instance Types: Users can select the exact AWS instance family (e.g., Compute Optimized, Memory Optimized, or General Purpose) that fits their specific workload.
• Networking Control: The networking model can be tailored to the organization's needs, allowing runners to sit within a specific VPC for secure access to internal databases or services.
• Custom Images: While RunsOn supports public Amazon Machine Images (AMIs), users have the freedom to bring their own custom-baked images containing pre-installed dependencies, further reducing build setup time.

The RunsOn Action and Advanced Feature Set

To unlock the full potential of the platform, the runs-on/action@v2 must be integrated into the workflow. This action serves as the bridge between the GitHub job and the specialized capabilities of the RunsOn infrastructure.

Magic Caching and S3 Integration

One of the most powerful features of the ecosystem is "magic caching," which is activated by adding the extras=s3-cache label to the job configuration. When this feature is enabled, the runs-on/action@v2 must be included in the workflow steps to manage the cache lifecycle.

The system provides an integrated S3 cache bucket that comes free with the RunsOn installation. This bucket is designed for "blazing fast" download speeds and offers unlimited storage, removing the restrictive quotas often found in standard GitHub Actions caching.

For developers working with C/C++, Rust, or NVIDIA CUDA, RunsOn provides specialized support for sccache. By configuring the action with sccache: s3, RunsOn automatically configures the S3 cache backend for sccache. This removes the need for manual environment variable configuration. Under the hood, the action executes the following configuration:

bash echo "SCCACHE_GHA_ENABLED=false" >> $GITHUB_ENV echo "SCCACHE_BUCKET=${{ env.RUNS_ON_S3_BUCKET_CACHE}}" >> $GITHUB_ENV echo "SCCACHE_REGION=${{ env.RUNS_ON_AWS_REGION}}" >> $GITHUB_ENV echo "SCCACHE_S3_KEY_PREFIX=cache/sccache" >> $GITHUB_ENV echo "RUSTC_WRAPPER=sccache" >> $GITHUB_ENV

This integration allows for a seamless transition where the mozilla-actions/[email protected] can be used in conjunction with the RunsOn S3 backend to accelerate slow Rust compilations.

Cost Transparency and Analysis

RunsOn provides a built-in mechanism to track the exact cost of every workflow job, a feature typically missing from hosted CI providers. By utilizing the https://ec2-pricing.runs-on.com API, the system calculates accurate data for both on-demand and spot pricing across all AWS regions and availability zones.

The cost analysis can be output in two formats: inline (displayed in the action log) or summary (displayed in the GitHub job summary). The system not only calculates the actual cost but also provides a comparison against the equivalent GitHub-hosted machine.

Example of the cost metric output:

Telemetry and Performance Monitoring

For organizations that require deep visibility into their CI resource utilization, RunsOn supports the transmission of additional metrics via the CloudWatch agent. This is available for Linux runners and is fully functional in version 2.8.4 and above.

By configuring the metrics parameter in the action, users can track a wide array of system data:

• CPU: Tracks usage_user and usage_system.
• Network: Tracks bytes_recv and bytes_sent.
• Memory: Tracks used_percent.
• Disk: Tracks used_percent and inodes_used.
• I/O: Tracks io_time, reads, and writes.

These metrics are rendered as live charts in the post-execution summary, allowing DevOps engineers to identify bottlenecks or over-provisioned instances. For example, a user can specify metrics: cpu,network,memory,disk,io to get a comprehensive view of the job's resource footprint.

Comparison of Infrastructure Models

The following table illustrates the technical and operational differences between standard GitHub-hosted runners and the RunsOn AWS-native approach.

Workflow Implementation Examples

To implement RunsOn, the user must modify the runs-on field in their GitHub Actions YAML file. Instead of using a generic label, they use a structured string that defines the runner specifications and any additional extras.

Basic Job Configuration

A standard job utilizing a 2-CPU Linux runner would be defined as follows:

yaml jobs: build: runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64 steps: - uses: actions/checkout@v4 - run: echo "Running on high-performance AWS infrastructure"

Advanced Configuration with Caching and Telemetry

For a complex build requiring S3 caching and detailed resource monitoring, the configuration expands to include the extras label and the runs-on/action step:

yaml jobs: build: runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/extras=s3-cache steps: - uses: runs-on/action@v2 with: metrics: cpu,network,memory,disk,io sccache: s3 show_env: true - uses: mozilla-actions/[email protected] - run: cargo build --release

In this configuration:
- runs-on=${{ github.run_id }} ensures a unique runner for the job.
- extras=s3-cache enables the high-speed S3 backend.
- show_env: true allows the developer to debug the environment variables available to the action.
- metrics provides a full telemetry suite in the job summary.

Analysis of the CI/CD Ecosystem Impact

The introduction of RunsOn represents a shift toward "sovereign CI." By decoupling the orchestration of the workflow (GitHub Actions) from the execution of the compute (AWS), organizations can optimize for the specific constraints of their project.

The impact is most visible in large-scale projects where thousands of jobs are run daily. In such environments, a 70% to 80% reduction in runtime and a 4x reduction in cost is not merely a marginal gain but a transformative operational victory. The ability to use "gigantic" spot instances allows for parallelization strategies that would be cost-prohibitive on hosted runners, effectively turning the CI pipeline from a bottleneck into a competitive advantage.

Furthermore, the use of a private GitHub App for authentication solves the historical security concerns associated with self-hosted runners. Traditionally, self-hosted runners required manual token management or broad permissions. RunsOn automates this via a scoped app, maintaining the security posture of the organization while providing the flexibility of a private cloud.

Conclusion

RunsOn transforms the GitHub Actions experience by migrating the execution layer to a user-controlled AWS environment. This transition provides a triple-win: significant cost reduction through raw EC2 pricing, increased performance via optimized hardware and custom AMIs, and enhanced security through private infrastructure ownership. By integrating the runs-on/action@v2, users gain access to professional-grade telemetry, transparent cost analysis, and high-performance S3 caching, including specialized support for sccache. The system's ability to be deployed in under 10 minutes via CloudFormation makes it a viable alternative to more complex Kubernetes-based runner controllers, offering a streamlined path to high-efficiency CI/CD.

Sources

1. RunsOn GitHub Repository
2. RunsOn Action GitHub Repository
3. RunsOn Official Website
4. GitHub Actions Features