FAQ

CircleCI employees never look at your code without permission. If you have requested support, a support engineer may ask permission to look at your code to help you debug the problem.

See the CircleCI Security policy for more details.

Yes, CircleCI provides a selection of "convenience images" for use with the Docker executor. For a full list, along with usage instructions, visit the CircleCI Developer Hub and the CircleCI images guide.

For the machine executor, see the available machine images list.

For an introduction to execution environments and images, see the Introduction to execution environments.

Yes, you can visit CircleCI’s Ideas page to request new features, or view features that have already been requested. To request a new feature, you will first need to select a category from the Give Feedback section.

When viewing requested features, you can sort by Trending, Top, and New, as well as filter by the following:

Yes, CircleCI offers migration guides for the following:

You can also visit the Migration introduction page for more information.

Yes, CircleCI server is available for installation on AWS or GCP. See the CircleCI server v4.x overview for details and links to installation instructions. Contact us to discuss your requirements.

CircleCI supports amd64 for Docker jobs, and both amd64 and Arm resources for machine jobs.

You can use the Machine executor for testing local IPv6 traffic. Unfortunately, we do not support IPv6 internet traffic, as not all of our cloud providers offer IPv6 support.

Hosts running with machine executor are configured with IPv6 addresses for eth0 and lo network interfaces.

You can also configure Docker to assign IPv6 address to containers, to test services with IPv6 setup. You can enable it globally by configuring docker daemon like the following:

Docker allows enabling IPv6 at different levels: globally via daemon config like above, with docker network create command, and with docker-compose.

Private orbs are available on any of our current plans.

Both commands and jobs are elements that can be used within orbs.

Commands contain one or many steps, which contain the logic of the orb. Commands generally execute some shell code (bash).

Jobs are a definition of what steps/commands to run and the executor to run them in. Jobs invoke commands, and are orchestrated using workflows.

Orbs can be used with installations of CircleCI server. For information on importing and using orbs for server, see the CircleCI server managing orbs page.

All public orbs are open source projects. Issues, bug reports, or even pull requests can be made against the orb’s git repository. Public orb authors may opt to include a link to the git repo on the orb registry. If the git repo link is unavailable, contact support and we will attempt to contact the author. Alternatively, consider forking the orb and publishing your own version.

Orbs use semantic versioning, meaning if you set the major version (example: 3), you will receive all minor and patch updates, where if you statically set the version (example: 3.0.0), no updates will apply, this is the most deterministic and recommended method.

No. Orbs are public by default and immutable, once a version of an orb is published it can not be changed. This is done so users can reasonably expect a known version of an orb will behave the same on every run. Deleting an orb could potentially lead to a failing pipeline in any of its user’s projects.

Orbs can however be "Unlisted" from the Orb registry. Unlisted orbs still exist and are discoverable via the API or CLI, but will not appear in the Orb Registry results. This may be desired if for instance, an orb is no longer maintained.

Use the env_var_name parameter type for the API key parameter. This parameter type will only accept valid POSIX environment variable name strings as input. In the parameter description, it is best practice to mention to the user to add this environment variable.

If you are interested in reading more on this topic, visit the Environment variable name and Best practices pages.

Create a parameter for the environment variable name, even if it is a statically named environment variable the user should not change. Then, assign it the correct default value. In the parameter description let the user know if this value should not be changed. Either way, consider instructing the user on how they can obtain their API key.

Consider validating required environment variables. See more in the Orb author best practices guide.

If you are interested in reading more on this topic, visit the Environment variable name and Best practices pages.

Orbs are packages of CircleCI YAML configuration.

CircleCI orbs package CircleCI reusable config, such as commands, which can execute within a given executor defined by either, the user if using a command within a custom job, or by the orb author if using a reusable job. The environment within which your logic is running may influence your language decisions.

POSIX compliant bash is the most portable and universal language. This is the recommended option when you intend to share your orb. Orbs do, however, come with the flexibility and freedom to run other programming languages or tools.

Bash

Bash is the preferred language as it is most commonly available among all available executors. Bash can (and should) be easily written directly using the native run command. The default shell on MacOS and Linux will be bash.

Ruby

Node

Python

Binary

This option is strongly discouraged wherever possible. Sometimes it may be necessary to fetch a remote binary file such as a CLI tool. These binaries should be fetched from a package manager or hosted by a VCS such as GitHub releases wherever possible. For example, installing Homebrew as a part of the AWS Serverless orb.

The answer might be both, but it will heavily depend on the task you want to accomplish.

An orb command can be utilized by the user, or even the orb developer, to perform some action within a job. The command itself has no knowledge of the job it is within as the user could utilize it however they wish. A command may be useful, for example, to automatically install a CLI application or go a step further and install and authenticate.

A job defines a collection of steps and commands within a specific execution environment. A job is highly opinionated as it generally chooses the execution platform to run on and what steps to run. Jobs may offer a useful way to automate tasks such as deployments. A deployment job may select a certain execution platform that is known, such as python, and automatically checkout the users code, install a CLI, and run a deployment command, all with little to no additional configuration required from the user.

A task is the smallest unit of work on CircleCI. If a job has parallelism of one, it is one task. If a job has parallelism = n and n > 1, then the job creates n tasks to execute.

A resource class is a label to match your CircleCI job with a type of runner (or container runner) that is identified to process that job. The first part of the resource class is your organization’s namespace. For example, a CircleCI resource class could be circleci/documentation.

Resource classes help you identify a pool of self-hosted runners, which allow you to set up your configuration to send jobs to specific resources. For example, if you have multiple machines running macOS, and multiple machines running Linux, you could create resource classes for each of these, orgname/macOS and orgname/linux, respectively. At the job level in your .circleci/config.yml, you can associate which self-hosted runner resources to send a job to based on the resource class.

Every time you create a resource class, a resource class token is generated that is associated with the given resource class. This token is the method by which CircleCI authenticates that the resource class is valid. The resource class token only has access to claim tasks.

Machine runners let you choose the user that executes jobs when the self-hosted runner is installed. It is up to you to ensure this user only has permissions you are comfortable letting jobs use. The container runner installation page describes the security model for container runners.

Install dependencies in one of two ways:

In order to connect back to CircleCI to receive and execute jobs, outbound HTTPS connections to runner.circleci.com, circleci-binary-releases.s3.amazonaws.com are required.

Caches, workspaces, and artifacts are methods you can implement to help persist data between jobs, and speed up builds. All three features are compatible with self-hosted runners.

Find out more about these concepts below:

You can also find out more on the Persisting data page.

If you would prefer to take complete control of artifact storage, CircleCI recommends you avoid the built-in steps and upload the artifacts directly to your chosen storage backend.

Machine runners are not opinionated about state between jobs. Machine runners can be configured to give each job a unique working directory and clean it up afterwards - but this is optional. And by default, nothing restricts the job from placing files outside of its working directory.

In general CircleCI recommends jobs rely on as little state as possible to improve their reproducibility. An effective way to accomplish this is to put cleanup steps at the start of a job so they are guaranteed to run regardless of what happened to a previous job.

If a self-hosted runner has not contacted CircleCI in 12 hours, it will not show up in the inventory page on the CircleCI web app.

Yes, self-hosted runner resource classes can be deleted through the CLI. Be sure you want to permanently delete the resource class and its associated tokens, as this action cannot be undone.

Organization admins in your VCS provider can create and delete self-hosted runner resource classes. Any organization user in your VCS provider that the resource class is associated with can view the resource class list through the CLI.

Yes, runner resource class tokens can be deleted through the CLI. Be sure you want to permanently delete the token as this action cannot be undone. Note this will not delete the resource class itself, only the token.

To get the list of tokens and their identifiers:

To delete the token itself:

Yes, additional runner resource class tokens for a specific runner resource class can be created through the CLI.

To create the token:

No, runner resource classes cannot be used by jobs that are not associated with the organization that owns the runner resource classes. Only forks of your OSS project that are a part of your organization may use the organization’s self-hosted runners.

On self-hosted runners, circleci-agent is used for all commands in which you may use either circleci-agent or circleci on CircleCI cloud (such as test splitting and step halt commands). Note, circleci is not to be confused with the local CircleCI CLI, and is simply an alias of circleci-agent.

If you would like to use the local CircleCI CLI in your self-hosted runner jobs, which can proxy test commands to circleci-agent, you can install the CLI via a job step. Install the CLI as a dependency on your machine for machine runner, or include it in a Docker image for container runner.

This section answers frequently asked questions for CircleCI’s container runner.

This section answers frequently asked questions for CircleCI’s machine runner.

If your project code is integrated via the CircleCI GitHub App, you can split your configuration into multiple files. For steps see the Set up multiple configuration files how-to guide.

While splitting configuration files is only available for GitHub App integrations, CircleCI does support dynamic configuration, which allows you to create configuration files based on specific pipeline values or paths, and continue one pipeline to another. See the Dynamic configuration page for more information.

You can trigger pipelines to build PRs from forked repositories with CircleCI API v2. However, by default, CircleCI will not build a PR from a forked repository. If you would like to turn this feature on, navigate to Project Settings  Advanced in the web app. If you would like more information, you can view this support article.

Yes, visit the Scheduled pipelines migration guide for more information.

As scheduled pipelines are stored directly in CircleCI, there is a UUID associated with each schedule. You can view schedules that you have created on the Triggers page of the project settings. You can also list all the schedules under a single project:

Refer to the Getting started with the API section of the API Developer’s Guide for more guidance on making requests.

Coordinated Universal Time (UTC) is the time zone in which schedules are interpreted.

Yes, you can set up Scheduled pipelines through the CircleCI web app, or with CircleCI API v2.

If you are currently using Scheduled workflows, see the Migration guide to update your scheduled workflows to scheduled pipelines.

CircleCI provides no guarantees about precision. A schedule will be run as if the commit was pushed at the configured time.

The scheduling expression with scheduled pipelines is different to the Cron expression.

For example, when you express the schedule as 1 per-hour for 08:00 UTC, the scheduled pipeline will run once within the 08:00 to 09:00 UTC window. Note that it does not mean that it will run at 08:00 UTC exactly.

However, subsequent runs of the scheduled pipeline will always be run on the same time as its previous run. In other words, if a previous scheduled pipeline ran at 08:11 UTC, the next runs should also be at 08:11 UTC.

Not currently. Scheduled pipelines require highly deterministic inputs such as a commit SHA, branch, or tag (fully qualified, no regex) included in the webhook, API call, or schedule.

The number of jobs you can run concurrently differs between plans. When using workflows to schedule jobs, you can use a fan-out/fan-in method to run jobs concurrently.

Yes, this is supported. See the Sample configuration page for examples.

You can set up your workflows to conditionally run jobs based on specific updates to your repository. You can do this with Conditional workflows and Dynamic configurations. Dynamic configurations will dynamically generate CircleCI configuration and pipeline parameters, and run the resulting work within the same pipeline.

Previously, this was true. With the dynamic configuration feature, you can now set pipeline parameters dynamically, before the pipeline is executed (triggered from either the API or a webhook—a push event to your VCS).

Custom executors can be used, but require certain dependencies to be installed for the continuation step to work (currently: curl, jq).

The continuation orb assists you in managing the pipeline continuation process. The continuation orb wraps an API call to continuePipeline. Refer to the continuation orb documentation for more information.

If you have special requirements not covered by the continuation orb, you can implement the same functionality in other ways. Refer to the orb source code to learn how the continuation functionality is implemented with the orb.

Credits are used to pay for users and usage based on machine type, size, and features such as Docker Layer Caching.

For example, the 25,000 credit package would provide 2,500 build minutes when using a Docker or Linux "medium" compute at 10 credits per minute. CircleCI provides multiple compute sizes so you can optimize builds between performance (improved developer productivity) and value.

When applicable, build time can be further reduced by using parallelism, which splits the job into multiple tests that are executed at the same time. With 2x parallelism, a build that usually runs for 2,500 minutes could be executed in 1,250 minutes, further improving developer productivity. Note that when two executors are running in parallel for 1,250 minutes each, total build time remains 2,500 minutes.

Every month, you are charged for your selected credit package at the beginning of the month.

You can choose to pay for premium features per active user, compute, and optionally, premium support.

On the Performance Plan, when you reach 0 credits, you will be refilled approximately 25% of your credit subscription, with a minimum refill of 25,000 credits. For example, if your monthly package size is 100,000 credits, you will automatically be refilled 25,000 credits (at $.0006 each, not including applicable taxes) when you reach 2000 remaining credits.

If you notice that your account is receiving repeated refills, review your credit usage by logging in to the CircleCI web app, then select Plan  Plan Usage. In most cases, increasing your credit package should minimize repeat refills. You can manage your plan by clicking Plan Overview.

On the Free Plan, jobs will fail to run once you have run out of credits.

Performance Plan: Credits expire one year after purchase. Unused credits will be forfeited when the account subscription is canceled.

You can pay from inside the CircleCI app for monthly pricing.

On the Performance Plan, at the beginning of your billing cycle, you will be charged for premium support tiers and your monthly credit allocation. Any subsequent credit refills during the month (such as the auto-refilling at approximately 25% when there are 0 credits remaining) will be paid at the time of the refill.

Prepaid billing is a payment option for customers on the Performance Plan. Prepaid Billing allows you to purchase credits in bulk, pay upfront, and be able to get discounted prices for credits based on volume purchased.

All Performance Plan customers can choose to get on prepaid billing through the CircleCI web app. To access this option, follow these steps:

You will still have access to any balance credits that were previously purchased, and the 12 month expiry date will remain.

Discounting for prepaid billing starts at a purchase volume of 5 Million credits and up.

Similar to what happens today on Performance plans, when you run out of credits your credit package will be automatically renewed at the purchase level you have selected.

Upon selecting prepaid billing, your credit card will be charged immediately. Subsequently, when you run out of credits, your credit card will be charged again to provide you with a refill.

You can follow these steps:

Yes, all prepaid billing customers still receive the benefit of 30,000 credits and 5 free user seats every month.

Yes, log in to the CircleCI web app, then navigate to Plan  Share & Transfer.

On non-free plans, you can share your plan with free organizations for which you have admin access using the Add Shared Organization option. All orgs you have shared your plan with will then be listed on the Share & Transfer page and child organizations will bill all credits and other usage to the parent org.

On non-free plans, you can transfer your plan to another free organization for which you have admin access using the Transfer Plan option. When you transfer a paid plan to another org, your org will be downgraded to the Free Plan.

You pay to the next nearest credit. First we round up to the nearest second, and then up to the nearest credit.

Calculate your monthly storage and network costs by finding your storage and network usage on the CircleCI web app by navigating to Plan  Plan Usage.

Calculate your monthly IP ranges costs by finding your IP ranges usage on the CircleCI app by navigating to Plan > Plan Usage.

In addition to the IP Ranges Usage summary, you can navigate to the IP Ranges tab to find more details about your data usage. In this tab, the IP ranges usage value represents the raw number of bytes in or out of the Docker container during execution of a job with IP ranges enabled.

This number includes the job’s overall network transfer and any other bytes that go in or out of the Docker container. Data used to pull in the Docker image to the container before the job starts executing will not incur usage costs for jobs with IP ranges enabled.

This feature will consume 450 credits from your account for each GB of data used for jobs with IP ranges enabled. You can also view job-specific details of IP ranges usage in the Resources tab on the Job Details UI page. See IP ranges pricing for more information.

You can view an approximation of network transfer for any Docker job (excluding Remote Docker) in the Resources tab on the Job Details UI page. Convert this value to GB if it is not already in GB and multiply by 450 credits to predict the approximate cost of enabling IP ranges on that Docker job.

Credit usage covers access to compute. We prefer to keep usage costs as low as possible to encourage frequent job runs, which is the foundation of a good CI practice. Per-active-user fees cover access to platform features and job orchestration. This includes features like dependency caching, artifact caching, and workspaces, all of which speed up build times without incurring additional compute cost.

An active user is any user who triggers the use of compute resources on non-OSS projects. This includes activities such as:

To find a list of your active users, log in to the CircleCI web app, select Plan  Plan Usage  Users.

No. If you are notified that a job is "queued", it indicates that your job is waiting due to a plan or concurrency limit. If your job indicates that it is "preparing", it means that CircleCI is setting up or dispatching your job so that it may run.

The first credit card charge on the day you upgrade to a paid plan or change paid plans, in addition to the following charges from CircleCI:

Open source organizations on our Free Plan receive 400,000 free credits per month that can be spent on Linux open source projects. Open-source credit availability and limits will not be visible in the UI.

If you build on macOS, we also offer organizations on our Free Plan 25,000 free credits per month to use on macOS open source builds. To find out more, visit the CircleCI support portal, which includes an Ask AI option to get you the information you need. Free credits for macOS open source builds can be used on a maximum of 2 concurrent jobs per organization.

CircleCI no longer offers discounts for open source customers on the Performance Plan.

Docker layer caching (DLC) reduces build times on pipelines where Docker images are built by only rebuilding Docker layers that have changed (read more on the Docker Layer Caching page). DLC costs 200 credits per job run.

To estimate your DLC cost, look at the jobs in your config file with Docker layer caching enabled, and the number of Docker images you are building in those jobs. There are cases where a job can be written once in a config file but the job runs multiple times in a pipeline, for example, with parallelism enabled.

Note that the benefits of Docker layer caching are only apparent on pipelines that are building Docker images, and reduces image build times by reusing the unchanged layers of the application image built during your job. If your pipeline does not include a job where Docker images are built, Docker layer caching will provide no benefit.

By purchasing a paid support plan with CircleCI, you can change the response time from our Support team to be as low as 30 minutes, with a 24 x 7 coverage plan, to ensure that any issues you have while using CircleCI are investigated as quickly as possible. For more information, refer to this support article.

You must have admin access in your CircleCI organization to cancel your Performance Plan subscription.

For GitHub users, your account has the "Owner" role in your GitHub organization.

For Bitbucket Cloud users, your account has "Admin" permissions in your Bitbucket repository.

For GitLab users, your account is listed as "Org Admin" in the CircleCI web app under Organization Settings > People.

You will continue to have access to the Performance Plan settings in the CircleCI web app and be able to use credits until the end of your current billing cycle. After the cycle ends, your org will be transitioned to the Free Plan, where you can use up to 30,000 credits per month.

Note that you will no longer have access to the billing statements after the end of the current billing cycle. Make sure to download your billing statements before then.

Credits that are unused at the end of the billing cycle will be forfeited and are not eligible for refunds.

Yes, you can always upgrade to the Performance Plan from the Plan > Overview page in the CircleCI web app.