JetBrains has launched the Warm Agents plugin for TeamCity to address one of the most common sources of delay in continuous integration and delivery environments: waiting for a cloud build agent to start before tests or a build can begin. The plugin makes it possible to maintain a target number of idle, pre-started agents for each cloud image, so TeamCity begins provisioning a new agent as soon as the number falls below the specified level.
The plugin works with any cloud provider supported by TeamCity, making it suitable for teams that use ephemeral agents instead of keeping an entire build infrastructure running. The idea is aimed particularly at short tasks whose environment setup time may exceed their execution time; a slow-starting cloud Windows agent, for example, can leave a one-minute test in the queue for several additional minutes.
What Changes in Practice?
Instead of creating agents only when a task arrives, TeamCity monitors the number of idle agents for each cloud image and launches new instances when the number falls below the target. The number can be configured through the REST API or through the project settings at Project Settings | Integrations | Warm Agents. A target of zero is used to stop retaining ready agents for a particular image.
The plugin requires TeamCity 2024.12.3 or later, a cloud profile and cloud image configured within a project, and the Manage project’s agent cloud profiles permission. After it is installed and enabled from JetBrains Marketplace, it can be managed through the REST API or the teamcity-cli tool.
The Cost of Speed and Scaling Limits
Warm Agents does not provide free acceleration. Every ready agent that is running consumes a build agent license, while idle cloud instances continue to incur charges from the cloud provider. The plugin therefore establishes a clear trade-off between wait times and operating expenditure, and increasing the target does not always produce a practical improvement when actual demand is low.
TeamCity respects the maximum number of running instances defined by the cloud image, even if the agent target is set to a higher value. Instances are also launched in batches with short intervals, so reaching a high target may take some time. When the target is lowered, TeamCity does not forcibly stop running agents; the idle timeout defined for the cloud image remains in effect, with the possibility that some stopped instances will be restarted to maintain the target number.
Scheduling and Measurement
JetBrains suggests using scheduled tasks to change the target according to demand patterns, such as raising it in the morning and lowering it to zero in the evening. This can be done through Kotlin DSL and REST API calls, with the OAuth token stored as a password-type parameter so that it does not appear in build logs.
The plugin also exposes Prometheus-format metrics for each cloud image, including utilization and saturation indicators, to help teams identify peak demand periods and determine whether the number of ready agents is keeping up with the queue. In multi-node environments, metric requests must be directed to the main node through the cookie profile designated for that purpose.
Why Does This News Matter?
The plugin provides a direct mechanism for turning agent provisioning time from an unpredictable delay into a resource that can be configured and monitored. Its practical value will be greatest for teams with short, recurring tasks or predictable demand peaks, while the cost may not justify keeping warm agents in projects with intermittent operation. Adoption therefore requires comparing the cost of idle capacity with actual wait times and using metrics to adjust the target instead of choosing a permanently high fixed number.