Running CI jobs on self-hosted infrastructure

The first continuous integration (CI) tools were all self-hosted, meaning they ran on a developer’s local computer or server. This setup was well received by dev teams at the time, but it has limited flexibility. Developers had to spend time maintaining the infrastructure, diverting focus away from actual development and reducing overall productivity.

As a result, many teams moved to cloud-hosted CI. Cloud-hosted CI is the best choice for most dev teams. It offers a flexible and scalable centralized platform to build and test software in the most common environments.

Even teams that have moved to the cloud may have compliance or compute needs that keep them from running every job there. In these situations, developers turn to self-hosted CI infrastructure.

This article explains what self-hosted infrastructure is and discusses use cases for running continuous integration jobs on it. It also explains some of the advantages dev teams may discover when running CI jobs outside the public cloud.

What is self-hosted CI infrastructure?

Self-hosted CI infrastructure is continuous integration software that runs on hardware, virtual machines, containers, or Kubernetes clusters that you control. Some organizations operate a physical data center for their self-hosted CI software. Many other organizations choose to maintain a private cloud network that only certain team members can access.

With either approach, teams trade more setup and maintenance overhead for better control over the computing environment. More robust privacy and data security measures are also benefits.

It’s important to note that cloud-based and self-hosted CI solutions are not mutually exclusive. You can run most of your CI jobs in the public cloud and still run self-hosted CI when specific needs arise. This approach is possible using self-hosted runners. A self-hosted runner is software installed on private architecture that polls the cloud-based CI service for jobs.

For example, CircleCI cloud customers can install self-hosted runners in under five minutes and start running private cloud and on-premises jobs on a range of supported platforms. Those platforms include Linux, macOS, Windows, Docker, and Kubernetes.

While self-hosted jobs execute on your private infrastructure, the results are reported back to the CircleCI web app. This gives you a single centralized location to view and manage your test results and application data for both your cloud-based and self-hosted jobs.

Use cases for CI jobs on self-hosted infrastructure

Self-hosted runners address two common use cases for development teams: unique resource requirements and privileged access needs. This section explores both of these use cases and some specific scenarios in which they might arise.

Custom compute types

If you have a particular need for a special type of compute instance that is not available through your cloud-based CI/CD provider, you may need to run your CI jobs on self-hosted infrastructure. For instance, teams building mobile applications may target specific hardware configurations and choose to test locally with self-hosted runners to ensure their application works exactly as expected on devices with the specified configuration.

Similarly, when developing for embedded systems, running tests against actual hardware or sensors is a critical part of building software and getting it ready for production. Teams that build software for consumer electronics, medical devices, household appliances, point-of-sale machines, and other embedded systems need a dedicated environment that matches the specifications of the target environment.

One approach is to set up an in-house building and testing lab and run tests there. While this option requires additional setup and maintenance overhead, it is the best way to create test environments that closely resemble the deployment environment, reducing the risk of unforeseen bugs in production.

Privileged access and controls

Organizations in highly regulated industries, like banking, healthcare, and the public sector, often face strict IT security and compliance requirements for where workloads are run and who has access to sensitive data. With self-hosted runners, your team can give certain jobs privileged access to private networks, set static IP addresses for verification with your servers’ allowlist, and (for self-hosted jobs running in AWS) assign Identity and Access Management (IAM) permissions for additional layers of access control.

Code signing is one example of a sensitive workload that requires this kind of additional security. When building signed binaries, organizations must protect their signed certificates from unauthorized access. One way to do this is to store the certificates on a secure local server that can be accessed with a self-hosted runner. This allows teams to take advantage of the speed and scalability of the cloud for building and testing their applications, then use self-hosted runners to sign the code before deployment.

Benefits of self-hosted CI jobs

Running CI jobs outside a cloud-based CI platform offers many benefits. These include flexibility, security, cost savings, a better development process, and improved confidence in your apps.

Flexibility and control over compute options

Running your CI jobs on self-hosted infrastructure gives you a high degree of control over computing options, such as the number of instances, regions, and instance types used for each job. You can also choose the best machine type based on the workload required by your CI job.

For example, suppose your team runs tests that take several hours to complete. These instances allow you to run tests in parallel without affecting performance. In that case, it makes sense to run them on large memory instances with high CPU power.

Depending on the execution environments offered by your cloud-based CI, running jobs with high resource demands or specific architecture requirements may be possible only on self-hosted infrastructure. Using CircleCI self-hosted runners, you can take advantage of the same parallelism and test-splitting capabilities available on the cloud platform for improved test run times.

Self-hosted CI also gives your team flexibility over when and how computing resources are used. If your team’s use of private infrastructure varies throughout the workday, you can implement an auto-scaling solution that will automatically spin up new instances based on demand and then tear them down when fewer resources are needed.

Privacy and security

One of the primary benefits of running continuous integration jobs on your own infrastructure is controlling who and what has access to your code. While there is always the risk of a breach, running workloads on private dedicated infrastructure can help reduce your risk exposure.

Running your continuous integration jobs in isolation on self-hosted infrastructure makes it much easier to limit the attack surface available for breaches. You can prevent network access from the outside world and expose only what is necessary, just to the parts of your system that need them. Preventing network access is especially useful if you have sensitive data like customer data or private keys in your repository.

Cost savings

Since self-hosted infrastructure is sometimes available at a fraction of the public cloud cost, you may find it makes financial sense to run resource-intensive jobs on self-hosted infrastructure. By setting up a CI instance on your infrastructure (whether an AWS EC2 instance or one hosted on your site), you can save money by paying only for the hardware resources.

Self-hosted infrastructure provides computing resources without costs beyond the hardware you’re using to host your code. Using virtualization software like Docker, you can take full advantage of all the benefits of cloud-based continuous integration systems, but with all the control that comes from running it on hardware you manage.

Increased confidence in your application and development process

Self-hosted CI provides increased flexibility and control over test-and-build environments. It’s often easier to access an uncommon or specialized test environment through a CI platform when running tests locally. This allows you to run tests on different platforms (for example, virtual machines) without having to wait for an update from the CI provider each time you want to switch environments.

Running tests on your own infrastructure also allows you to provision test environments that exactly match your production targets. This ensures your applications will work precisely as expected when deployed to production, improving confidence in your application and limiting the risk of shipping bugs to your customers.

Finally, running CI jobs on your own infrastructure can also improve your team’s development process. Hosted solutions often have limited control over build times due to scaling considerations. With self-hosted infrastructure, you can spin up the precise resources needed to complete your workflows. Having more control over how long tests run ensures that they’re not slowing down your developer workflows.

Conclusion

Cloud-hosted CI is the best option for most development teams. It offers all the flexibility, scalability, and performance needed to meet the most common development scenarios, without the hassle of maintaining your own infrastructure.

However, the cloud is not a one-size-fits-all solution. As the number of devices and computing environments keeps growing, so does concern with application and data security. Self-hosted CI isn’t going away anytime soon.

With CircleCI’s self-hosted runners, you can choose which CI jobs run in the cloud and which run on your organization’s infrastructure. Together, these options give you the flexibility to meet any computing and security needs your organization may face. Get started using self-hosted runners in your CI/CD pipeline today by signing up for a free CircleCI plan.