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.

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.

The Xcode 26.2.0 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.
• Device IDs are inconsistently changing across VMs in Xcode 26. This is an OS-level issue that can affect builds relying on consistent device identifiers. We’ve opened a support ticket with Apple and encourage affected users to do the same to help prioritize a fix.

You can now view detailed information about your GitHub App installation directly in CircleCI under Organization Settings > VCS Connections. This includes when the app was installed or last updated, which permissions have been granted, and what repository access level has been configured.

This information is visible to all users in your organization and can help you troubleshoot common issues:

• Installation timestamps help identify when your GitHub App was installed and updated
• Permission details let you verify whether newly requested permissions have been accepted in GitHub
• Repository access level shows whether the app has access to all repos or only selected ones, which can help diagnose issues with repository visibility in CircleCI

Previously, this information was only available on the GitHub installation page and required GitHub admin access. Having it in CircleCI makes it easier to diagnose configuration issues without leaving the platform.

We’ve added a new organization setting called “Enable minor AI-powered features” (under Organization Settings > Advanced) that gives you granular control over smaller AI-powered features across the platform.

This setting currently controls access to our natural language to cron translation feature for GitHub App schedule triggers, and will be used for similar AI-powered convenience features as we add them.

This allows you to manage your AI feature preferences at the organization level, separate from our larger AI capabilities like intelligent build failure summaries and Chunk.

Server 4.9.0 Changelog

Before Upgrading

See the CircleCI server 4.9 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.9.0

The v4.9 release introduces serial groups for job serialization, automatic retries for workflows and steps, and improved caching with Zstd compression. In addition, MongoDB 4.4 or higher is required before upgrading to v4.9.

NEW FEATURES

• Serial Groups: A native mechanism for serializing job execution across workflows. Jobs can now be configured to run sequentially using the serial-group key, preventing race conditions in deployments and other concurrent operations. For more information, see the docs.

• Automatic Workflow Reruns: Workflows can now be configured to automatically rerun on failure using the max_auto_reruns configuration key. For more information, see the changelog.

• Automatic Step Retries: Individual steps within jobs can now be configured to automatically retry on failure. For more information, see the changelog.

• Faster Checkout with Blobless Method: The checkout step now supports a method option that enables blobless checkout for faster repository cloning. For more information, see the changelog.

• Zstd Cache Compression: Cache compression now uses Zstd by default, providing faster compression and decompression with better compression ratios. For more information, see the changelog.

• Job-level Cache Retention Controls: Cache retention can now be configured at the job level, allowing more granular control over cache lifecycle. For more information, see the changelog.

• OIDC Token Reliability Improvements: Enhanced retry handling for OIDC token generation, improving reliability in environments with transient network issues. For more information, see the changelog.

• Configurable Max Run Time: Build jobs now support a configurable maximum run time through the builds_service.custom_max_run_time Helm value, allowing operators to override the default 5-hour limit.

• Dark Mode: Users can now enable “Dark mode” through the CircleCI web app, see the changelog.

CHANGES

• Some CircleCI job statuses that were previously marked as skipped were changed to failed, see the changelog.
• Reduced time to start jobs for very large and complex workflows, see the changelog.
• Personal Access Token (PAT) management has been migrated to the authentication-service. PATs are automatically migrated during the upgrade process. This changes requires that the mongoDB instance used by your CircleCI server is at least MongoDB 4.4. You will need to upgrade your mongoDB instance before upgrading to server 4.9.0. Please reference our MongoDB Upgrade instructions if your mongoDB instance is not externalized.
• Context APIs are now served by the CIAM gateway for improved performance and scalability.
• Redis has been updated to the version 6.2.20 to address CVE-2025-49844.
• The feature-flags service has been removed as it is not required for Server installations.
• Deleting contexts double confirmation now asks for the name of the context, see the changelog.
• Branches now displayed in branch picker regardless of trigger settings, see the the changelog.
• Workflow start time & duration are now copyable from CircleCI web app, see the changelog.
• 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, see the documentation.

BUG FIXES

• Fixed incorrect trigger event display for scheduled workflows. For more information, see the changelog.
• Fixed an issue where pipelines showed errors when all workflows are filtered out. For more information, see the changelog.
• Fixed branch filter dropdown functionality. For more information, see the changelog.
• Fixed project count on “User homepage”, see the changelog.

NEW SERVICES

New services introduced with this release:

• lock-job-provider - Provides job serialization capabilities for serial groups feature (includes internalapi and consumer components)
• no-op-job-provider - Handles no-operation job types used by serial groups

SERVICE CHANGES

• feature-flags - The feature flags service has been removed as it is not utilized by execution services in Server.

DATABASE MIGRATIONS

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

• authentication-service
• insights-service
• lock-job-provider
• no-op-job-provider
• oidc-tasks-service
• permissions-service
• runner-admin

KNOWN ISSUES

Using a custom signed certificate will result in an x509 error for Docker, Machinem, and Runner jobs. A fix will be provided shortly in the future.

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

CircleCI OIDC tokens now include two additional claims:

• oidc.circleci.com/workflow-id
• oidc.circleci.com/job-id

These claims provide unique identifiers (UUIDs) for the specific workflow and job, enabling more precise access control policies when authenticating with cloud providers.

You can read more at Using OpenID Connect tokens in jobs

The Insights Snapshot Badge functionality will reach end-of-life on January 12, 2026. After this date, the feature will no longer be available.

As previously announced, this feature is being deprecated. We have updated our community forum with this confirmed date. Impacted users have been notified directly.

As of today, December 3, 2025, the default resource class for macOS jobs for all paid plan organizations has changed from macos.m1.medium.gen1 to m4pro.medium.

Quick reminder:

• If you don’t specify a resource class in your configuration, your jobs are already using the faster m4pro.medium - no action needed.
• Per our previous announcement, m4pro.medium is priced at 200 credits/min compared to 150 credits/min for the previous default, though faster execution times may offset the higher per-minute rate - see our price list for details.
• Your jobs may fail if your configuration specifies an Xcode version that is not available on m4pro.medium. For these cases, you can update your configuration to specify a resource class that does support the required Xcode version. For more information on which Xcode versions are available on which resources classes, see our documentation.
• If your configuration explicitly specifies a different resource class, we recommend updating it to m4pro.medium or removing the resource class specification to avoid configuration parsing issues when these resource classes reach their end of life on February 16, 2026.

For full details, see our original announcement.

We’ve launched a new email notifications experience that gives you more control over your inbox. You can now opt into a “My Work” filter to receive email alerts only for builds you personally triggered.

Getting Started: Enable the “My Work” filter in your notification settings to reduce notification noise and stay focused on your own work.

Learn More:

• Read the documentation
• Share your feedback to help us improve this feature

You can now convert plain English descriptions into cron syntax when setting up GitHub App schedule triggers. Type a description like “every weekday at 9am” or “twice daily” and get the corresponding cron expression automatically generated. You can review and edit the generated syntax before saving.

Some examples:

MFA Now Required

MFA is now required for all CircleCI accounts that use email and password Authentication. Customers with active sessions will be prompted to setup MFA when their session expires.

For more information see the docs.

Web Interface Session Length Has Changed

• Active user session timeout reduced from 1 year to 30 days
• Inactive user session timeout reduced from 2 weeks to 3 days

What This Means

• Active user sessions will be required to re-authenticate after 30 days (previously 1 year).
• Inactive accounts will be required to re-authenticate after 3 days (previous 2 weeks).
• • Email and password authentication users will be required to setup MFA on re-authentication.
• SSO customers can still set custom session timeouts via their IdP provider.
• This change applies to all CircleCI web interface sessions.

Why We’re Making This Change

The session length update brings CircleCI in line with NIST (National Institute of Standards and Technology) recommended security practices and reduces the risk of unauthorized access from dormant sessions.

MFA required for all email and password authentication accounts improves overall account security and aligns with industry best practices.

Unregistered users that trigger builds are now listed individually in Plans > Usage > Users, rather than appearing under a single unregistered user entry.

An unregistered user is how CircleCI tracks users (including automated systems or bots) that trigger builds, but have not signed up for CircleCI. This includes tools or services that perform actions on your behalf, such as CI bots, automation scripts, or dependency update bots, like Renovate.

Each unique active unregistered user counts toward your monthly active user total. Pricing structure remains unchanged (5 free users on Free/Performance plans, then per-user pricing for additional users).

Read this support article to learn more about active users.