You can now define reusable deployment progressions for your environments and enforce them across your org, projects, or components.

Previously, there was no built-in way to standardize the order in which code moves through environments. Teams had to manage promotion paths manually, with no guardrails to ensure deployments followed the right sequence.

Now, you can:

1. Create named hierarchy templates (e.g., Development → Staging → Production) in your org settings under Deploys.

1. Set an environment hierarchy as the org-wide default, and assign hierarchies to specific projects or components.

1. Once assigned, version promotions follow that path automatically, and you can see each environment’s deployment status at a glance on the version promotion page.

What’s changed:

• Create and manage environment hierarchy templates from org settings under Deploys
• Set a hierarchy as the org default or assign it at the project or component level
• Version promotion pages now show each environment in the hierarchy with its current deployment status and version

Teams deploying across multiple environments can now standardize promotion paths, reduce manual coordination, and quickly see where any version currently stands across all environments.

You can now use Amazon Bedrock as the model provider for Chunk. In your Chunk org settings, select Amazon Bedrock and provide your AWS bearer token, AWS region, and Anthropic Claude model ID. Chunk will route all LLM requests through your Bedrock account, giving your organization full control over model access and data residency within AWS. Learn more in the documentation

It is now possible to configure pipelines to be triggered specifically when a push to a merge queue occurs.

When a pull request enters GitHub’s merge queue, GitHub creates a temporary branch prefixed with gh-readonly-queue/ that combines the PR’s changes with the latest base branch and any PRs ahead of it in the queue. This is the final validation before code lands on your base branch - and it often calls for a different CI strategy than what you run during code review.

With this trigger, teams using GitHub’s built-in merge queue can run a dedicated workflow at the merge gate - for example, a more comprehensive integration or end-to-end test suite - without slowing down the PR feedback loop. It also makes it straightforward to report a required status check on gh-readonly-queue/* branches, which GitHub needs in order to proceed with the merge.

This trigger option is available to all organizations using GitHub, as long as they have installed the CircleCI GitHub App integration. Access it by adding a new GitHub trigger to a GitHub App pipeline from the Project Settings > Project Setup page.

For more information and a full list of GitHub trigger event options, visit the Docs page.

Gen2 Linux VM / (x86) Remote Docker resource classes are now generally available on CircleCI, with CPUs that are up to 180% faster for your multi-threaded Linux workloads.

With over 96% of CircleCI machine jobs being multi-threaded, virtually all Linux VM / (x86) Remote Docker customers can leverage this significant performance boost to accelerate builds and reduce pipeline times.

Gen2 Linux VM / (x86) Remote Docker resources are available for all users in the following configurations:

See the Linux VM (gen2) documentation and CircleCI price list for details.

Effective August 1, 2026, support for all pipeline values starting with pipeline.trigger_parameters.circleci.* and pipeline.trigger_parameters.github_app.* will be discontinued. These values will no longer be guaranteed to be present in pipelines after this date.

These values are superseded by the pipeline.trigger.*, pipeline.event.*, and pipeline.git.* namespaces, which provide equivalent information in a more consistent format.

Affected values and replacements

Action required

Stop using these values in your pipeline configurations before August 1, 2026. After this date, their presence is not guaranteed and they should not be relied upon.

For the full list of available pipeline values and their replacements, see the Pipeline values reference.

The following pipeline values are now officially documented and supported.

Unless otherwise noted in documentation, all values listed below are available for GitHub App pipelines only.

Pipeline and project information

These values are available across all VCS integrations.

Trigger information

Checkout and repository information

Configuration source

These values describe where CircleCI fetched the configuration file from. They are available for GitHub App pipelines where the configuration file can be stored in a separate repository from the code being built.

GitHub event details

Push events

Pull request events

Sender

Repository

For full details on availability per VCS provider and trigger type, see the Pipeline values reference.

A Fix workflow button now appears at the top of any failed workflow. You can send the full workflow failure context to Chunk directly from the workflow view.

When hovering over a failing job in the Pipelines view, a Fix job button now appears inline. A Fix Job button is also available at the top of any failed job page. Both send that job’s failure context directly to Chunk without requiring you to navigate away or manually describe what went wrong.

We’ve added a notification flow for non-admin users who hit the GitHub App installation step during Chunk setup. If your organization hasn’t installed the GitHub App yet, you can now send a notification directly to your org admin from the setup screen, removing a major onboarding blocker.

We’ve updated the default build email notification settings to reduce inbox noise and surface only the alerts that matter most.

The New Defaults

My Work (builds you triggered): Email notifications are now enabled by default for failed, cancelled, unauthorized, and errored workflows.

Followed Projects: Email notifications are now disabled by default.

Who is affected? Users who have previously customized their notification preferences will see no changes — existing settings are preserved. Users who have not customized their preferences will automatically inherit the new defaults as of February 25.

Update Your Preferences You can review and customize your notification settings at any time here: Notification Settings

Today, if an upstream job is blocked and never runs, any downstream job depending on it is stuck — there’s no clean way to say “run this job once everything upstream is done, regardless of the outcome.” This leads to orphaned resources or messy config duplications when trying to implement a workaround.

We’re introducing two new job statuses that downstream jobs can depend on to solve this:

not_run — you can now explicitly condition downstream jobs on not_run, allowing cleanup and fallback jobs to fire whenever an upstream job did not execute.

terminal — an aggregate status that resolves to true when a job has reached any final state: success, failed, canceled, or not_run. Instead of enumerating every possible outcome, you can simply require a job to be terminal.

Here is an example:

workflows:
  test:
    jobs:
      - set-up-test-database   
      - run-tests:
          requires:
            - set-up-test-database
      - delete-test-database:
          requires:
            - run-tests: terminal  # Runs regardless of outcome

Now, delete-test-database always runs once “run-tests” job have reached a terminal state — whether it succeeded, failed, were canceled, or never ran at all.

For more details, visit the documentation.

You can now compare two versions directly from the deploy timeline to see the list of commits between them. Previously, understanding what changed between two deployed versions meant manually tracking down diffs in GitHub, with no easy way to see the commit history from within your deploy view. Now, clicking the compare button next to any release opens a modal with the full list of commits between that version and the currently live one, along with links to view the diff on GitHub.

What’s changed:

• A new compare button on the deploy timeline lets you select any two versions and view the commits between them in a modal, without leaving your deploy view.

Why it matters:

• Whether you’re investigating an incident or reviewing a release, you can now quickly see exactly what changed between versions, right from the timeline. Links to GitHub are included for teams who want to dig deeper into the full diff.

Availability:

• Version comparison is currently available for GitHub App users. An AI-generated summary of the diff is coming soon.

It is now possible to configure pipelines to be triggered only when a non-draft pull request is opened.

Combine this trigger option with “Pushes to open non-draft PRs” to ensure pipelines run when changes happen on pull requests that are ready for review.

This trigger option is available to all organizations using GitHub, as long as they have installed the CircleCI GitHub App integration. Access it by adding a new GitHub trigger to a GitHub App pipeline.

For more information and a full list of GitHub trigger event options, visit the Docs page.

Runner Release 3.1.8

Machine Runner:

• Fixed a regression where task-agent logs were only written to stderr and not to the log file when configured.
• Fixed an issue on Windows where backslashes in file paths were incorrectly stripped during command prefix expansion, causing task execution failures for some command prefixes.
• Fixed a bug where the task-agent binary was re-downloaded even when it already existed in the local cache, causing unnecessary network usage during task execution.
• The machine driver now configures a job object for the task-agent process and its child processes, ensuring they are properly terminated during cleanup.

A new “successful rerun” view is now visible in the Tests tab on your job page. This view displays tests that were successful after certain number of auto-reruns of failing tests.

Note: Auto-rerun of failing tests is a feature of Smarter Testing.

Sign up for early access to try Smarter Testing during our preview period.

Immediately stop all new pipelines and workflow reruns during incidents, at the organization or project level. In-progress workflows are not affected.

Available in Organization Settings > Advanced and Project Settings > Advanced.

Note: For server customers, this feature will be available in Server 4.10+.

You can now configure deploy markers across multiple projects in a single step, replacing the old project-by-project workflow.

Previously, adding deploy markers meant going through each project individually, which became increasingly tedious as your project count grew.

Now, our new multi-project setup lets you select the projects you want and apply deploy marker configuration to all of them at once. The tool ensures consistent setup across your projects so you can start tracking deployments everywhere without the manual overhead.

What’s changed:

• Deploy markers can now be added to multiple projects simultaneously from a single workflow, replacing the previous project-by-project setup.

Why it matters:

• Teams with large numbers of projects no longer need to spend time on repetitive configuration. Deploy marker setup now scales with you, whether you have a handful of projects or hundreds, so you can focus on shipping rather than configuring.

Getting started:

• Head to your organization’s project settings to try the new multi-project deploy marker setup. To learn more about how deploy markers work, visit our documentation.

Gen2 Linux VM / (x86) Remote Docker resource classes are now available in Beta on CircleCI, delivering priority access to CPUs that are up to 180% faster for your Linux multi-threaded workloads.

With over 96% of CircleCI machine jobs being multi-threaded, virtually all Linux VM / (x86) Remote Docker customers can leverage this significant performance boost to accelerate builds and reduce pipeline times.

Gen2 Linux VM / (x86) Remote Docker is available for all users in the following configurations:

See the Linux VM (gen2) documentation and CircleCI price list for details.

Beta Release Notes:

• This feature is stable but still being refined based on customer feedback
• Preview pricing shown above may change at General Availability
• SLOs are measured but not guaranteed during Beta
• Self-service activation is available now through your config

We’ve replaced our email notification system with enhanced preferences that give you granular control over when you receive build notifications.

What’s New:

“My Work” Notifications Receive email notifications only for workflows you triggered, reducing inbox noise while keeping you informed about builds you’re directly responsible for.

“Followed Projects” Notifications Stay updated on projects you follow with customizable notification preferences separate from your personal work.

Workflow Status Filtering Choose which workflow outcomes trigger email notifications - success, failed, canceled, and more. Focus on what matters most to your workflow.

Default Branch Preferences Set different notification preferences specifically for your default branch, since main/master branch builds often require different attention than feature branch work.

New email sender address Build notification emails are now sent from CircleCI Builds no-reply@builds.circleci.com. If you use email filters or allowlists, please update them to include this address.

Getting Started Update your preferences at User Settings > Notifications: https://app.circleci.com/settings/user/notifications

Scale plan customers can now set and track budget limits for CI credit usage.

Features:

• Organization and project-level budgets: Set weekly credit limits at the org level or for individual projects
• Real-time tracking: Monitor consumption as a percentage of your budget limit
• Automated notifications: Receive alerts when reaching 70%+ of budget limits via email, in-app banners, and build notification warnings
• Comprehensive coverage: Budgets track compute, Docker Layer Caching, storage, IP ranges, and network usage

Access: Org Admins can create and manage budgets from the Plans page. All users with Plans page access can view budget status.

Budgets run weekly (Monday 00:00 UTC - Sunday 23:59:59 UTC) and reset automatically.

To enhance your organization’s security, we’ve introduced a new setting: Context Security Settings.

You can find this option under Organization Settings > Security.

• When enabled: Contexts must first be assigned to a specific group before any user within that group can utilize them.
• When disabled (default behavior): Contexts are available to all users across your organization.

We understand that migrations to new resource classes take time, so we’ve added a way to temporarily disable resource class brownouts while you transition. Simply navigate to Organization Settings > Advanced > Enable resource class brownouts to control this setting.

This gives you more flexibility during your migration, though please note that deprecated resource classes will still reach their end-of-life date as scheduled, at which point they’ll no longer be available, regardless of your brownout settings.

We’ll announce the end-of-life schedule for each resource class well in advance, giving you plenty of time to plan your transition. Currently, only Mac M1 and M2 resource classes are being deprecated, with a scheduled EOL date of February 16th, 2026. We’ll keep you informed about any future changes through our changelog and email announcements.

You can now use CircleCI managed API keys when setting up Chunk Tasks.

During setup, choose between using a CircleCI managed key or bringing your own Anthropic or OpenAI API key.

Note: During beta, using CircleCI managed keys doesn’t incur additional costs beyond your normal compute credits. This will be a paid feature after beta.

Note

This is the last update for Server 4.7 as it has reached end of life. Please upgrade to Server 4.8.x.

Fixes

• Updated the IMDS client in machine-agent to fallback to IMDSv1 if it can’t communicate with IMDSv2
• Fixed incorrect kong HTTP header
• Fixed a bug where failed pipelines would produce an url that points to circleci.com rather than the CircleCI Server’s domain
• Fix for intermittent “S3 ExpiredToken” errors which occurred during workspace uploads for jobs running longer than 15 minutes

Image Updates

• approval-job-provider-migrator
• audit-log-service
• authentication-svc
• branch-service
• branch-service-migrator
• builds-service
• builds-service-migrator
• circle-www-api
• cron-service
• cron-service-migrator
• domain-service
• domain-service-migrator
• init-known-hosts
• machine-provisioner
• machine-provisioner-migrator
• orb-service
• orb-service-analytics-migrator
• orb-service-migrator
• policy-service
• runner-admin
• runner-admin-migrator
• server-postgres
• server-rabbitmq
• server-redis
• web-ui
• web-ui-authentication
• web-ui-insights
• web-ui-onboarding
• workflows-conductor
• workflows-conductor-migrator

You can now promote artifacts using deploy pipelines across environments to ensure the code you tested in staging is exactly what goes to production.

Why we built this: Rebuilding your code for each environment creates uncertainty. Is the code in production exactly what you tested in staging? When something breaks, was it a code change or an environment difference? Teams need confidence that what passed validation is exactly what’s being deployed.

How it works:

• Your CI pipeline publishes a versioned artifact (Docker image, JAR, binary) once. After that artifact passes validation in staging, you can promote that exact same artifact to production, other regions, or any environment without rebuilding.

When you’re ready to promote:

• Navigate to the Deploys page and select the artifact version you want to promote
• Choose your target environment from the dropdown
• The same verified artifact moves across your deployment pipeline

This means no more rebuilding for each environment, no more wondering if staging and prod are running identical code, and faster deployments when rolling out to multiple regions.

A new “Test Overview” widget is now visible in the Tests tab on your job page. When test results are uploaded, you’ll now see:

• Total number of tests run
• Test results breakdown (passed, failed, skipped by the test runner or Smarter Testing)
• Time saved from skipping tests with Smarter Testing

Want to reduce your test execution time? Sign up for early access to try Smarter Testing during our preview period.