Frequently Asked Questions¶
What are the IP addresses of Cirrus CI?¶
Cirrus CI control plane uses three IP addresses:
126.96.36.199- IP address of the Cirrus CI API and all
188.8.131.52- IP address for egress connections when evaluating Starlark configuration files.
184.108.40.206- IP addresses for egress connections that Cirrus CI uses to access APIs, deliver webhook events, etc.
Is Cirrus CI a delivery platform?¶
Are there any limits?¶
Cirrus CI has the following limitations on how many CPUs for different platforms a single user can run on Cirrus Cloud Clusters for public repositories for free:
- 16.0 CPUs for Linux platform (Containers or VMs).
- 16.0 CPUs for Arm Linux platform (Containers).
- 8.0 CPUs for Windows platform (Containers or VMs)
- 8.0 CPUs for FreeBSD VMs.
- 4.0 CPUs macOS VM (1 VM).
Note that a single task can't request more than 8 CPUs (except macOS VMs which are not configurable).
Monthly CPU Minutes Limit
Additionally there is an upper monthly limit on free usage equal to 50 compute credits (which is equal to 10,000 CPU-minutes for Linux tasks or 500 minutes for macOS tasks which always use 4 CPUs).
If you are using Cirrus CI with your private personal repositories under the $10/month plan you'll have twice the limits:
- 32.0 CPUs for Linux platform (Containers or VMs).
- 16.0 CPUs for Windows platform (Containers or VMs)
- 16.0 CPUs for FreeBSD VMs.
- 8.0 CPUs macOS VM (2 VMs).
Cache and Logs Redundancy
By default Cirrus CI persists caches and logs for 90 days. If you bring your own compute services this period can be configured directly in your cloud provider's console.
Repository is blocked¶
Free tier of Cirrus CI is intended for public OSS projects to run tests and other validations continuously. If your repository is configured to use Cirrus CI in a questionable way to just exploit Cirrus CI infrastructure, your repository might be blocked.
Here are a few examples of such questionable activities we've seen so far:
- Use Cirrus CI as a powerhouse for arbitrary CPU-intensive calculations (including crypto mining).
- Use Cirrus CI to download a pirated movie, re-encode it, upload as a Cirrus artifact and distribute it.
- Use Cirrus CI distributed infrastructure to emulate user activity on a variety of websites to trick advertisers.
IP Addresses of Cirrus Cloud Clusters¶
Instances running on Cirrus Cloud Clusters are using dynamic IPs by default. It's possible to request
220.127.116.11 IP for all the "managed-by-us" instance types except macOS VMs via
Here is an example of a Linux Docker container with a static IP:
CI agent stopped responding!¶
It means that Cirrus CI haven't heard from the agent for quite some time. In 99.999% of the cases it happens because of two reasons:
Your task was executing on a Cirrus Cloud Cluster. Cirrus Cloud Cluster is backed by Google Cloud's Spot VMs for cost efficiency reasons and Google Cloud preempted back a VM your task was executing on. Cirrus CI is trying to minimize possibility of such cases by constantly rotating VMs before Google Cloud preempts them, but there is still chance of such inconvenience.
Your CI task used too much memory which led to a crash of a VM or a container.
Agent process on a persistent worker exited unexpectedly!¶
This means that either an agent process or a VM with an agent process exited before reporting the last instruction of a task.
Instance failed to start!¶
It means that Cirrus CI has made a successful API call to a computing service to allocate resources. But a requested resource wasn't created.
Instance got rescheduled!¶
Cirrus CI is trying to be as efficient as possible and heavily uses spot VMs to run majority of workloads. It allows to drastically lower Cirrus CI's infrastructure bill and allows to provide the best pricing model with per-second billing and very generous limits for OSS projects, but it comes with a rare edge case...
Spot VMs can be preempted which will require rescheduling and automatically restart tasks that were executing on these VMs. This is a rare event since autoscaler is constantly rotating instances but preemption still happens occasionally. All automatic re-runs and stateful tasks using compute credits are always executed on regular VMs.
Instance timed out!¶
By default, Cirrus CI has an execution limit of 60 minutes for each task. However, this default timeout duration can be changed
timeout_in field in
.cirrus.yml configuration file:
It means that Cirrus CI has made a successful API call to a computing service to start a container but unfortunately container runtime or the corresponding computing service had an internal error.
Only GitHub Support?¶
Cirrus CI itself doesn't provide any discounts except Cirrus Cloud Cluster which is free for open source projects. But since Cirrus CI delegates execution of builds to different computing services, it means that discounts from your cloud provider will be applied to Cirrus CI builds.