Buildkite lets you coordinate automated builds while running the actual jobs on infrastructure you control. An agent checks out work, executes the job, reports its logs and result, and uploads the resulting artifacts. That is useful when builds need access to your own machines, networks or tools. On Kubernetes, the Agent Stack creates Jobs for that work, changing how temporary workspaces, permissions and cleanup are managed.
Deployment and operating notes
The recovered chart installed Buildkite agents that polled for work. Buildkite now documents Agent Stack for Kubernetes, which watches a queue through the Agent API and creates a Kubernetes Job containing the containers needed to acquire and run each Buildkite job. This changes scheduling, workspace lifetime and security boundaries; it should not be treated as a values-file-only upgrade of a long-running agent.
Inventory pipeline plugins, hooks, Docker access, caches, artifact credentials and required service accounts before migrating a queue. Decide which workloads may run untrusted code and isolate their Kubernetes permissions and secrets accordingly. The current controller documentation distinguishes older GraphQL-token configuration from newer Agent API operation, so remove obsolete credentials only after confirming the deployed version. Test a checkout, multi-container build, artifact upload, cancellation and failed job. Check that temporary workspaces and pods are cleaned up and that cache behavior is intentional. Retain a separate old queue for rollback until representative builds pass.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
The buildkite agent is a small, reliable and cross-platform build runner that makes it easy to run automated builds on your own infrastructure. Its main responsibilities are polling buildkite.com for work, running build jobs, reporting back the status code and output log of the job, and uploading the job’s artifacts.
How it Works?
The agent works by polling Buildkite’s agent API over HTTPS. There is no need to forward ports or provide incoming firewall access, and the agents can be run across any number of machines and networks.
The agent starts by registering itself with Buildkite, and once registered it’s placed into your organization’s agents pool. The agent periodically polls Buildkite looking for new work, waiting to accept an available job.
After accepting a build job the agent will execute the command, streaming back the build script’s output and then posting the final exit status.
Whilst the job is running you can use the buildkite-agent meta-data command to set and get build-wide meta-data, and buildkite-agent artifact for fetching and retrieving binary build-wide artifacts. These two commands allow you to have completely isolated build jobs (similar to a 12 factor web application) but have easy access to shared state and data storage across any number of machines and networks.
Customising with Hooks
The agent’s behavior can be customized using hooks, which are just shell scripts that exist on your build machines or in each pipeline’s code repository. Hooks can be used to set up secrets as well as overriding default behavior. See the hooks documentation for full details.
Signal Handling
When a build job is cancelled the agent will send the build job process a SIGTERM signal to allow it to gracefully exit. If the process does not exit within 10 seconds it will be forcefully terminated with a SIGKILL signal.
The agent will also accept SIGTERM directly, and will gracefully exit. After it has processed the current job, it will disconnect and stop accepting jobs.
Sources & further reading
Spotted something that needs another look?
Help improve this page →