Static AMI images for cloud build agents are a ticking clock. Every tooling update, TeamCity server upgrade, or repository mirror refresh forces you to spin up a fresh instance, install changes, snapshot it, and update your cloud profile. JetBrains just released an AWS Image Builder plugin for TeamCity that turns that whole cycle into a regular build configuration.
Why Static AMIs Are a Maintenance Pain
Cloud agents are ephemeral: each build starts from a clean VM. That's great for isolation but brutal for state drift. Your base AMI starts aging the moment toolchains change or the server updates. Large repositories make it worse - every fresh agent has to pull an entire checkout directory from scratch. Baking repository mirrors into the image helps, but those mirrors go stale too. The traditional fix is a manual bake cycle that nobody enjoys.
The plugin eliminates that cycle. It takes a base AMI, runs an automated build step that installs the TeamCity agent (matching your server version), executes custom scripts for runtimes and SDKs, and pre-populates Git object mirrors from your VCS roots. All of that is defined in a standard TeamCity build configuration.
How the Plugin Works
After installing the plugin from JetBrains Marketplace and configuring an AWS connection, you create a new build configuration and add an "Image Builder AWS AMI" step. You specify the base AMI, network settings, instance type, and tags. Tags are critical: they let TeamCity discover the newest AMI automatically rather than hardcoding an ID.
Enable "Install TeamCity agent" to bake the exact agent binary from your server into the image. After a major TeamCity update, just rerun this build configuration to produce a fresh AMI with the matching agent. Attach VCS roots to the build configuration with the checkout policy set to "Use mirrors" - the plugin clones Git object mirrors into the image, so agents only fetch the latest commits on boot. Optional inline scripts or first-run scripts let you install anything else (Java runtimes, .NET SDKs, agent plugins) without adding boot-time slop.
Behind the scenes, the plugin generates a HashiCorp Packer template and stores it as a hidden artifact (.teamcity/image_builder/). You can inspect or debug the template if something goes sideways.
Automating Cloud Profile Updates
Building a fresh AMI is only half the automation. The real trick is making TeamCity use it without manual profile edits. Set each cloud image's instance toggle to "AMI by tags" instead of a fixed AMI ID. Use the same tags you defined in the image builder step (e.g., role=teamcity-agent, env=prod). TeamCity polls AWS periodically, finds all AMIs matching those tags, and picks the one with the most recent creation date. New builds automatically launch from the latest AMI.
No more snapshot-edit-profile-repeat. The cloud profile stays pointed at a tag, and the image builder configuration produces indefinitely refreshed AMIs under that tag.
Kotlin DSL Support
If you live in Kotlin DSL, the plugin exposes a build step type: awsImageBuilderBuild {}. You set the AWS connection ID, base AMI, subnet, tags, inline script, and a flag to include the agent. Same capabilities, all in code.
For teams running TeamCity on AWS, this plugin turns image drift from a recurring manual chore into a schedule-able build configuration that runs alongside your regular pipelines.
Source: AWS Image Builder Plugin for TeamCity
Domain: blog.jetbrains.com
Comments load interactively on the live page.