Glossary

Any user, registered or unregistered, who triggers the use of compute resources on projects that are not open source during a billing period. Commits, reruns, approvals, scheduled pipelines, and machine users can all make a user active. Active users are counted for billing. See the User Types and Registration page.

A special job, configured with type: approval, that pauses a Workflow until a user with the required permissions manually approves it. An approval job runs no steps of its own. It acts as a manual gate before downstream jobs continue. See the Workflows page.

A file or directory that persists after a Job finishes, such as a compiled binary, a coverage report, or a screenshot. Artifacts remain available for download long after a workflow completes, subject to a storage retention period. See the Storing Build Artifacts page. Compare with Cache and Workspace, which serve different purposes.

A record of significant events in a CircleCI organization, available to organization admins for audit and forensic analysis. See the Audit Logs page.

On CircleCI Server, the CircleCI program that executes the steps within a job and reports the results. The build agent runs as the main process inside a Nomad job allocation. See the CircleCI Server page.

A predefined Environment variable that CircleCI makes available in every job, containing information about the project, pipeline, and job being run (for example CIRCLE_BRANCH, CIRCLE_JOB, CIRCLE_BUILD_NUM). Built-in environment variables are scoped to the job. See the Project Values and Variables page.

A stored hierarchy of files that CircleCI restores into later jobs to speed up repetitive operations, such as downloading dependencies. A cache is immutable once written and is identified by a Cache key. See the Caching Dependencies page. Compare with Workspace and Artifact.

A unique identifier that determines when CircleCI writes a new Cache and which existing cache it restores. Cache keys can include templates, such as a checksum of a lock file or the branch name, that are evaluated at runtime. See the Caching Dependencies page.

The command-line interface you install on your local machine to validate and debug configuration, run jobs locally, and manage orbs, contexts, and policies. See the CircleCI Local CLI page. The CircleCI CLI is distinct from the environment CLI, which is available in your CircleCI pipelines.

CircleCI’s on-premises CI/CD platform for organizations that must operate within their own firewall, private cloud, or data center. CircleCI Server runs in a Kubernetes cluster and provides the same core features as CircleCI Cloud. See the CircleCI Server page.

A reusable sequence of steps that can be invoked multiple times within a job, within other commands, or across jobs in a configuration file. Commands are a building block of reusable config and Orbs. See the Reusable Config Reference page.

In the context of deployments, a collection of code and configuration that is deployed and released as a single unit. In Kubernetes terms, a component corresponds to a Deployment or Rollout object and its related objects that share a common circleci.com/component-name label. See the Deployment Overview page.

Running multiple jobs at the same time, either multiple jobs within a single Workflow or multiple workflows running across an organization. Concurrency is limited by soft limits on each Resource class. Concurrency is not the same as Parallelism, which splits the tests of a single job across multiple containers. See the Concurrency page.

Organization-level rules that govern which configuration elements are required, allowed, or disallowed in project configurations. CircleCI evaluates config policies with the Open Policy Agent (OPA) decision engine, using policies written in the Rego language. See the Config Policy Management Overview page.

The YAML file that defines your entire CI/CD process as code. The configuration file declares the Pipeline, workflows, jobs, and steps that run when work is triggered. It is most often stored at .circleci/config.yml in the root of a repository, but a project is not limited to that name or location. See the Configuration Introduction page and the Configuration Reference.

A running instance of an Image.

A type of Self-hosted runner installed in a Kubernetes cluster that runs containerized jobs in ephemeral pods. Container runner complements the Machine runner for high-concurrency, container-based workloads. See the Container Runner page.

A mechanism for securing and sharing environment variables across projects at the organization level. Environment variables in a context are defined as name/value pairs and injected at runtime. After you create a context, you can reference it in the workflows section of a project’s configuration file to give jobs access to its variables. Context access can be restricted with security groups, project restrictions, or expression restrictions. See the Using Contexts page.

A prebuilt Docker Image maintained by CircleCI with popular languages and tools preinstalled. Next-generation convenience images use the cimg/ namespace on Docker Hub and offer faster spin-up and improved stability over legacy images. See the CircleCI Images page. Compare with Custom image and Machine image.

The unit of compute consumption in CircleCI. Credits are consumed by the second, at rates that vary by machine type and Resource class. Larger resource classes consume credits at higher rates. See the Plan Overview page.

A Trigger that runs a pipeline in one repository when an event, such as a tag push, occurs in another. Cross-repo triggers help you test library consumers. See the Set up Cross-Repo Triggers page.

A Docker Image that you build and maintain yourself, typically from a Dockerfile stored in a registry. Use a custom image with the Docker executor when convenience images do not meet your needs. See the Using Custom-Built Docker Images page.

An inbound webhook that lets any third-party service capable of sending an HTTP request trigger a CircleCI Pipeline. See the Custom Webhooks page. Compare with Webhook (outbound).

The act of packaging code changes and making them available for Deployment. Continuous delivery produces deployable executables from code that can be deployed at a later time. See the Deployment Overview page.

A lightweight logging mechanism, configured as steps in your pipeline, that records a timeline of deployments in one place. Deploy markers let you track deployment status, roll back, and promote versions through environments. See the Configure Deploy Markers page.

The act of putting a new Component version into an Environment, regardless of whether traffic is yet routed to it. See the Deployment Overview page. Compare with Release and Delivery, which CircleCI defines as distinct steps.

The Executor (docker) that runs a job inside one or more Docker containers, providing the Docker execution environment. The Docker executor is resource-efficient and well suited to most build and test jobs. See the Introduction to Execution Environments page.

Docker Layer Caching (DLC) lets builds reuse Docker image layers from previous builds so that jobs which build Docker images run faster on subsequent runs. Layers can only be reused by builds from the same project. See the Docker Layer Caching and Running Docker Commands pages.

A feature that lets a pipeline determine the work it runs at runtime, based on pipeline parameters, changed file paths, or other conditions, rather than using fully static configuration. Dynamic configuration is enabled with a Setup workflow (setup: true). See the Dynamic Configuration page.

In the Deploys feature, a named deployment target represented in the CircleCI UI, such as staging or production. Environments can be a custom type or a Kubernetes cluster type. Ordered into an Environment hierarchy, they define a promotion path. See the Deployment Overview page.

An ordered sequence of environments that defines a promotion path. You can configure hierarchies at the organization, project, or component level to support different promotion workflows. See the Environment Hierarchy and Version Promotion page.

A named value stored in CircleCI and injected at runtime into jobs, used for configuration, secrets, and credentials. Environment variables can be set at the context, project, job, or step level, and follow an order of precedence. Values are encrypted at rest and masked in job output. See the Using Environment Variables page. Compare with Built-in environment variable.

The runtime in which a Job runs, either a Docker container or a virtual machine. CircleCI offers the Docker, Linux VM, macOS, Windows, GPU, Android, and Arm VM execution environments. You choose an Executor (docker, machine, or macos) and an image, and those together determine the environment. See the Introduction to Execution Environments page.

The type you assign to a Job that defines the underlying technology used to run it. CircleCI has three executors: docker, machine, and macos. For example, the machine executor can run a job in the Linux VM, Windows, GPU, Android, or Arm VM execution environment. In configuration an executor is also a named, parameterizable definition that multiple jobs can share. See the Introduction to Execution Environments and Reusable Config Reference pages.

A Workflow pattern in which a single job branches into multiple jobs that run concurrently (fan-out), which then converge on a single downstream job (fan-in). This pattern is useful for running test suites in parallel after a build, then deploying once all tests pass. See the Workflows page.

The mechanisms for controlling whether a Job, Workflow, or Step runs, based on the git branch or tag, or on other conditions. You can filter a job by branch or tag using the filters key with only and ignore values. For finer control, set filters to an expression, for example filters: pipeline.git.branch == "main". You can also gate a whole workflow or a single step with an expression in a when or unless condition. Expression-based conditions are the most flexible option and can reference pipeline values and parameters. See the Branch and Tag Filtering page.

A test that passes and fails inconsistently without changes to the code under test. CircleCI identifies a test as flaky when it both fails and passes on the same commit within a set time window. See the Identify and Fix Flaky Tests page.

A packaged system that includes the instructions for creating a running Container. The Primary container is defined by the first image listed in your configuration file. Visit the CircleCI Developer Hub to browse available convenience and machine images. See also Convenience image, Machine image, and Custom image.

CircleCI’s dashboards that report time-series and aggregated data on credit usage, success rates, duration, and test performance across your projects, workflows, jobs, and tests. See the Insights page and the Insights Metrics Glossary for metric definitions such as throughput, P95 duration, and mean time to recovery.

A feature that routes a job’s traffic through a set of well-defined CircleCI IP addresses, so jobs can reach systems protected by IP allow lists. See the IP Ranges page.

A collection of steps that run in a single Execution environment. Each job declares an Executor, and jobs are orchestrated by workflows. See the Jobs and Steps page.

The Executor (machine) that runs a job in a dedicated, ephemeral virtual machine with full operating-system access. Depending on the image you specify, the machine executor provides the Linux VM, Windows, GPU, Android, or Arm VM execution environment. See the Introduction to Execution Environments page.

A prebuilt virtual machine image for the Machine executor, available for Linux, macOS, Windows, Android, and GPU environments. See the Introduction to Execution Environments page.

On CircleCI Server, the service that dynamically provisions and manages the virtual machines used by jobs configured for the machine execution environment, as well as Remote Docker jobs. See the CircleCI Server page.

A type of Self-hosted runner installed directly on a Linux, macOS, or Windows machine, where it executes jobs in the same environment the runner binary is installed in. The current version is machine runner 3, which replaces the deprecated launch agent. See the CircleCI Runner Overview page.

The Executor (macos) that runs a job in a macOS virtual machine with Xcode available, providing the macOS execution environment. Used for iOS and macOS development and testing. See the Using the macOS Execution Environment page.

A Job that runs multiple times with different combinations of parameter values, configured with the matrix key. Matrix jobs let you test across multiple language versions, platforms, or other variables without defining each job by hand. See the Using Matrix Jobs page.

The CircleCI Model Context Protocol (MCP) server, which lets AI coding assistants diagnose build failures, fix issues, and manage pipelines through natural language without leaving the development environment. See the Using the CircleCI Model Context Protocol Server page.

An additional layer of account security that requires a second verification factor, such as a one-time password from an authenticator app, in addition to a password. See the Manage Multi-Factor Authentication page.

A unique, immutable identifier that groups an organization’s resources under a single owner. Each user or organization claims one namespace, typically the lowercase VCS organization name. The same namespace groups your registry Orbs by author and identifies your self-hosted runners. For runners, it is combined with a resource-class name to form the full runner Resource class label. See the Orb Concepts and Runner Concepts pages.

A token issued by CircleCI that lets a job authenticate with a cloud provider without storing long-lived credentials. CircleCI provides OIDC tokens in the CIRCLE_OIDC_TOKEN and CIRCLE_OIDC_TOKEN_V2 environment variables, with claims identifying the organization, project, and job. See the Using OpenID Connect Tokens page.

Reusable packages of YAML configuration that bundle jobs, commands, and executors to automate repeated processes and integrate with third-party tools. Orbs come in three forms. Registry orbs are published to the orb registry and can be public or private. Inline orbs are defined directly in your configuration. URL orbs are a single YAML file imported by HTTPS URL, subject to the organization’s allow list. Visit the Orb Registry to find orbs, and see the Orbs Introduction page.

The open repository of published registry Orbs that you can search and import into your projects. Orbs in the registry are designated as certified (written by CircleCI), partner, or community. See the Orbs Introduction page.

The top-level account in CircleCI that contains a team’s projects, settings, permissions, and billing. An organization is one of three types: circleci, github, or bitbucket. See the Users, Organizations, and Integrations Guide page.

In a circleci type Organization, a role assigned at the organization level that determines a user’s permissions across the whole organization. The organization roles are admin, contributor, and viewer. In github and bitbucket OAuth organizations, access follows the VCS permissions model instead. See the Roles and Permissions Overview page.

Running a single job’s steps across multiple identical execution environments at the same time, set with the parallelism key, to reduce job time. Parallelism is most often used with Test splitting. Parallelism is not the same as Concurrency, which is running multiple jobs at once. See the Running Tests in Parallel page.

A named, typed value passed to a Command, Job, or Executor to make reusable configuration flexible. Parameters support types such as string, boolean, integer, and enum. See the Reusable Config Reference page. Compare with Pipeline parameter.

The full set of processes you run when you trigger work on a project. A pipeline encompasses your workflows, which in turn coordinate your jobs, and is defined in your project’s configuration file. See the Pipelines page.

A typed Parameter declared at the top level of a configuration file and passed when a Pipeline is triggered through the API or web app. Pipeline parameters are referenced with pipeline.parameters.<name>. See the Pipeline Values and Parameters page.

Metadata about a pipeline that CircleCI makes available automatically, without declaration, such as pipeline.id, pipeline.number, and pipeline.git.branch. See the Pipeline Values and Parameters page. Compare with Pipeline parameter and Built-in environment variable.

The first Image listed in your configuration file for a Docker job. The job’s steps run in the primary container. See the Introduction to Execution Environments page. Compare with service container.

A registry orb available only within the organization that owns it. A private orb is findable in the registry only with a direct URL and when authenticated, and cannot be used by other organizations. See the Orbs Introduction page.

For github and bitbucket type organizations, a CircleCI project shares the name of the code repository whose workflows, tests, and deployments it automates. A project is visible on the Projects page of the CircleCI web app and must be added with the Set Up Project button.

For circleci type organizations, a CircleCI project is a standalone entity that you create first, and then associate with a code repository. You can create projects and connect your code in the CircleCI web app.

After a project is set up, you can configure settings, contexts, environment variables, and the team members who may follow it. See the Create a Project page.

A user who has created a CircleCI account. Registered users can access the web app, view pipelines and build history, trigger and rerun builds, and have organization access based on their role. See the User Types and Registration page. Compare with Unregistered user.

A version of a Component becoming available to an audience of users and other services. A release occurs when an existing component is updated or when the first version of a new component is deployed. See the Deployment Overview page. Compare with Deployment.

A tool installed in a Kubernetes cluster that lets you manage deployments through CircleCI, providing visibility and control over releases, including support for Kubernetes Deployments and Argo Rollouts. See the Release Agent Overview page.

A feature that enables building, running, and pushing Docker images to registries from within a Docker executor job, using the setup_remote_docker key. See the Running Docker Commands page.

Re-executing a failed Workflow, or individual failed jobs within it, to recover from transient failures without triggering a new pipeline. See the Workflows page. For tests specifically, see Test splitting and the Rerun Failed Tests page.

A configuration option that specifies the compute resources, such as CPU and RAM, allocated to a Job. A resource class is also used as a label to identify a pool of self-hosted runners and to route a job to that pool. See the Resource Class Overview page.

Reverting an application to a previous stable version when an issue is detected, either through a dedicated rollback pipeline or by rerunning a prior workflow. See the Roll Back a Deployment page.

A Trigger that runs a pipeline on a defined schedule, using cron syntax, rather than on each commit. Schedule triggers are the recommended way to run scheduled work. Use them instead of scheduled workflows unless your setup requires that approach. See the Schedule Triggers page.

A security feature that obscures environment variable and context values in job output, providing an additional layer of protection against accidental exposure of secrets. See the Using Environment Variables page.

A CircleCI agent installed on your own infrastructure, such as Kubernetes, virtual machines, or physical hardware, that claims and executes jobs on hardware or architectures you control. The two types are Container runner and Machine runner. See the CircleCI Runner Overview page.

An additional Image listed in a job’s configuration that runs alongside the Primary container, typically to provide a service such as a database. Also called a secondary container. See the Introduction to Execution Environments page.

An authentication method that lets users authenticate once through an identity provider, using the SAML 2.0 protocol, to access an organization’s CircleCI resources. See the SSO Overview page.

A cryptographic key pair used for authentication in CircleCI. A deploy key gives CircleCI access to check out a single repository. A user key is associated with a user account and can give access to multiple repositories. See the Rotate Project SSH Keys page.

A single executable action within a Job, such as a run, checkout, save_cache, or store_artifacts command. Steps run in the order they are defined under the steps key. See the Jobs and Steps page.

A workflow marked with setup: true that runs first in a dynamic configuration. A setup workflow can compute pipeline parameters and select which configuration to continue with, enabling conditional execution of the rest of the pipeline. See the Dynamic Configuration page.

A feature that runs only the tests affected by a code change. Test impact analysis maps which tests exercise which source files and skips tests covering unchanged files, to speed up CI. See the Set up Test Impact Analysis page.

Dividing a test suite across multiple parallel execution environments, by name, file size, or historical timing data, to reduce overall test time. Test splitting works together with Parallelism. See the Running Tests in Parallel page.

A mechanism that initiates a Pipeline. Triggers can be automatic, based on VCS events, schedules, or custom webhooks, or manual, through the web app, API, or CLI. See the Triggers Overview page. See also Schedule trigger, Custom webhook, and Cross-repo trigger.

Someone who has triggered builds in a CircleCI organization but has not created a CircleCI account. Unregistered users count as active users for billing. See the User Types and Registration page.

Deploying a specific Component version to the next Environment in an Environment hierarchy, often with a single action from the CircleCI UI. See the Environment Hierarchy and Version Promotion page.

The platform where your code is stored and that CircleCI integrates with, such as GitHub, GitHub Enterprise, GitLab, GitLab self-managed, Bitbucket Cloud, or Bitbucket Data Center. See the VCS Integration Overview page.

An HTTP POST request that CircleCI sends to an external service when a specified event occurs, such as a workflow or job completing. Outbound webhooks let other services react in real time without polling. See the Outbound Webhooks page. Compare with Custom webhook, which triggers CircleCI.

A set of rules that defines a collection of jobs and their run order. Workflows can run jobs concurrently, sequentially, on a schedule, or with a manual gate using an Approval job. See the Workflows page.

A workflow-aware storage mechanism that passes data between jobs in the same Workflow. A job persists files with persist_to_workspace, and downstream jobs access them with attach_workspace. On CircleCI Cloud, workspace storage is retained for 15 days by default, which is also the maximum. You can set a shorter period (1 to 15 days) under Plan  Usage Controls in the web app. See the Using Workspaces to Share Data Between Jobs page. Compare with Cache and Artifact.