Supported Platforms and Environments

Platforms (Operating Systems)

Web Browsers

The TeamCity Web Interface is mostly W3C-compliant, so just about any modern browser should work well with TeamCity. The following browsers have been specifically tested and reported to work correctly in the recent versions of:

• Google Chrome

• Mozilla Firefox

• Safari under Mac

• Microsoft Edge

• Microsoft Internet Explorer 11+. Support for Internet Explorer 10 is discontinued since TeamCity 2018.1.4.

• Opera 15+

Build Runners

TeamCity supports a wide range of build tools, enabling both Java and .NET software teams to build their projects.

Testing Frameworks

• JUnit 3.8.1+, 4.x

• NUnit 2.2.10, 2.4.x, 2.5.x, 2.6.x, 3.0.x are supported (dedicated build runner).

• TestNG 5.3+

• MSTest 8.x-12.x,14.x, 15.x, 19.x and VSTest are supported by the Visual Studio Tests runner; requires the appropriate Microsoft Visual Studio edition or Visual Studio Test Agent installed on the build agent.

• MSpec (requires MSpec installed on the build agent)

Version Control Systems

• Git (for automatic git gc support requires Git client installed on the server in order to perform maintenance of Git clones, latest version is recommended)

• Subversion (server versions 1.4-1.9 and higher as long as the protocol is backward compatible).

• Perforce (requires a Perforce client installed on the TeamCity server). Check compatibility issues.

• Perforce (requires a Perforce client installed on the TeamCity server). Check compatibility issues.

• Team Foundation Server 2005, 2008, 2010, 2012, 2013, 2015, 2017 are supported.

• Mercurial (requires the Mercurial "hg" client v1.5.2+ installed on the server)

• CVS

• SourceGear Vault 6 and 7 (requires the Vault command line client libraries installed on the TeamCity server), integrated via an additional plugin

• Borland StarTeam 6 and up (the StarTeam client application must be installed on the TeamCity server)

• IBM Rational ClearCase Base and UCM modes (requires the ClearCase client installed and configured on the TeamCity server), integrated via an additional plugin

• Microsoft Visual SourceSafe 6 and 2005 (requires a SourceSafe client installed on the TeamCity server, available only on Windows platforms)

For support for other VCS please check external plugins available.

Cloud Agents Integration

• Amazon EC2
• VMWare vSphere

See also details on the cloud integrations and non-bundled and third-party cloud integration plugins.

VCS Hosting Services Integration

• GitHub / GitHub Enterprise
• GitLab
• Bitbucket Cloud

• Azure DevOps Services, or formerly Visual Studio Team Services

Issue Tracker Integration

• JetBrains YouTrack 1.0 and later (tested with the latest version)

• Atlassian Jira 4.4 and later (all major features also reportedly worked for version 4.2)

• Bugzilla 3.0 and later (tested with Bugzilla 5.0.1)

• GitHub
• Bitbucket

• Azure DevOps Server (formerly Visual Studio Team Foundation Server – supported version 2012 or later, and Azure DevOps Services are supported)

Additional requirements are listed in Integrating TeamCity with Issue Tracker.

Links to issues of any issue tracker can also be recognized in change comments using Mapping External Links in Comments.

IDE Integration

TeamCity provides productivity plugins for the following IDEs:

• Eclipse: Eclipse versions 3.8 and 4.2-4.6 are supported. Eclipse must be run under JDK 1.5+

• IntelliJ Platform Plugin: compatible with IntelliJ IDEA 15.0.x - 2019.3.x (Ultimate and Community editions); as well as other IDEs based on the same version of the platform, including JetBrains RubyMine 6.3+, JetBrains PyCharm 3.1+, JetBrains PhpStorm/WebStorm 7.1+, AppCode 2.1+. See more information on compatibility.

• Microsoft Visual Studio 2010, 2012, 2013, 2015, 2017 is supported by the TeamCity Visual Studio Add-in shipped as a part of ReSharper Ultimate. Installed .NET Framework is required.

Supported Databases

See more at Setting up an External Database

• HSQLDB 2.3.2
  The internal database suits evaluation purposes only; we strongly recommend using an external database in a production environment.

• MySQL 5.0.33+, 5.1.49+, 5.5+, 5.6+, 5.7+, 8+ (Note that due to bugs in MySQL, versions 5.0.20, 5.0.22 and 5.1 up to 5.1.48 are not compatible with TeamCity)

• Microsoft SQL Server 2005 or later (including Express editions), SQL Azure; SSL connections support might require these updates.

• PostgreSQL 8.2 and newer

• Oracle 10g and newer (TeamCity is tested with driver version 12.1.0.1)

Estimate Hardware Requirements for TeamCity

The hardware requirements differ for the server and the agents.

The agent hardware requirements are basically determined by the builds that are run. Running TeamCity agent software introduces a requirement for additional CPU time (but it can usually be neglected comparing to the build process CPU requirements) and additional memory: about 500Mb. The disk space required corresponds to the disk usage by the builds running on the agent (sources checkouts, downloaded artifacts, the disk space consumed during the build; all that combined for the regularly occurring builds). Although you can run a build agent on the same machine as the TeamCity server, the recommended approach is to use a separate machine (it may be virtual) for each build agent. If you chose to install several agents on the same machine, consider the possible CPU, disk, memory or network bottlenecks that might occur. The Performance Monitor build feature can help you in analyzing live data.

The server hardware requirements depend on the server load, which in its turn depends significantly on the type of the builds and server usage. Consider the following general guidelines.

Database Note:When
using the server extensively, the database performance starts to play a greater role.
For reliability and performance reasons you should use external database.
See the notes on choosing external database.
The database size requirements naturally vary based on the amount of data stored (number of builds, number of tests, and so on). The active server database usage can be estimated at several gigabytes of data per year.

Overview of the TeamCity hardware resources usage:

• CPU: TeamCity utilizes multiple cores of the CPU, so increasing number of cores makes sense. For non-trivial TeamCity usage at least 4 CPU cores are recommended.

• Memory: used by the TeamCity server main process and child processes (used for Maven integration, version control integration, Kotlin DSL execution). See the notes on the main process memory usage. Generally, you will probably not need to dedicate more than 4G of memory to TeamCity server if you do not plan to run more than 100 concurrent builds (agents), support more than 200 online users or work with large repositories.

• HDD/disk usage: This sums up mainly from the temp directory usage (<TeamCity Home>/temp and OS default temp directory) and <TeamCity Data Directory>/system usage. Performance of the TeamCity server highly depends on the disk system performance. As TeamCity stores large amounts of data under <TeamCity Data Directory>/system (most notably, VCS caches and build results) it is important that the access to the disk is fast (in particular reading/writing files in multiple threads, listing files with attributes). Ensuring disk has good performance is especially important if you plan to store the Data Directory on a network drive. It is recommended to use local storage for TeamCity Data Directory/system/caches directory. See also TeamCity Data Directory.

• Network: This mainly sums up from the traffic from VCS servers, to clients (web browsers, IDE, etc.) and to/from build agents (send sources, receive build results, logs and artifacts).

The load on the server depends on:

• number of build configurations;

• number of builds in the history;

• number of the builds running daily;

• amount of data consumed and produced by the builds (size of the used sources and artifacts, size of the build log, number and output size of unit tests, number of inspections and duplicates hits, size and number of produced artifacts, and so on);

• clean-up rules configured

• number of agents and their utilization percentage;

• number of users having TeamCity web pages open;

• number of users logged in from IDE plugin;

• number and type of VCS roots as well as the configured checking for changes interval for the VCS roots. VCS checkout mode is relevant too: server checkout mode generates greater server load. Specific types of VCS also affect server load, but they can be roughly estimated based on native VCS client performance;

• number of changes detected by TeamCity per day in all the VCS roots;

• the size of the repositories TeamCity works with;

• total size of the sources checked out by TeamCity daily.

A general example of hardware configuration capable to handle up to 100 concurrently running builds and running only TeamCity server can be:
Server-suitable modern multi-core CPU, 8Gb of memory, fast network connection, fast and reliable HDD, fast external database access.

Based on our experience, a modest hardware likeIntel 3.2 GHz dual core CPU, 3.2Gb memory under Windows, 1Gb network adapter, single HDDcan provide acceptable performance for the following setup:

• 60 projects and 300 build configurations (with one forth being active and running regularly);

• more than 300 builds a day;

• about 2Mb log per build;

• 50 build agents;

• 50 web users and 30 IDE users;

• 100 VCS roots (mainly Perforce and Subversion using server checkout), average checking for changes interval is 120 seconds;

• more than 150 changes per day;

• Kotlin DSL is not used;

• the database (MySQL) is running on the same machine;

• TeamCity server process has -Xmx1100m JVM setting.

The following configuration can provide acceptable performance for a more loaded TeamCity server:Intel
Xeon E5520 2.2 GHz CPU (4 cores, 8 threads), 12Gb memory under Windows Server 2008 R2 x64, 1Gb network adapter, 3 HDD RAID1 disks (general, one for artifacts, logs and caches storage, and one for the database storage)

Server load characteristics:

• 150 projects and 1500 build configurations (with one third being active and running regularly);

• more than 1500 builds a day;

• about 4Mb log per build;

• 100 build agents;

• 150 web users and 40 IDE users;

• 250 VCS roots (mainly Git, Hg, Perforce and Subversion using agent-side checkout), average checking for changes interval is 180 seconds;

• more than 1000 changes per day;

• the database (MySQL) is running on the same machine;

• TeamCity server process has -Xmx3700m x64 JVM setting.

However, to ensure peak load can be handled well, more powerful hardware is recommended.

HDD free space requirements are mainly determined by the number of builds stored on the server and the artifacts size/build log size in each. Server disk storage is also used to store VCS-related caches and you can estimate that at double the checkout size of all the VCS roots configured on the server.

If the builds generate large number of data (artifacts/build log/test data), using fast hard disk for storing .BuildServer/system directory and fast network between agents and server are recommended.

The general recommendation for deploying large-scale TeamCity installation is to start with a reasonable hardware while considering hardware upgrade. Then increase the load on the server (e.g. add more projects) gradually, monitoring the performance characteristics and deciding on necessary hardware or software improvements. There is also a benchmark plugin which can be used to estimate the number of simultaneous build the current server installation can handle. Anyway, best administration practices are recommended like keeping adequate disk defragmentation level, and so on.

Starting with an adequately loaded system, if you then increase the number of concurrently running builds (agents) by some factor, be prepared to increase CPU, database and HDD access speeds, amount of memory by the same factor to achieve the same performance.
If you increase the number of builds per day, be prepared to increase the disk size.

If you consider cloud deployment for TeamCity agents (for example, on Amazon EC2), also review Setting Up TeamCity for Amazon EC2

A note on the agents setup in JetBrains internal TeamCity installation:We use both separate machines each running a single agent and dedicated "servers" running several virtual machines each of them having a single agent installed. Experimenting with the hardware and software we settled on a configuration when each core7i physical machine runs 3 virtual agents, each using a separate hard disk. This stems form the fact that our (mostly Java) builds depend on HDD performance in the first place. But YMMV.

TeamCity is known to work well with 500+ build agents (500 concurrently running builds actively logging build run-time data). In synthetic tests the server was functioning OK with as many as 1000 concurrent builds (the server with 8 cores, 32Gb of total memory running under Linux, and MySQL server running on a separate comparable machine). The load on the server produced by each build depends on the amount of data the build produces (build log, tests number and failure details, inspections/duplicates issues number, etc.). Keeping the amount of data reasonably constrained (publishing large outputs as build artifacts, not printing those into standard output; tweaking inspection profiles to report limited set of the most important inspection hits, etc.) will help scale the server to handle more concurrent builds.
If you need much more agents/parallel builds, it is recommended to use several nodes setup. If a substantially large amount of agents is required, it is recommended to consider using several separate TeamCity instances and distributing the projects between them. We constantly work on TeamCity performance improvements and are willing to work closely with organizations running large TeamCity installations to study any performance issues and improve TeamCity to handle larger loads.