Steps on the build canvas now display their run duration directly on each node, so you can quickly spot slow steps and see the progress of running jobs without clicking into them. Steps that haven't started yet show a -- placeholder, so you can see at a glance which parts of your build are still waiting to run.

Group steps on the build canvas are now collapsed by default, making complex dependency graphs much easier to follow at a glance.

• Collapsed by default: Group steps are now collapsed when you open a build, reducing visual noise and improving page performance on large pipelines.
• Expand and collapse all: A new button on the canvas lets you expand or collapse all group steps at once. You can also press G to toggle.

• Auto-expand on failure or input: Groups containing failed steps or steps waiting for user input are automatically expanded, so you never miss something that needs your attention.

You can still expand or collapse individual group steps by clicking on them.

You can now toggle case-sensitive matching when searching through job logs on the new build page. Click the Aa button in the log search bar to switch between case-sensitive and case-insensitive search.

The Buildkite MCP Server now sanitizes all tool responses to protect agents from prompt injection attacks. Build logs, pipeline names, commit messages, and annotations are passed through a multi-stage sanitization pipeline before reaching the agent — filtering invisible characters, stripping control sequences, sanitizing HTML, and neutralizing LLM delimiter tokens.

The list_builds tool no longer requires a pipeline_slug. When omitted, it queries across the entire organization, making it easier for agents to find failing builds without needing to call the tool once per pipeline.

When the Buildkite API returns an authentication error, the MCP server now surfaces it as a proper 401 response rather than a generic tool error. This means MCP clients and agents can correctly prompt you to re-authenticate instead of failing with a cryptic message.

A new --max-log-bytes flag (and BKLOG_MAX_LOG_BYTES environment variable) lets you cap how much log data the server downloads per request, defaulting to 100 MB. This gives you more control over memory consumption when working with large pipeline logs.

These improvements apply to both the open-source MCP server and the Remote MCP server.

The Buildkite Remote MCP server now rate limits on a per-user basis, so one person can't chew through your organization's entire API quota.

If you've been hesitant to roll out the remote MCP server broadly, this should help. Each user gets their own limit of 50 requests per minute, so you can invite your whole team to connect their AI coding assistants to Buildkite without worrying about one heavy user blocking everyone else.

There's nothing to configure, per-user limits apply automatically. If someone hits their limit, only their requests are throttled. Everyone else carries on as normal.

For more on API rate limits across Buildkite, see the Remote MCP server limits documentation.

Organization administrators can now view the service quotas that apply to their organization directly in Buildkite. Head to Settings > Quotas to see your actual limits, broken down by product area.

Each quota shows the effective limit for your organization. A Custom badge indicates a limit that differs from the default for your plan, and an Exceeded in last 24h badge flags any quotas your organization has hit recently.

If you need a quota increased, contact support@buildkite.com or reach out to your Technical Account Manager.

For the full list of default limits, see the Limits documentation.

We've been busy making changes to the way the Buildkite CLI can authenticate against organizations. We've implemented some features, as well as improvements to security so folks can feel safer in giving the CLI assess to their Buildkite organization.

OAuth availability

The CLI can now be authenticated via OAuth, with permissions scoped within the user's own accepted access. The permissions can also be customized to meet your needs for CLI use.

A single auth family

We've introduced an auth command, with various subcommands, to ensure all things authentication can be found in a logical spot. whoami and use can still be used, for now, performing the same actions as their new subcommands, bk auth status and bk auth switch, respectively.

We've also implemented bk auth login, replacing configure add, and bk auth logout, a new command which will clear keychain credentials for the current authenticated organization, or all keychain configurations with the --all flag.

No more text-based tokens

The CLI, until now, has been writing API tokens to a config file, typically at ~/.config/bk.yaml, which is convenient but a pattern we've wanted to move away from. As of v3.32.0, we'll no longer write to this file, only read from it. API tokens will be encrypted and stored in the OS keychain exclusively.

The CLI will fall back to reading bk.yaml files, so if those are in use, or you wish to continue using them, you can, you'll just see a warning in the terminal when you do. If you do wish to store API tokens in your bk.yaml file, you can manually adjust the file;

organizations:
  my-cool-org:
    api_token: bkua_hunter28265989387498729792378

A lot to take in? Read the Buildkite CLI documentation

The Buildkite SDK now supports C#, starting in v0.8.0. You can define and manage your Buildkite pipelines programmatically in C#, with the same type-safe experience available in the SDK's other supported languages: JavaScript/TypeScript, Python, Go, and Ruby. The package is now available for download from NuGet.

Several of our most popular plugins now support GCP and Azure, making it easier to use Buildkite with your preferred cloud provider.

The secrets plugin fetches secrets and injects them as environment variables into your builds. It now supports GCP Secret Manager and Azure Key Vault, in addition to Buildkite Secrets.

The cache plugin stores and restores build cache between pipeline runs. It now supports Google Cloud Storage and Azure Blob Storage backends alongside Amazon S3.

The docker-cache plugin speeds up Docker builds by caching images between pipeline runs. It now supports Azure Container Registry as a caching provider.

The docker-image-push plugin builds and pushes Docker images to Google Artifact Registry and Azure Container Registry alongside its existing support for Amazon ECR and Docker Hub.

(New) The azure-login plugin authenticates your Buildkite agents with Azure using managed identity or service principal credentials. Pair it with our secrets, docker-image-push, or cache plugins to streamline your Azure workflows.

You can now save filtered views directly from the Suite Summary page. After configuring your filters, save them as a custom view that will appear in your suite navigation for quick access later.

This makes it easier to:

• Quickly access the summary trends you check most often
• Share a consistent, filtered view across your team
• Reduce time spent reconfiguring filters between visits

You can now set an expiry date when creating an API access token. Once a token expires, any API requests using it will stop working, so forgotten tokens don't become a security risk.

Choose from preset durations (1 day, 7 days, 30 days, 90 days, 1 year), pick a custom date, or select "Never" to create a token with no expiry.

Key details

• Expiry is set at creation and cannot be changed afterward. To extend access, create a new token.
• You'll receive an email 3 days before a token expires, with a link to create a replacement.
• Expired tokens are automatically deleted after a grace period.
• All existing tokens are unaffected and continue to work with no expiry.

For more information, see the API access tokens documentation.

Test Engine Client (bktec) v2.1.0 introduces a new custom test runner and several improvements for pytest users.

🛠️ Custom test runner

You can now use bktec to split tests with any test runner that supports running specific test files via command-line arguments. For details, see the custom test runner documentation for Test Engine Client.

🐢 Split slow files by example (pytest)

You can now split slow test files by individual test examples when using pytest. This helps distribute long-running tests more evenly across agents and reduces build times.

🏷️ Tag filters (pytest)

The new --tag-filters option allows you to select and run tests based on a single key:value tag pair when using pytest.

Example:

bktec run --test-runner pytest --tag-filters "test.type:integration"

Read more about splitting slow files by example and tag filters in the Test Engine Client pytest documentation.

bktec v2.1.0 Release Notes.

We're pleased to announce migration documentation to help our customers transition from our Elastic CI Stack for AWS to the Buildkite Agent Stack for Kubernetes (agent-stack-k8s). This documentation addresses key differences between the two platforms and provides practical guidance for migrating your CI/CD workloads to Kubernetes:

• Amazon ECR authentication - Learn how to authenticate with Amazon Elastic Container Registry from Kubernetes environments.
• Docker login configuration - Understand the options for configuring Docker registry authentication in agent-stack-k8s.
• Package management - Discover approaches for handling required software packages and dependencies in Kubernetes-based builds.
• Hook execution differences - Understand the agent hook execution differences in agent-stack-k8s.
• Secrets management - Explore options for managing secrets when migrating your S3-based secrets.
• Docker daemon configuration - Learn about Docker daemon access patterns and container building approaches.

These guides are designed to help you understand the architectural differences between EC2 and Kubernetes environments, and provide practical examples for adapting your existing pipelines to use agent-stack-k8s.

Have questions or need help? Reach out to us at support@buildkite.com

You can now bring your CircleCI pipelines over to Buildkite even faster! Our pipeline conversion tool now supports more cases to convert CircleCI workflows to Buildkite pipelines. In addition to generating pipeline YAML that you can run, the output also includes information about required agent setup and other adjustments that may be needed to get a complete functional pipeline.

This makes it simple to:

• Copy an existing CircleCI pipeline
• Instantly see the equivalent Buildkite pipeline steps
• Speed up trying out Buildkite with less manual rewriting

👉 Try it out in the Pipeline Converter
📖 See the documentation

Starting in Agent v3.104.0, OIDC tokens are automatically redacted from build logs by default. This security improvement uses the Job API (a local API exposed over a unix socket) to perform redaction.

By default, the Job API environment variables (BUILDKITE_AGENT_JOB_API_SOCKET and BUILDKITE_AGENT_JOB_API_TOKEN) and socket are available in the job environment. However, when running buildkite-agent oidc request-token in a container or sandbox, these variables and the socket path must be explicitly passed through. See this docker-compose example.

If the Job API is not accessible, the command will fail with:

buildkite-agent: fatal: failed to create Job API client: BUILDKITE_AGENT_JOB_API_SOCKET empty or undefined

Who is affected: Customers using buildkite-agent oidc request-token outside of a standard Buildkite job environment.

Workaround: If you're unable to make the Job API available to buildkite-agent oidc request-token, you can disable automatic redaction with:

buildkite-agent oidc request-token --skip-redaction

If you need to roll back, v3.103.1 does not include this change.

Steps that were canceled (either directly or as part of a canceled build) now return state: "canceled" in the REST API and webhooks, instead of state: "finished" with outcome: "errored".

Previously, canceled steps were grouped with timed-out and expired steps under the same errored outcome. This made it difficult to distinguish between steps that were manually canceled versus those that failed due to timeouts or system errors.

With this change:

• Canceled steps: state: "canceled", outcome: "neutral"
• Timed-out/expired steps: state: "finished", outcome: "errored"

If you have integrations that parse step state from webhooks or the REST API, update your logic to handle the new canceled state:

- if step.state == "finished" && step.outcome == "errored"
-   # Could be canceled, timed out, or expired
+ if step.state == "canceled"
+   # Step was canceled
+ elsif step.state == "finished" && step.outcome == "errored"
+   # Step timed out or expired

This affects step.finished webhook events and REST API endpoints that return step data.

You can now bring your GitHub Actions workflows over to Buildkite even faster! Our pipeline conversion tool now uses AI to translate Actions workflows to Buildkite pipelines. In addition to generating pipeline YAML that you can run, the output also includes information about required agent setup and other adjustments that may be needed to get a complete functional pipeline.

This makes it simple to:

• Copy an existing Actions workflow
• Instantly see the equivalent Buildkite pipeline steps
• Speed up trying out Buildkite with less manual rewriting

👉 Try it out in the Pipeline Converter
📖 See the documentation

You can now select multiple log lines by Shift+Clicking, making it easier to copy multiple lines or share a permalink to a line range.

Teams can now customize their suite summary view to better track the trends that matter most. Save default filters and show or hide metric charts to tailor the view to the suite insights you care about.

This makes it easier for your team to:

• Focus on the most relevant suite trends
• Reduce visual noise by hiding unused metrics
• Keep a consistent, shared view across your team

We're pleased to announce the release of technical documentation that details how to use popular container image building frameworks from within our Elastic CI Stack for AWS and Buildkite Agent Stack for Kubernetes (agent-stack-k8s).

For our Elastic CI Stack for AWS, we've created documentation for the following frameworks:

• Docker BuildKit
• Remote Docker BuildKit
• Docker Compose
• Kaniko
• Buildah

For our Buildkite Agent Stack for Kubernetes, we've created documentation for the following frameworks:

• Docker BuildKit
• Docker Compose
• Docker-in-Docker (DinD)
• Kaniko
• Buildah

Follow the links above for complete usage information for each framework.

Have questions or need help? Reach out to us at support@buildkite.com