The first continuous integration (CI) tools were all self-hosted, meaning they ran on a developer’s local computer or server. Although this setup was viewed favorably by dev teams at the time, it has limited flexibility, and developers had to spend time maintaining the infrastructure.
As a result, many teams moved to cloud-hosted CI. Cloud-hosted CI is the best choice for most dev teams because it offers a flexible and scalable centralized platform to build and test software in the most common environments. However, even teams that have migrated to a cloud-based solution may have security and compliance requirements or specialized compute needs that prevent them from running certain jobs on the public cloud. 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 continuous integration software, but many organizations choose to maintain a private cloud network that only certain team members can access. With either approach, teams trade higher setup and maintenance overhead for more control over the computing environment and more robust privacy and data security measures.
However, it’s important to note that cloud-based and self-hosted continuous integration 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, including Linux, macOS, Windows, Docker, and Kubernetes. While self-hosted jobs execute on the private infrastructure you specify, the results of these jobs 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 are meant to 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 their 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 a range of benefits, including flexibility, security, cost savings, and improved confidence in your applications and development process.
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. In that case, it makes sense to run them on large memory instances with high CPU power, since these instances allow you to run tests in parallel without affecting performance. Depending on the execution environments offered by your cloud-based CI provider, 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 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.
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 because 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. With the ongoing proliferation of devices and computing environments, coupled with the growing 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, giving you the ultimate flexibility to meet any computing and security needs your organization may face. You can get started using self-hosted runners in your CI/CD pipeline today by signing up for a free CircleCI plan and enrolling in the free CircleCI Academy runner course.
