Frequently Asked Questions

What are the IP addresses of Cirrus CI?

Cirrus CI control plane uses three IP addresses:

• 34.117.12.6 - IP address of the Cirrus CI API and all *.cirrus-ci.com domains.
• 34.27.109.83 - IP address for egress connections when evaluating Starlark configuration files.
• 34.28.114.255 - IP addresses for egress connections that Cirrus CI uses to access APIs, deliver webhook events, etc.

Is Cirrus CI a delivery platform?

Cirrus CI is not positioned as a delivery platform but can be used as one for many general use cases by having Dependencies between tasks and using Conditional Task Execution or Manual Tasks:

lint_task:
  script: yarn run lint

test_task:
  script: yarn run test

publish_task:
  only_if: $BRANCH == 'master'
  trigger_type: manual
  depends_on: 
    - test
    - lint
  script: yarn run publish

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).

There are no limits on how many VMs or Containers you can run in parallel if you bring your own infrastructure or use Compute Credits for either private or public repositories.

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 a static 35.222.255.190 IP for all the "managed-by-us" instance types except macOS VMs via use_static_ip field. Here is an example of a Linux Docker container with a static IP:

task:
  name: Test IP
  container:
    image: cirrusci/wget:latest
    use_static_ip: true
  script: wget -qO- ifconfig.co

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:

1. 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.

2. 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.

If it's happening for a macos_instance then please contact support.

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.

If it happened for an OSS project, please contact support immediately. Otherwise check your cloud console first and then contact support if it's still not clear what happened.

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 by using timeout_in field in .cirrus.yml configuration file:

task: 
  timeout_in: 90m
  ...

Maximum timeout

There is a hard limit of 2 hours for free tasks. Use compute credits or compute service integration to avoid the limit.

Container errored

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?

At the moment Cirrus CI only supports GitHub via a GitHub Application. We are planning to support BitBucket next.

Any discounts?

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.