Deploying TeamCity into AWS using CloudFormation and Fargate

For the good cause, it is sometimes easier to start with TeamCity by deploying it into a cloud service, such as AWS. This allows the users to try TeamCity without the need to prepare the dedicated machine.

For the quick start, it is possible to use CloudFormation template which deploys the minimal setup to AWS. For the agents, TeamCity includes the integration for Amazon EC2 out of the box. However, there is also an alternative way to start the agents as Docker containers at Amazon’s Elastic Container Services platform.

In this article, we’re going to describe how to deploy TeamCity server using the CloudFormation template and how to configure the agents to run on Amazon ECS with Fargate.

Deploying TeamCity server to AWS with CloudFormation template

The official TeamCity CloudFormation template is available to simplify deployment to AWS. The resulting implementation will start a VM with two Docker containers: one for TeamCity server, and the other for the default agent.

DISCLAIMER: The current configuration of the CloudFormation template is not recommended for production setup. The default agent is configured to run on the same machine as the TeamCity server. Instead, it is advised to run the agents separately in order not to consume the machine resources required by the server.

Deploy TeamCity to AWS using CloudFormation template

Once a TeamCity server is deployed, check the Outputs tab for the URL. After the initial configuration steps, it is possible to add more build agents to the server. There are multiple options for TeamCity agents deployment at AWS. In the following, we’ll describe how to deploy the agent to Amazon ECS with Fargate.

AWS Fargate for TeamCity Agents

AWS Fargate is a technology for Amazon ECS that allows us to run containers without having to manage servers. TeamCity agent can be deployed as a container to ECS by using Fargate.

The short-lived container instances at ECS are perfectly suitable for executing build tasks. For TeamCity, it means that it is possible to acquire more resources dynamically. Once more agents are required to process the build queue TeamCity will request a new agent to start via Fargate. The agents can stop once the workload isn’t as high anymore.

To run TeamCity agents at Amazon ECS with Fargate several steps needs to be fulfilled:

  1. Have a running TeamCity server instance
  2. Install the required plugins for TeamCity server
  3. Create task definition for TeamCity agent in Amazon ECS
  4. Create cloud agent profile for the project in TeamCity
  5. Optionally, configure S3 artifact storage for the project in TeamCity

Installing Plugins

The required integration with various AWS services activates by installing the additional plugins to TeamCity server. To make use of AWS Fargate integration in TeamCity the Amazon ECS Support plugin needs to be installed. Also, one might want to consider storing the build artifacts in Amazon S3 as well. AWS S3 Artifact Storage plugin enables the integration.

Once the plugins are installed, we can proceed to the configuration.

Agents Configuration

Create AWS Fargate task definition

TeamCity agent is available as a Docker image via Docker Hub. In the Fargate task definition, it is possible to define a container, referring to that image. Once the server requests for a new agent via Fargate, a new container will start on Amazon ECS.

The important bit is to add SERVER_URL environment variable pointing at the URL of the TeamCity server. The agent will use that variable to connect to the server.

Create Fargate task definition

Create cloud profile for a project in TeamCity

To enable cloud integration in TeamCity one has to create a cloud profile for the desired project. Configuring cloud profile in TeamCity is quite straightforward.

Go to the project settings, the Cloud Profiles tab, click “Create new cloud profile” button and proceed with the configuration. Make sure to select Amazon Elastic Container Service as the cloud type.

It is also important that the selected AWS region in the cloud profile matches the region that you used to create the Fargate task definition.

In order to point the cloud profile at the task definition in Farget we have to add an agent image with the appropriate launch type.

Create Fargate task definition

Artifact Storage Configuration

In TeamCity, a build configuration can expose the resulting artifacts. It is wise to store the artifacts in the external storage. We can use Amazon S3 to save the files. Let’s see how to configure the service for TeamCity.

In the project settings, navigate to the Artifacts Storage Project tab and click the “Add new storage” button. Select “S3 Storage” type and fill in the name, bucket name and press Save. After that, activate this artifact storage in the TeamCity project by clicking the “Make Active” link. The new builds in this project will store artifacts in S3 automatically.

S3 artifact storage configuration


TeamCity was designed as on-premise solution. However, cloud services, such as AWS, simplify the setup if you would like to try TeamCity for your projects. It is easy to start with the CloudFormation template and scale by deploying the agents as Docker containers at Amazon ECS.

Posted in Blogroll, Features, How-To's | Tagged , , | Leave a comment

BitTorrent Plugin for TeamCity

Some time ago we announced the plugin that turns TeamCity into a torrent tracker and a seeder for large artifacts.

Judging by the flow of feedback — both positive and not so much — the plugin is in use by quite a few of our users. To remedy the not-so-much part, we are presenting a new version of the plugin, BitTorrent Support, today.

Plugin changes

If you’re new to BitTorrent, you might want to read our previous post on the subject first. For those familiar with the plugin, here is the list of the critical performance and security bug fixes, as well as the new features:

  • Optimized downloading speed in the torrent library (TW-49963)
  • Optimized memory usage by seeded torrents on the server and agent sides (TW-35395)
  • Optimized server resource usage on a build finish
  • Security fix related to modifying torrents settings by non-server admin users (TW-9523)
  • Ability to switch the plugin on/off for particular projects and build configurations
  • A large number of minor fixes.

Setting up the plugin

The new BitTorrent Support plugin is compatible with the latest TeamCity 2017.2.x+. Download the plugin from the JetBrains plugin repository and install it as usual.

Once you restart the server, a new link, Torrent Settings, will appear in the Administration area. By default, the plugin is disabled. To enable it server-wide, check the options for the TeamCity server and agents (you can later disable the plugin for some of the projects or build configurations if required):torPlugSettings

For the plugin to work correctly, TCP ports in the 6881-6889 interval should be open on the TeamCity server and agents.

If the plugin works correctly and you checked the options on the Torrent settings page, in the subsequent builds the agents will use the BitTorrent protocol to download all large artifacts (over 10Mb by default). The details will be logged: see the example of the build log in the Verbose mode:

Users can also download artifacts from the server via the BitTorrent protocol. To download a torrent file, click the torrent icon near the artifact name:torPlugArtDownload

Enabling / disabling the plugin for particular projects and build configurations, as well as controlling the artifacts size available via BitTorrent can be done using the configuration parameters described in the technical notes to the plugin’s Github repository.

Try the new plugin version and let us know what you think in the comments to this post, in our in our forum or tracker.

Happy building!

Posted in Blogroll, Features, FYI | Leave a comment

TeamCity 2018.1 (code-named Jaipur) EAP is open

Today we are opening the early preview program (EAP) for TeamCity 2018.1.
It’s been a tradition with us at TeamCity to name our versions after cities in India, so please welcome Jaipur 2018.1 EAP1.

This version will definitely be interesting for our customers using build configuration templates: you can now define build steps common for build configurations and place these steps before / after the build configuration’s own steps, conveniently using a placeholder for the latter.

Another thing is that now TeamCity allows more flexibility when it comes to redefining settings inherited from a template – now it is possible to change every setting of the inherited build step without the need to introduce parameters in the template. On the other hand, if you are a system administrator and if you want to enforce some settings on all the build configurations in the project so that other users could not redefine them, TeamCity now allows you to do this too.

Other improvements touch on the TeamCity integration with Docker, shared resources, our UI pages and much more, including over 70 fixed issues: see our release notes for details.

Download Jaipur 2018.1 EAP1 build, and remember to install it on a trial server as the new version changes the TeamCity data format.

All our EAP releases come with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations, and we do hope that you’ll try this build and share your feedback in our forum or tracker.

Happy Easter and happy building!

Posted in EAP, Features, Release, Uncategorized | 2 Comments

TeamCity 2017.2.3 is available

Yet another TeamCity update is available today. TeamCity 2017.2.3 fixes a few important performance problems, further improves security and provides better integration with Azure Container registry.

See our Release Notes for the full list of fixes.

The data format of TeamCity 2017.2.3 is the same as all the other 2017.2.x builds, which means you can upgrade easily and freely downgrade without lengthy restore from a backup.

When upgrading from TeamCity 2017.2.x, the automatic update will make things easier. If you’re upgrading from older versions, download TeamCity 2017.2.3 and follow our standard upgrade instructions.

Happy building!

Posted in Release | 2 Comments

The official TeamCity Azure Resource Manager template

We are happy to announce the Azure Resource Manager template for TeamCity. You can now deploy TeamCity to Azure cloud services and save time on configuration tasks. Get ready to start using TeamCity in several minutes!


Deploy TeamCity to Azure Cloud Services

The template performs the following tasks:

  • Setting up of an external database
  • Creating a virtual machine for the TeamCity server
  • Configuring the TeamCity server machine
  • Installing the TeamCity server
  • Installing a TeamCity build agent

Depending on your team size, you can select the appropriate TeamCity installation size for evaluation or production usage:

  • Small – suitable for small teams, typically 3 users, 100 builds/day.
  • Medium – suitable for medium sized teams, typically 5 users, 300 builds/day.
  • Large – is intended for large teams, typically 20 users, 1000 builds/day.

To get started, perform the following steps:

  • Specify the resource group name
  • Enter a public SSH key for the TeamCity server machine
  • Enter a password for the database
  • Click Purchase.


Wait for about 10 minutes and you will be able to navigate to the TeamCity URL received from the template outputs:


After opening the TeamCity page, you’ll need to accept the license agreement and set the root account credentials. Now you are ready to use TeamCity.

Configure additional Azure integrations

Your TeamCity server comes with preinstalled plugins which can be used to configure tighter integration with Azure services:

How it works

During the deployment process, the service allocates a Linux virtual machine. The VM is powered by CoreOS with Docker support enabled. It exposes port 80 for the web access and 22 for maintenance in the network security group, so you’ll be able to connect to it via SSH.

Configuration and data files are stored on the disk attached to this VM. The TeamCity server and build agent are started from the official Docker images.

An instance of the Azure database for MySQL is created with the teamcitydb schema. Network security rules are set to make the database accessible from the TeamCity server machine.

In the virtual machine, the TeamCity operation is controlled by the following systemd services:

  • teamcity-server.service controls the lifecycle of TeamCity server
  • teamcity-agent.service controls the lifecycle of TeamCity build agent
  • teamcity-update.service handles the TeamCity updates.

TeamCity upgrade

When a TeamCity VM is created, it has a teamcity-version tag. By updating its value, you can control the current version of the TeamCity server and build agent. After the update, you need to restart the VM entirely or restart the server and agent services via the following commands:

> sudo systemctl restart teamcity-server.service
> sudo systemctl restart teamcity-agent.service

Note: The update could take a few minutes to pull the new version of TeamCity Docker images.

How to diagnose problems

You can connect to the VM and use default systemd tools to control TeamCity services. For instance, during the upgrade you can view the server log using the following command:

> sudo systemctl status teamcity-server.service


Please feel free to leave a comment to this post or file an issue in the TeamCity issue tracker.

Run TeamCity on Azure

Happy building in Azure Cloud!

Posted in Features, FYI, News & Events | 14 Comments

TeamCity 2017.2.2 is released

Here is another update for our latest version, TeamCity 2017.2.2.

This bugfix update addresses over 100 issues, all of them listed in the Release notes.

We recommend updating to this version as it contains several security and performance fixes.

Build 50909 uses the same data format as all the 2017.2.x releases and you can freely upgrade or downgrade if required.

Upgrading is especially easy if you are using TeamCity 2017.2.x – you can use automatic update. To upgrade from older versions, download TeamCity 2017.2.2 and install it on your server.

Your feedback is always welcome in our forum and tracker.

Happy building!

Posted in Features, Release | 11 Comments

Branch specific settings in TeamCity

We’re often asked how to run different build steps in different branches. In fact, this has already been possible in TeamCity for quite some time (since version 9.1), but it seems we need to do a better job explaining how to use this feature.

Let’s assume that you have a build configuration where building of feature branches is enabled.

First, enable Versioned settings for the project where this build configuration resides. TeamCity will ask for a VCS root where the settings are to be stored. For simplicity’s sake, let’s store the settings in the same VCS repository where other project files are located.

For the Versioned settings, make sure the option When build starts is set to the use settings from VCS value. TeamCity will then take the settings from a branch used by the build instead of the current settings.


Once versioned settings are enabled, TeamCity will commit the .teamcity directory with the current project settings to the default branch of the selected VCS root. To start customizing the settings in our feature branch, we need to merge the .teamcity directory from the default branch.

But before making any changes in the .teamcity directory in your feature branch, bear in mind that not all the changes there will be applied. For instance, if you add a new project or a build configuration, such changes will be ignored. This happens because TeamCity does not support different sets of projects and build configurations in feature branches.

Besides, there is a chicken and egg problem. Currently TeamCity loads settings from .teamcity while the build sits in the queue. But to load the settings from a repository, TeamCity needs to know this repository settings (VCS roots). Thus VCS roots are always taken from the current project settings.

The same story is with build triggers and snapshot dependencies. TeamCity needs triggers to decide when to place builds into the queue. And TeamCity needs snapshot dependencies to create a build chain (graph of builds) before the builds are going to the queue. Hence the changes in .teamcity affecting these settings are ignored too.

But there are plenty of other settings whose changes will affect the build behavior:

  • build number pattern
  • build steps
  • system properties and environment variables
  • requirements
  • build features (except Automatic merge and VCS labeling)
  • failure conditions
  • artifact publishing rules
  • artifact dependencies

By default, the settings are stored in the XML format. Since there is no publicly available documentation for this format, it is hard to guess how to change build steps correctly, or how to add a build feature. This is what a command line build step looks like in XML:

What can help here is seeing how TeamCity generates these settings. For instance, get a sandbox project on your TeamCity server for such experiments, and browse the audit page for settings difference after each change:


Another option is to use Kotlin DSL (see the Settings format option on the Versioned settings page). In this case, instead of .xml files, .kt files will be stored under the .teamcity folder.

A Kotlin DSL project can be opened in IntelliJ IDEA Community (free and open-source IDE from JetBrains). Kotlin DSL files look much more concise, and IDE auto-completion makes it much easier to work with them, especially in the recent TeamCity versions. This is what the same command line build step looks like in Kotlin DSL:

Some additional hints:

  • Since TeamCity 2017.2 you can browse Kotlin DSL documentation using the following URL: <TeamCity server URL>/app/dsl-documentation/index.html
  • If a build loads settings from the VCS repository, you should see something like this in the build log:
  • Actual settings used by the build are stored in the buildSettings.xml file under the hidden build artifacts. This file can be helpful if something does not work as expected.
  • If you’re using remote runs instead of feature branches, then all the same abilities are also available, provided that the .teamcity directory is  present in your repository and versioned settings are configured as described above.

Finally, one more thing to keep in mind. If changes under .teamcity in your feature branch were temporary, you should not forget to revert the settings during the merge with the default branch. For instance, if you removed some long running steps or switched off some tests for convenience.

Happy building!

Posted in Features, How-To's, Tips&Tricks | 3 Comments

Webinar recording and Q&A: What’s New in TeamCity 2017.2

The recording of our December 20 webinar, What’s New in TeamCity 2017.2, is now available on the JetBrains YouTube channel.

In this webinar, Wes Higbee goes over the new features of TeamCity 2017.2, the latest release of TeamCity. He demonstrates how the Docker-specific build runners and the new Docker support build features work; the built-in .NET CLI support for building the .NET Core projects; the new composite builds for aggregating build results; as well as the default and multiple templates.

Continue reading

Posted in Features, Webinar | Tagged | Comments Off on Webinar recording and Q&A: What’s New in TeamCity 2017.2

TeamCity 2017.2.1 is released

Today we are releasing an update for the latest TeamCity version, TeamCity 2017.2.1.

This is a bugfix release fixing over 100 issues. For details please see the Release notes.

Upgrading is strongly recommended if you are using with TeamCity. As will deprecate a number of older cryptographic standards in February 2018, this change will affect agent-side checkout in all TeamCity versions before 2017.2.1 and server-side checkout in TeamCity versions prior to 9.0.2. If upgrading is not possible for you, see this workaround.

Other users are also advised to update to this version as it features a number of important fixes.

TeamCity 2017.2.1 has the same data format as all the 2017.2.x releases, which means that downgrading is possible if required.

If you are already using TeamCity 2017.2, use the Updates page for an automatic update.

Update 1721

To upgrade from older versions, download TeamCity 2017.2.1 and install it on your server.

We’ll appreciate your feedback: feel free to use our forum and tracker.

Happy building!

Posted in Bugfix, Release | Tagged | Comments Off on TeamCity 2017.2.1 is released

What’s New in TeamCity 2017.2, December 20th Webinar

Join us Wednesday, December 20th, 16:00 – 17:00 CEST (10:00 AM – 11:00 AM Eastern) for our free live webinar, What’s New in TeamCity 2017.2 with Wes Higbee.

r (1)

In this webinar, Wes Higbee will go over some of the major features of the latest TeamCity release. He will demonstrate how the Docker-specific build runners and the new Docker support build features work; the built-in .NET CLI support for building the .NET Core projects; the new composite builds for aggregating build results; as well as the default and multiple templates.

Space is limited, so please register now. There will be an opportunity to ask questions during the webinar.

About the presenter:

Wes McClureWes Higbee is passionate about helping companies achieve remarkable results with technology and software. He’s had extensive experience developing software and working with teams to improve how software is developed to meet business objectives. Wes launched Full City Tech to leverage his expertise to help companies rapidly deliver high quality software to delight customers. He has a strong background in using Continuous Integration with TeamCity to bring quality to the table.
Posted in Features, Webinar | Comments Off on What’s New in TeamCity 2017.2, December 20th Webinar