Finding the job you care about on a busy build just got faster. The build page has a cleaner layout, a proper list view in place of the old sidebar, and less duplicated information getting between you and what you're actually trying to inspect.

• Find the job faster: Jobs are scannable at a glance, with room to breathe. Long step names are finally readable instead of truncated into uselessness.
• A cleaner layout: Pipeline and jobs on the left, the detail you're inspecting on the right. Less hunting, more space for the thing you care about.
• Works on your phone: The list view is fully responsive, so checking in on a cheeky build while you're AFK is no longer a pinch-and-zoom ordeal.
• Filter jobs by state: Something the old sidebar couldn't do at all. Find that one scheduled step inside a running group without scrolling.
• Groups stay grouped: When you filter or group by state, parallel, matrix and group steps keep their parent visible instead of flattening, so you never lose the context of where a job belongs.
• Less duplication: Repeated headers and metadata are gone, so the information you need stands out.
• Jump to anything, from anywhere: Search straight to a job or step from any view — including the canvas.

Available now for everyone on the new build page — turn it on from your user settings if you haven't already. Tell us what you think at support@buildkite.com.

Agents running buildkite-agent start now receive jobs in sub-second time, with no configuration changes necessary. Agent v3.122.0 replaces the polling-based dispatch with a persistent streaming connection, enabled by default.

What changed

Agent v3.122.0 changes the default agent API endpoint to agent-edge.buildkite.com, a new Go-based edge service that maintains a ConnectRPC stream to each connected agent. When a job is dispatched, it's pushed to agents over this stream rather than waiting for the next poll.

Why this matters

Previously, agents checked for work by polling every 10 seconds, plus random jitter to avoid synchronized requests across fleets. A job dispatched right after a poll could wait up to 20 seconds before that agent checks in again. Across a pipeline with many steps, that wait compounds.

With streaming dispatch, job acceptance latency drops to under 1 second. For an average build, that can save minutes of unnecessary wait time - resulting in faster and more efficient builds.

Availability

This is now the default for all agents running buildkite-agent start, including those on the Elastic CI Stack for AWS.

Buildkite Hosted Agents, Agent Stack for Kubernetes, and workflows using --acquire-job use different dispatch mechanisms and don't benefit from this change.

Upgrade to Agent v3.122.0 to get streaming dispatch by default. We'd love to hear how it goes! Reach out to support@buildkite.com with any feedback.

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.

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.

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'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

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

We've updated the names of our GitHub apps to make their purpose clearer and help you choose the right integration for your needs.

Name changes:

• "GitHub" → "GitHub (Limited Access)"
• "GitHub (with code access)" → "GitHub"

What each app does:

GitHub (formerly "GitHub (with code access)") is now the default option. This app can:

• Clone your repositories during builds
• Access your source code for hosted agents

GitHub (Limited Access) (formerly "GitHub") provides basic integration without code access:

• Trigger builds on commits and pull requests
• Update commit statuses and checks
• Perfect for scenarios where you don't need Buildkite to access your source code

These updates improve clarity around each app's capabilities.

Learn more:

• Setting up GitHub integration
• Understanding code access for hosted agents
• Migrating between GitHub apps