A Self-Hosted GitHub Actions Runners

Introduction

GitHub Actions provides a powerful and flexible platform for automating workflows directly within your GitHub repositories. You can set up a self-hosted runner to enhance the capabilities of GitHub Actions and execute workflows on your own infrastructure. In this blog post, we’ll guide you through configuring and deploying a self-hosted GitHub Actions runner.

Self-Hosted Runner

Benefits

Using self-hosted runners in GitHub Actions provides several benefits, especially when using GitHub’s hosted runners. Here are some advantages of using self-hosted runners:

Control Over Execution Environment:

• Customization: With self-hosted runners, you have complete control over the execution environment. You can customize the machine’s operating system, installed software, and configurations to match the requirements of your workflows.
• Persistent State: Stateful configurations, such as installed dependencies or cached data, can persist across workflow runs on the same self-hosted runner, potentially saving time and resources.

Cost Efficiency:

• Resource Utilization: You can utilize existing infrastructure, such as on-premises servers or dedicated cloud instances, as self-hosted runners. This approach can result in cost efficiencies compared to using GitHub’s hosted runners, which is particularly beneficial for expansive projects or continuous integration (CI) pipelines that impose substantial resource requirements.

Increased Security:

• Isolation: Self-hosted runners operate within your network environment, providing an additional isolation layer. This can be important for projects with specific security requirements or restrictions.
• Access Control: You have control over access permissions for the self-hosted runners. This allows you to manage who can trigger workflows and deploy code on your infrastructure.

Reduced Latency:

• Proximity: Self-hosted runners can be placed near your code repositories and other resources, reducing network latency. This can result in faster workflow execution times than hosted runners in GitHub’s data centers.

Compatibility:

• Compatibility with Legacy Systems: For projects with specific dependencies or legacy systems, self-hosted runners offer the flexibility to maintain compatibility with existing infrastructure and tools.

Scalability:

• Scaling Resources: You can scale your self-hosted runner infrastructure horizontally by adding more machines or vertically using more powerful hardware. This provides the ability to handle increased workload and concurrency.

Offline Workflows:

• Air-Gapped Environments: In scenarios where internet access is restricted or prohibited, self-hosted runners allow you to run workflows in air-gapped environments without relying on externally hosted runners.

Resource Limits and Quotas:

• Avoiding Shared Resource Limits: Self-hosted runners operate independently of GitHub’s hosted runner resource limits. This can benefit projects with resource-intensive workflows that may exceed the limitations of GitHub’s hosted runners.

Self-hosted runners can be incorporated at different tiers within the management hierarchy

• Repository-Level Runners: These runners are specifically designated for a single repository, providing a dedicated environment tailored to the needs of that particular codebase.
• Organization-Level Runners: Organization-level runners extend their functionality to process jobs across multiple repositories within an organization. This enables a more centralized and shared resource for CI/CD workflows.
• Enterprise-Level Runners: Enterprise-level runners offer the highest level of scalability by being assignable to multiple organizations within an enterprise account. This allows efficient resource utilization across diverse projects and teams within the larger organizational structure.

Distinguishing between GitHub-hosted and Self-hosted runners

GitHub-hosted runners offer a streamlined and straightforward approach to executing workflows, whereas self-hosted runners provide a highly adaptable method to run workflows within a personalized environment.

GitHub-hosted runners:

• Benefit from automatic updates for the operating system, preinstalled packages, tools, and the self-hosted runner application.
• Are under the management and maintenance of GitHub.
• Provide a fresh instance for each job execution.
• Utilize free minutes on your GitHub plan, with per-minute rates applied after surpassing the free minutes.

Self-hosted runners:

• Receive automatic updates for the self-hosted runner application, giving you control over turning automatic updates on or off.
• Have the flexibility to use cloud services or local machines you may already be paying for.
• It can be tailored to your hardware, operating system, software, and security specifications.
• Do not require a clean instance for every job execution.
• You are free to use GitHub Actions, but you are responsible for the expenses of maintaining your runner machines.

Usage of GitHub Actions with self-hosted runners is subject to certain limitations, and these constraints may change over time.

Workflow Run Time Limit: Each workflow run is restricted to 35 days. If a workflow run surpasses this time limit, it will be automatically canceled. This timeframe encompasses the execution duration and the time spent in waiting and approval processes.

Job Queue Time Limit: Jobs assigned to self-hosted runners that remain in the queue for at least 24 hours will be canceled. The time spent in the queue can extend to 48 hours before automatic cancellation takes effect. Failure to initiate the job within this timeframe results in termination and an unsuccessful completion.

API Requests Limit: There is a limit of 1,000 requests to the GitHub API per hour for all actions within a repository. Exceeding this limit will result in additional API calls failing, potentially causing job failures.

Job Matrix Limit: A job matrix has a maximum capacity of generating 256 jobs per workflow run, applicable to both GitHub-hosted and self-hosted runners.

Workflow Run Queue Limit: A repository is restricted to queuing no more than 500 workflow runs within a 10-second interval. The workflow run will be terminated and deemed incomplete if this limit is reached.

Registering Self-hosted Runners Limit: The maximum allowable number of self-hosted runners within a single runner group is 10,000. Once this limit is reached, adding new runners to the group becomes impossible.

Conclusion

Setting up a self-hosted GitHub Actions runner allows you to customize your workflow environment and use your infrastructure for CI/CD processes. With the flexibility and control provided by self-hosted runners, you can tailor the execution environment to meet the specific requirements of your projects.

The flexibility self-hosted runners provide allows organizations to leverage their resources efficiently, enabling customization of the operating system, installed software, and configurations. This is particularly advantageous for projects with unique dependencies or those operating in secure environments where strict access controls are crucial.

Keep your self-hosted runner software up-to-date to leverage the latest features and security enhancements. Regular updates are essential for maintaining optimal performance and safeguarding against potential vulnerabilities.

Drop a query if you have any questions regarding GitHub and we will get back to you quickly.

About CloudThat

CloudThat is a leading provider of Cloud Training and Consulting services with a global presence in India, the USA, Asia, Europe, and Africa. Specializing in AWS, Microsoft Azure, GCP, VMware, Databricks, and more, the company serves mid-market and enterprise clients, offering comprehensive expertise in Cloud Migration, Data Platforms, DevOps, IoT, AI/ML, and more.

CloudThat is recognized as a top-tier partner with AWS and Microsoft, including the prestigious ‘Think Big’ partner award from AWS and the Microsoft Superstars FY 2023 award in Asia & India. Having trained 650k+ professionals in 500+ cloud certifications and completed 300+ consulting projects globally, CloudThat is an official AWS Advanced Consulting Partner, AWS Training Partner, AWS Migration Partner, AWS Data and Analytics Partner, AWS DevOps Competency Partner, Amazon QuickSight Service Delivery Partner, Amazon EKS Service Delivery Partner, Microsoft Gold Partner, AWS Microsoft Workload Partners, Amazon EC2 Service Delivery Partner, and many more.

To get started, go through our Consultancy page and Managed Services Package, CloudThat’s offerings.