Cirrus CI is free for Open Source projects. For private projects, Cirrus CI has couple of options depending on your needs:
- For private personal repositories there is a very affordable $10 a month plan with access to community clusters for Linux, Windows and macOS workloads.
- Buy compute credits to access managed and pre-configured community clusters for Linux, FreeBSD, Windows, and macOS workloads.
- Configure access to your own infrastructure and pay $10/seat/month.
Here is the pricing model of Cirrus CI:
|User||Public Repository||Private Repository|
|Person||Free + Access to community cluster||$10/month + Access to community cluster|
|Organization||Free + Access to community cluster|
Sometimes configuring your own compute services isn't worth it. It takes time and effort to maintain them. For such cases there is a way to use the same community clusters that the Open Source community is enjoying. Use compute credits with your private or public repositories of any scale.
1 compute credit can be bought for 1 US dollar. Here is how much 1000 minutes of CPU time will cost for different platforms:
- 1000 minutes of 1 virtual CPU for Linux for 5 compute credits
- 1000 minutes of 1 virtual CPU for FreeBSD for 5 compute credits
- 1000 minutes of 1 virtual CPU for Windows for 10 compute credits
- 1000 minutes of 1 CPU with hyper-threading enabled (comparable to 2 vCPUs) for macOS for 30 compute credits
All tasks using compute credits are charged on per-second basis. 2 CPU Linux task takes 2 minutes? Pay 2 cents.
Note: orchestration costs are included in compute credits and there is no need to purchase additional seats on your plan.
Tasks that are using compute credits will be prioritized and will be scheduled as fast as possible.
Works for OSS projects
Compute credits can be used for commercial OSS projects to avoid concurrency limits. Note that only collaborators for the project will be able to use organization's compute credits.
Pros of this approach:
- Use the same pre-configured infrastructure as the Open Source community is enjoying.
- No need to configure anything. Let Cirrus CI's team manage and upgrade infrastructure for you.
- Per-second billing with no additional minimum or monthly fees.
- Cost efficient for small to medium teams.
Cons of this approach:
- No support for exotic use cases like GPUs, SSDs and 100+ cores machines.
- Not cost efficient for big teams.
Buying Compute Credits¶
To see your current balance, recent transactions and to buy more compute credits, go to your organization's settings page:
200 hours worth of compute credits for free!
Every organization on GitHub gets 60 compute credits upon Cirrus CI App installation. It has never been easier to try Cirrus CI on private organizational repositories.
Configuring Compute Credits¶
Compute credits can be used with any of the following instance types:
No additional configuration needed.
task: container: image: node:latest ...
Using compute credits for public or personal private repositories
If you willing to boost Cirrus CI for public or your personal private repositories you need to explicitly mark a task to use compute credits
Here is an example of how to enable compute credits for internal and external collaborators of a public repository:
task: use_compute_credits: $CIRRUS_USER_COLLABORATOR == 'true'
Here is another example of how to enable compute credits for master branch of a personal private project to make sure all of the master builds are executed as fast as possible by skipping community clusters usage limits:
task: use_compute_credits: $CIRRUS_BRANCH == 'master'
Pros of this approach:
- Full control of underlying infrastructure. Use any type of VMs and containers with any amount of CPUs and memory.
- More secure. Setup any firewall and access rules.
- Pay for CI within your existing cloud and GitHub bills.
Cons of this approach:
- Need to configure and connect one or several compute services. Might be nonintuitive for cases like Anka Build Cloud for macOS.
- Might not be worth the effort for a small team.
- Need to pay $10/seat/month plan.
What is a seat?
A seat is simply a GitHub user that initiates CI builds by pushing commits and/or creating pull requests in a private repository. It can be a real person or a bot. If you are using Cron Builds or creating builds through Cirrus's API it will be counted as an additional seat (like a bot).
For example, if there are 10 people in your GitHub Organization and only 5 of them are working on private repositories where Cirrus CI is configured, the remaining 5 people are working on public repositories or not modifying any repositories at all. Let's say Dependabot is also configured for these private repositories.
In that case there are
5 + 1 = 6 seats you need to purchase Cirrus CI plan for.