What’s new in TeamCity 2019.2

TeamCity 2019.2 gives you great new ways to manage the clean-up of your builds and to monitor your server’s performance. It supports EC2 launch templates, and features a new DSL syntax for defining build chains. It also provides an easy way to run personal builds with Git patches, and adds many improvements to the experimental UI.

Power up your clean-up

TeamCity 2019.2 opens new dimensions of control over the historical data and artifacts created by your builds. A reworked clean-up engine allows you to set up different clean-up policies with a wide spectrum of filters: for example, you may choose to keep all builds from specific branches, or with specific tags.

We believe that new clean-up rules will be particularly useful for companies that have a lot of projects, and for teams that use feature branches during development.

Clean-up rules in TeamCity

Bird’s eye of your CI

Pros love tools that help them monitor how mission-critical systems are behaving and performing. Starting with 2019.2, TeamCity exposes its metrics via an HTTP endpoint, so they can be scraped by Prometheus and then visualized via the Prometheus web interface, or in a Grafana dashboard.

The metrics include the server performance information, as well as various details on agents, projects, and build configurations.

TeamCity metrics in Prometheus

Scalability, taken further

For many large organizations, a high-performance CI is critical to their workflows. TeamCity takes another step toward a multi-node setup allowing you to add builds to the build queue, manage build problems and investigations, and perform other user-level actions – now on a secondary server.

More ways to be productive with experimental UI

Developers often open TeamCity many times a day, which is why we want it to be a place where they can quickly find what they need, regardless of the size and complexity of their projects. Following the TeamCity UI roadmap, we are introducing a new build page that gives you an easy way to browse build history, investigate problems, and discover any misconfigurations or bottlenecks in your build chains.

Check out the experimental UI – we're proud of how it now looks and feels.

New build page in experimental UI

EC2 launch templates. Builds taken to new heights

We want TeamCity to have everything you need in a modern workflow. Version 2019.2 adds support for EC2 launch templates, and lets you run cloud build agents using the launch parameters from your AWS account. With the launch templates, updating and installing new software on build agents becomes a very simple and straightforward task – you no longer need to change anything in the TeamCity project configuration.

Support for EC2 launch templates

Level up your DSL

Build chains, built easily

Goodbye clicking, hello scripting. The Kotlin DSL now provides a simple and very straightforward syntax for defining build chains. Set up sequential and parallel builds, configure failure conditions and dependencies – and store everything as code.

Many parameters. One template.

Project configuration just got easier. Starting with 2019.2, your Kotlin DSL configurations may include custom parameters, which you can define later when importing the project in the UI.

Run more. Wait less. Start builds with Git patches.

Quickly test your changes by creating a Git patch, uploading it to TeamCity, and running a personal build – without creating any branches or committing anything.

For the full list of changes in version 2019.2, see the TeamCity documentation.

What’s new in 2019.1

New look, new feel, fewer clicks

TeamCity UI is getting a major overhaul, and here’s a first taste of what you’re going to get in this version.

Not only have we improved the look, but we've also updated the underlying technology stack so now the UI works as a single-page application, which means you can access parts of it faster and all the changes appear instantly. See the TeamCity UI roadmap to stay up to date with all the planned changes.

In 2019.1, we are targeting the pages related to working with projects and build configurations.

Project overview

The new project overview presents you with a dashboard-style view over your build configurations. Each configuration gets its own card which displays a histogram with up to 14 of the latest builds. For each of the builds, you can see the status (green means successful, red is failed), build time, and how long the build has spent in the queue. There is also information about the build that is currently running.

The Branches tab

The reworked Branches tab displays your default branch at the top, hiding the rest of the branches in an expandable block underneath. The details of the latest builds in the default branch can now be seen right away which increases the visibility of the important data.


Full GitLab support out of the box


Using GitLab? TeamCity 2019.1 adds full support for GitLab. You can now set up a GitLab connection and create projects in TeamCity with one click, by simply picking a GitLab project from the list.

We’ve also added support for GitLab merge requests, so you can now set TeamCity up to automatically run the build on each merge request and then automerge it if the build is successful.

Go all the way


The Go language is now supported natively by TeamCity. Add your Go projects and TeamCity will detect and report Go tests, providing rich insights into the test status, its history across the builds, and duration, and will mark unstable tests as flaky. With the Test History tab, you can now dig deeper into your Go tests.

Token-based authentication

In addition to basic HTTP authentication, TeamCity now supports authentication based on permanent access tokens. Tokens are useful for REST API authentication, so that you don’t need to expose a user login and password in scripts.

Token-based authentication

Snapshot dependencies without sources synchronization

You can now turn off the synchronization of code revisions for the snapshot dependencies. This is handy when running deployments and lets you promote one of the older builds in the chain using the latest deployment configuration.

AWS Spot Fleet requests

With this more flexible way of creating Spot Instances, you can now have more granular control over your Spot Fleet. TeamCity 2019.1 lets you submit and edit the spot fleet configuration file and specify the strategy, set the target capacity, and add tags to your instances. It is a more advanced and cost-effective way of running your builds on AWS.

Processing build lifecycle on a secondary node

The secondary node now has an additional responsibility: processing the build lifecycle. If you turn it on, the secondary node will handle the build-related tasks, such as running and finishing builds, uploading artifacts, and failure conditions processing. This change expands the already broad list of tasks that you can offload from your main server onto a secondary one: collecting changes, serving as a read-only backup node, and now, processing the build lifecycle.

Processing build lifecycle
Processing build lifecycle

On-demand tools loading

Tools will now only be loaded onto agents on demand. The necessary tools will be loaded only when the first build requiring them appears. This significantly improves the build agent upgrade times and saves you network traffic.

There is more to this release! Find out about the other new features.

What’s new in 2018.2

Increase scalability with a secondary TeamCity node

The secondary TeamCity node is designed to take the load off the main TeamCity server by taking over the task of collecting and checking for changes from the Version Control Systems. Outsourcing the collecting of VCS changes to the secondary node thus increases the scalability of the whole installation. It is also possible to use the secondary node for a high availability setup.

  • Polling
  • Commit Hook

Build GitHub pull requests

TeamCity now extends its support for GitHub pull requests. Filter the pull requests by author and limit it to internal or external collaborators, or open it for everyone. There is also the option to filter the pull requests by target branch.

Improved experience for working with plugins

Install from the plugin repository

You can now browse and install plugins in TeamCity directly from the JetBrains plugin repository.

No server restart

Once a plugin is installed from the plugin repository, you no longer need to restart the TeamCity server for it to be applied.

Hassle-free plugin development

Similarly, when developing a plugin for TeamCity, there is no need to restart the server anymore.

Add screenshots in test results

TeamCity 2018.2 lets you add screenshots and other test data, such as links, artifacts, logs, and numeric values, to the test results. These will be displayed natively in the test details section of the UI.

Preview settings in Kotlin DSL

Unsure how best to describe a setting in the Kotlin DSL format? TeamCity now automatically generates DSL code for all your settings and lets you preview it in the admin UI. Handy for learning DSL format or for just copying parts of DSL to insert into already existing settings.kts file.

Assign investigations automatically

You can now let TeamCity suggest or automatically assign investigations to team members based on a number of heuristics. That way the person who most likely broke a build will receive a notification to investigate the failure.

Multiple NuGet feeds

TeamCity 2018.2 lets you specify multiple NuGet feeds to be used by builds in a project and all its subprojects. It also introduces support for NuGet Server API v3.

What’s new in 2018.1

TeamCity Professional is FREE

Up to 100 build configurations and 3 concurrent builds. No user or time limits. Fully featured.

Welcome new Kotlin DSL

Kotlin DSL has been significantly reworked and improved and now allows simpler usage, portability, and creation of projects from just one file.


The format of the DSL has been simplified. TeamCity no longer requires uuid and project IDs, which makes the code simpler and more readable. As an example, this is all the code you would need for a basic “Hello world!” project in TeamCity:

All in one

One .teamcity/settings.kts file is now all you need to describe the project settings.


Kotlin DSL scripts are now server and project independent, which means you can share the same script between different servers or even projects on the same server. All you need to do is to check it into the repository.

Create from URL

When creating a project in TeamCity, just point it to the repository with your .teamcity/settings.kts file and TeamCity will automatically create the project with all the required settings and build configurations, as described in code.

Learn More about Kotlin DSL

High Availability

Spin up a High Availability TeamCity installation with the new read-only server mode. The read-only server has access to the database and the data directory, and in the event of the main server becoming unavailable, will accept all the requests and allow read access to the builds, artifacts, etc. Handy for running seamless server upgrades or during unplanned downtime.

IDE Plugin
Build Agents
TC Main Server
TC Main Server
TC Read-Only Server
TC Read-Only Server
NAS Data Directory
  • Main Server is Up
  • Mains Server is Down

Revamped Docker support

Docker support has been significantly improved:

Docker wrapper now supports .NET CLI and PowerShell runners.

build, push, and other Docker commands are now available directly in the new Docker runner, which replaces the old Docker Build Runner.

Bundled Amazon S3 artifact storage

TeamCity 2018.1 comes with built-in Amazon S3 support. Storing, uploading, downloading, and removing artifacts from S3 is now integrated natively and can be done via the TeamCity UI. The integration handles the dependencies and clean-up so that users wouldn’t even need to know that S3 is under the hood.