The Xcode 26.0 Beta 6 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known Issues:

• iOS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle
  

The Project settings > Project setup page now allows disabling GitHub App and Custom Webhook triggers. This is useful when iterating on trigger configuration, as it enables pausing pipeline triggering without deleting a trigger.

The same functionality is available programmatically through the Triggers API.

Test Quality Agent now in Beta

A new agentic capability is now available in private beta that automatically identifies and fixes flaky tests in your CircleCI projects. This agent helps reduce debugging time by analyzing inconsistent test behavior and creating pull requests with validated solutions.

Read the full announcement and setup guide on Discuss

How it Works:

• Identifies flaky tests with inconsistent pass/fail behavior
• Generates and validates multiple solution attempts per test
• Creates PRs only when solutions pass reliability validation
• Provides detailed logs and code diffs for review

Beta Details:

• No extra cost during beta (uses existing compute credits and AI provider tokens)
• Join the waitlist for access
• Feedback welcome at ai-feedback@circleci.com

The Xcode 26.0 Beta 5 image is now available to be used in CircleCI pipelines on the M4 Pro resource classes.

Please see the full manifest for information about the software included with this image release.

Known Issues:

• iOS 26 simulators sporadically freeze during boot and may fail to start. We recommend pre-booting simulators and, if they don’t start within 60 seconds, terminate them and restart them.
• Metal Toolchain is currently non-functional. A workaround is available by running the following commands before use:

    xcodebuild -downloadComponent metalToolchain -exportPath /tmp/MetalExport/
    sed -i '' -e 's/17A5295f/17A5241e/g' /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle/ExportMetadata.plist
    xcodebuild -importComponent metalToolchain -importPath /tmp/MetalExport/MetalToolchain-17A5295f.exportedBundle
  

We have added automatic workflow retry functionality to help you handle flaky resources and intermittent failures without manual intervention. You can now specify max-auto-reruns in your workflow configuration with a value between 1 and 5 to automatically rerun failed workflows. Just like the manual “re-run from failed” feature, only failed jobs will be retried - successfully finished jobs will not be rerun during automatic retries. This eliminates the need to manually monitor and restart workflows that fail due to environmental issues beyond your control.

The UI will provide clear indicators when a workflow is being automatically retried and show how many retry attempts have been made. This feature is available to all CircleCI customers across all plan types.

For teams dealing with flaky tests or unreliable external dependencies, this update significantly improves operational efficiency by reducing the manual overhead of workflow management. For more details on configuring automatic workflow reruns, visit the documentation.

Note: For those needing to auto-retry individual steps, automatic step retry is in the works!

You can create and delete CircleCI organizations programmatically through newly released Organization endpoints:

• Create organization
• Delete organization

Server 4.8.0 Changelog

Before Upgrading

See the CircleCI server 4.8 release notes and upgrade guide for this release.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.8.0

The v4.8 release introduces further security improvements and support for flexible job dependencies.

NEW FEATURES

• Nomad UI is now accessible.
• Amazon Message Queue (AMQ) is now supported.
• Added support for configuring IOPS and throughput parameters for EC2 instances in the machine provisioner. New parameters can be found in the values.yaml reference.
• CircleCI Server now supports nomad servers externalized from your Kubernetes cluster. You may now deploy nomad servers on your own VM instances. This should improve the performance and stability of your nomad clusters.
• Support for Expression-based job filters
• Support for flexible job dependency.
• Support for Dynamic When Statements for Workflows (Breaking Change)

NEW SERVICE:

• public-api-service

REMOVALS:

• web-ui-user-settings
• web-ui-org-settings
• web-ui-insights
• web-ui-project-settings
• web-ui-runners
• Support for launch-agent.
• Already-disabled v2 runner API endpoints.

CHANGES

• Moved from CircleCI fork back to upstream Hashicorp Nomad for improved stability and security updates.
• JSON logging is enabled for Clojure services. This change allows customers to ingest logs from these services to their log aggregators in a familiar and consistent format.
• All containers now run with runAsNonRoot: true
• Telegraf will now include circleci_server_version in all the metrics it collects.
• The frontend container now uses the circleci-www-api image instead of the previously named frontend image.
• Clojure containers have moved to Java 21.
• Kong has been updated to 3.4.2
• Rerun workflow endpoint now has a rate limit of 20 requests per 5 seconds (max burst: 10)
• In server-terraform, the included Nomad images are now based on Ubuntu 22.04 with CgroupsV1 enabled. CgroupsV2 is currently unsupported. These nomad AMIs are built automatic security updates enabled.

PERFORMANCE IMPROVEMENTS:

• Database Operations: Optimized workflow storage to avoid N+1 database queries, reducing latency and improving concurrency.
• Workflow Status API: Now uses stored workflow status instead of generating it from job data, improving response times.
• Compiled Config Size: Removed unused job definitions from compiled configs, reducing size for customers with large configurations.

BUG FIXES

• Expression based restrictions via API have been fixed.
• Job handlers no longer silently drop on partial failure.
• Fixed broken branch picker functionality.
• SSH reruns in air-gapped installs have been restored.
• Broken pipelines now show triggering information in the UI.

DATABASE MIGRATIONS

The following services will run migrations when upgrading to this version:

• workflows-conductor
• authentication-svc
• builds-service
• branch-service
• contexts-service
• cron-service
• distributor
• domain-service
• insights-service
• machine-provisioner
• orb-service
• permissions-service
• runner-admin

NOTES

Customers that are using “S3-compatible” object storage should ensure that their object storage supports S3’s default data integrity protections. This includes (but is not limited to) Minio RELEASE.2025-01-20T14-49-07Z and Nutanix Objects v5.1.1.

KNOWN ISSUES

• Docker jobs may take an extra 60 seconds to conclude under certain circumstances.
• RDS is not compatible due to certain permissions checks; this will be fixed in 4.8.1.
• Vault may not refresh its client token after a month of uptime. Migrate to Tink to resolve this issue.
• Retry with SSH for jobs using the machine executor advertises a private IP address. For this reason, retry with SSH for jobs using the machine executor works as standard for public installations, but for private installs you would need to ensure that you can access the private IP advertised. For example, by using a VPN into your VPC.

To learn more about Server 4.8 installation, migration, or operations please review our documentation.

Mac M4 Pro resources are now available on CircleCI, bringing Apple’s most advanced silicon directly to your CI/CD pipelines. Experience cutting edge performance with optimized CPU and memory configurations designed to effectively tackle your most challenging tasks.

Mac M4 Pro is available for customers on Performance and Scale plans in the following configurations:

Supported Xcode versions: 16.4.0, 16.3.0, 16.2.0, 16.1.0, 16.0.0, 15.4.0, 15.3.0, 15.2.0, 15.1.0, 14.3.1, 13.4.1

See the macOS documentation and CircleCI price list for details.

The CircleCI Terraform Provider enable customers to manage CircleCI projects with IaC patterns. For large-scale organizations, this enables automated project creation for new teams or projects. For existing projects and teams Terraform offers consistent settings and controls across all projects.

There is a planned breaking change in the public-api-service that affects the Get Trigger operation. We are working to fix this on the next release. change will remove name and description from the API response for the getTrigger endpoint.

We will move the terraform provider to General Availability once we have addressed the planned API changes.

https://github.com/CircleCI-Public/terraform-provider-circleci

From the “Project Overview” page, you can now set up a rollback pipeline that lets you quickly revert to a previous deployment version when invoked. Read more in our community forum, send any questions/comments to sebastian@circleci.com.

Platform Team Toolkit enables enterprise CI/CD optimization and governance that eliminates duplication, enforces security compliance, and accelerates delivery while empowering developers with the flexibility and speed they need.

It’s a combination of features that unlock efficiency and reduce operational toil for platform teams managing pipelines at scale, all while enhancing developer experience and velocity.

Key components of Platform Team Toolkit:

Terraform Module (coming soon) - Built on top of our Administration APIs. Provides a centralized tool to manage all projects on CircleCI. With infrastructure as code policies, you can set standards and maintain settings in one place.

URL Addressable Orbs - Removes the barriers to reusable config by allowing any file in your VCS to become a CircleCI orb. Allowlist rules maintain security and compliance.

Centralized Configuration, Templates, and Overrides - Gives the platform team the ability to manage pipelines from a central template while still providing dev team autonomy where it’s required.

To get the most from these features we recommend you review the documentation.

Project administration APIs are now available to cloud customers. Perfect for customers wanting to ease new project onboarding, maintain standards across projects, or manage projects with infrastructure as code (IaC practices). For more information see the official documentation.

APIs Available:

• Project
• Pipeline Definitions (Github App)
• Triggers (Github App)

Over the next few weeks we will be following up on the API release with an official Terraform module supported by CircleCI. You will also see more detailed tutorials on how to leverage the APIs and Terraform on the CircleCI blog.

We’ve recently rolled out the CircleCI Model Context Protocol (MCP) Server. This enables developers using tools (Claude Code, Cursor, Windsurf, etc.) that support the MCP protocol to interact with CircleCI.

Agents and AI tools can now fulfill developer requests, such as “Find the latest failed pipeline on my branch and get logs.” This eliminates the need to navigate through the UI or use complex CLI commands to debug and solve problems. This is the initial release, and we will continuously be updating what the server can do over the coming weeks. If you would like to contribute, please don’t hesitate to put in a pull request.

For more details and example use cases, check out our documentation and our blog post.

For questions or feedback, please open an issue on the GitHub repository.

We’ve introduced a new project overview page, which allows users to get a quick sense of the health of their pipelines and see what changes have recently been deployed for a project all in one place. Users can access this page by clicking the Overview link from the Organization Home page or Projects page.

If you have any feedback on how we can improve this overview, please use the survey popup in the bottom right corner of the page to let us know!

The queue orb was previously used to avoid multiple pipeline race conditions and conflicts. Serial-job provides native support for the functionality provided by the queue orb. Overtime we will expand the use cases we support to cover additional challenges like multi-job or workflows. The first release is serial-group for individual jobs.

This allows an individual job to be serialized across the organization, project or branch based on the parameters you provide. Serialization will ensure the jobs are executed in the order in which the pipelines are started via commit, api or other triggering method.

To learn more about your options see the documentation.

It is now possible to configure pipelines to be triggered only on pushes to non-draft Pull Requests.

Who Can Use This?

This functionality is available to all customers that use GitHub.

If your organization is currently integrated with GitHub only through OAuth, an admin must take the one-time action of installing the CircleCI GitHub App to enable this functionality.

Getting Started

1. Go to your project’s Project Settings > Pipelines, and ensure you have a “GitHub App” pipeline defined
2. Go to Project Settings > Triggers, and define a GitHub App trigger
3. In the “run on” menu, select “Pushes to open non-draft PRs”
4. Trigger your GitHub App pipeline by pushing to a non-draft PR

For more details on newly supported GitHub trigger events and example use cases, check out our documentation. For any questions or feedback, email benedetta@circleci.com.

Pipelines can now be triggered on a wider range of GitHub events, including pull request events, giving you more control over when your builds run.

The full range of trigger options available are:

• All pushes
• Tag pushes
• Pushes to default branch
• PR opened or pushed to, default branch pushes, tag pushes
• PR opened
• PR merged
• PR marked ready for review
• “run-ci” label added to PR

This allows teams to trigger builds only when needed, reducing unnecessary spending.

Customizing Triggers for Different Pipelines

This functionality can be leveraged to configure different pipelines in the same project to run on specific events. For example:

• A “build-test-deploy” pipeline (config.yml) runs on “all pushes”
• A “benchmark” pipeline (benchmark.yml) runs on “PR opened”
• A “cleanup” pipeline (teardown-env.yml) runs on “PR merged”

We plan to expand the available events and conditions to choose from. Let us know what additional triggers your team needs by filling out this form, so we can prioritize adding them next.

Who Can Use This?

This functionality is available to all customers that use GitHub. If your organization is currently integrated with GitHub only through OAuth, an admin must take the one-time action of installing the CircleCI GitHub App to enable this functionality.

Getting Started

1. Go to your project’s Project Settings > Pipelines, and ensure you have a “GitHub App” pipeline defined
2. Go to Project Settings > Triggers, and define a GitHub App trigger
3. In the “run on” menu, select your preferred event
4. Trigger your GitHub App pipeline by performing the selected action on GitHub.

For more details and example use cases, check out our documentation.

For any questions or feedback, email benedetta@circleci.com.

Github App organizations can now take advantage of Github Checks. Customers often use GitHub checks to verify and validate that specific jobs or workflows have been completed before taking action like merging code.

GitHub App support within CircleCI allows customers to have multiple “pipelines” defined within a single project. Github doesn’t share this same capability or concept when it comes to GitHub Checks. GitHub checks the workflow name is the key and if workflows in two different pipelines share the same name they would overwrite each other’s status. CircleCI had to introduce a way to ensure that status updates were unique and identifiable by workflow across pipelines. Because of this, we introduced a pipeline definition ID in the workflow name for GitHub Checks for GitHub App integrations. These are non-mutable and allow the organization to build GitHub Check rules that are name-based.

NOTE: Some customers have both Github App and GitHub OAuth enabled on their application and may have both Github Status and GitHub checks enabled. Those customers will see GitHub Check updates for the GitHub App integration.

There is a new “no-op” type of job available to customers, which does nothing. This is useful in some cases to shape complex workflows and simplify dependency relationships when there are large fan-in/fan-out scenarios.

Use “type: no-op” when defining a job at it does nothing.

some-job:
  type: no-op

For example, if you had a workflow for building and deploying a binary to several distribution channels you might have a configuration like this:

workflows:
  main:
    jobs:
      - build-binary
      - generate-docs
      - run-tests
      - publish-to-app-store:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-play-store:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-website:
          requires:
            - build-binary
            - generate-docs
            - run-tests

With the addition of a no-op job called “build” you could shape your workflow as follows:

workflows:
  main:
    jobs:
      - build-binary
      - generate-docs
      - run-tests
      - build:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-app-store:
          requires:
            - build
      - publish-to-play-store:
          requires:
            - build
      - publish-to-website:
          requires:
            - build

This reduces duplication of requires stanzas and makes it easier to create new jobs both before and after “build” without making mistakes in the dependency relationships.

We have added conditional support to when statements so you can do things like this: when: pipeline.git.tag == "release". The conditional support allows you to run workflows based on pipeline parameters and values.

For those looking to optimize their pipelines for fast feedback or cost, you now have additional capabilities to meet those objectives. We have also made some improvements to error messaging for those customers that may have invalid config.yaml post release. The error will be similar to this: “Error calling workflow: ‘workflow-name’ Expected valid pipeline variable”.

Please see previous notifications about this breaking change here.

For more about these new capabilities visit the docs.

For organizations that integrate with GitHub App, GitHub OAuth App, Bitbucket Cloud, and Bitbucket Data Center, we now pre-populate pipeline parameters when triggering pipelines in the CircleCI web app.

For more details or to share feedback, visit our community forum.

Before Upgrading

See the CircleCI server 4.7 release notes and upgrade guide for this release.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.7.0

The v4.7 release introduces security improvements with the implementation of rootless containers.

NEW FEATURES

• Approval jobs can now be canceled through the CircleCI UI or via the API.

CHANGES

• Server components now run as rootless containers, enhancing security.
• The Nomad server ReplicaSet is now scaled to 5 pods by default, which improves execution stability at scale.
• Configuration for the RabbitMQ PersistantVolumeClaim (PVC) is now exposed through server Helm values. For more details, see the docs.

BUG FIXES

• Resolved an issue where frontend pods would not automatically detect and apply a new server license.
• Fixed a bug where a workflow could be prematurely marked as failed before all non-blocking jobs were run.
• Fixed a configuration issue that could cause connection refusals between Kong and Soketi following an upgrade to version 1 of Soketi.
• Addressed a typo in the Helm values for machine_provisioner.machine_agent_base_url. The correct template value should be machine_provisioner.agent_base_url.

SERVICE CHANGES

Deprecated components removed with this release:

• web-ui-404: Previously served the 404 error page. Its functionality has now been merged into the main web-ui component.
• Support for GitHub Enterprise versions <= 2.2: Code supporting these versions has been removed, as they are no longer supported by GitHub.

DATABASE MIGRATIONS

The following databases will run migrations when upgrading to this version:

• authenticationservice
• conductor_production

KNOWN ISSUES

• SSH reruns in air-gap will time out, leaving the job in an error state
• Vault may not refresh its client token after a month of uptime. Migrate to Tink to resolve this issue.
• Retry with SSH for jobs using the machine executor advertises a private IP address. For this reason, retry with SSH for jobs using the machine executor works as standard for public installations, but for private installs you would need to ensure that you can access the private IP advertised. For example, by using a VPN into your VPC.
• CircleCI 1.0 builds are not supported. If an attempt is made to run a 1.0 build, no feedback will be available in the application to indicate the cause of the issue. If a build is run on your installation and does not show up in the CircleCI application, use the CircleCI CLI to validate the project configuration and get details of the possible cause of the issue.

To learn more about Server 4.7 installation, migration, or operations please review our documentation.

Historically, CircleCI users have been limited to setting up validation systems that only worked within the scope of a single repository.

If a pipeline’s YML config was stored in Repo A, that pipeline could only be triggered from events on Repo A (or from a Custom Webhook). This has left many customers unable to set up the validation system that they want.

We have launched additional enhancements to pipeline and trigger configuration, which will enable customers to build any validation setup that they need.

Read more on our community forum.

We are enabling users who are a part an organization that integrates with CircleCI’s GitHub OAuth App to use functionality that was previously only available to organizations that integrate with CircleCI’s GitHub App.

The immediate change that users will see is the presence of “Pipelines” & “Triggers” tabs in Project Settings of the CircleCI web app.

Read our community forum for details.

Until today, the Pipeline property “Fallback branch” determined which branch would be used to fetch config and code for pipelines triggered via Custom Webhook. This field could only be configured by editing the Pipeline associated with a Custom Webhook, rather than by editing the Custom Webhook itself, and was poorly discoverable.

Now, the field “Fallback branch” has been removed from Pipeline configuration, and two new fields have been added to Custom Webhook setup:

• Config branch, which determines the branch to be used to fetch config
• Checkout branch, which determines the branch to be used to check out code when running a checkout step.

For existing custom webhook triggers, both new fields have been populated with the “fallback branch” value of the associated pipeline, so that existing behaviour is preserved.

Pipelines connected via GitHub App or Bitbucket Data Center can now be run via API, using a new API V2 endpoint:

https://circleci.com/api/v2/project/circleci/<org-id>/<project-id>/pipeline/run

See the docs for usage instructions. The new endpoint is not yet documented in the V2 API docs.

With CircleCI’s Evals orb 1.x.x, users were able to configure CircleCI to orchestrate evaluations of their LLM-enabled applications within their CI pipeline.

Evals orb 2.0.0 builds upon version 1.x.x, introducing Evaluation Testing. With Evals orb 2.0.0, users are able to automate the entire process of running evaluations, reviewing evaluation results and determining whether results meet application performance criteria. This removes the need to manually trigger evaluations and manually review evaluation results. Automating evaluations with CircleCI enables developers to automatically determine whether or not to merge proposed changes, or deploy their AI application.

To use Evaluation Testing, users configure test cases to determine if the results of an evaluation meet specified conditions. Each test case represents a scenario with an assertion to check if a specified condition is true or false. If any test case fails, the evaluation test fails. You can configure test case assertions such as Thresholds (Check whether 1 or more results fall within a range), and Equality (Check whether results provide an expected answer)

Evaluation Testing results are presented in the CircleCI web UI in two locations:

1. In the step details
2. In the tests tab

We have added release markers and release jobs to CircleCI Releases!

Release markers provide a lightweight way for users to generate a changelog and easily track their releases without requiring a full CircleCI Releases setup (no agent install needed!). Release markers can be configured for releases to any deployment target (ie. ECS, EC2, VMs, k8s, etc). See our documentation for information on setting up release markers.

Release jobs replace kubernetes manifest annotations as the way to configure deployment triggers. Release jobs also allow users to monitor their kubernetes release process as part of the overall deployment workflow in CircleCI, making it easier to find releases for a given pipeline. Users can also use release jobs to orchestrate releases across multiple environments (for example, deploy to production only after a successful release in a staging environment). See our documentation for information on setting up release jobs.

This version will reach EOL in August 2025 and can be skipped when upgrading from 4.3 or 4.4. We recommend upgrading directly to 4.7 for the latest security patches.

Before Upgrading

See the CircleCI server 4.6 release notes and upgrade guide for this release.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.6.0

The v4.6 release introduces various UI refreshments and improvements.

NEW FEATURES

• Several enhancements to the CircleCI web app, including:
  • A new “User Homepage”.
  • Updated styling for the left-hand navigation bar.
  • Top navigation bar that allows easy access to user-level actions.
• Pipelines are now labeled whenever they are rerun from start or fail, or with SSH.
• Project-based context restrictions. For more information see the docs.

CHANGES

• Old, expired workflows are now automatically canceled after 90 days.
• The pipeline.in_setup pipeline parameter has been removed.
• Kong, which is used for server API management, has been upgraded from 2.x to 3.x.

BUG FIXES

• Fixed a bug that prevented jobs from being rerun with SSH.
• Resolved an issue that prevented project loading on the Insights dashboard.
• Addressed regressions from server 4.2:
  • Introduced a configuration option at the organization level to set the default resource class for a Docker job. In server 4.3, this was previously hardcoded to large.
  • Added support for absolute paths in defining a GCP network under the machine provisioner configuration. This feature is particularly useful for VM jobs using shared networks, enabling explicit network selection. This corrects a regression from the previous VM service architecture.

NEW SERVICES

New services introduced with this release:

• authentication-service - provides an interface for user and identity management in the CircleCI system

DATABASE MIGRATIONS

The following databases will run migrations when upgrading to this version:

• builds_service
• conductor_production
• permissions

KNOWN ISSUES

• SSH reruns in air-gap will time out, leaving the job in an error state
• Vault may not refresh its client token after a month of uptime. Migrate to Tink to resolve this issue.
• Retry with SSH for jobs using the machine executor advertises a private IP address. For this reason, retry with SSH for jobs using the machine executor works as standard for public installations, but for private installs you would need to ensure that you can access the private IP advertised. For example, by using a VPN into your VPC.
• CircleCI 1.0 builds are not supported. If an attempt is made to run a 1.0 build, no feedback will be available in the application to indicate the cause of the issue. If a build is run on your installation and does not show up in the CircleCI application, use the CircleCI CLI to validate the project configuration and get details of the possible cause of the issue.
• Open ID Connect Tokens are not generated and not available.

To learn more about Server 4.6 installation, migration, or operations please review our documentation.