TeamCity provides a number of build parameters which are ready to be used in the settings of a build configuration or in build scripts.

On this page:

The predefined build parameters can originate from several scopes:

All these parameters are finally passed to the build.

There is also a special kind of server-side build parameters that can be used in references while defining other parameters, but which are not passed into the build. See Configuration Parameters below for the list of such properties.

The most up-to-date list of parameters can be obtained in the TeamCity web UI while defining a text value supporting parameters: either click on icon to the right of the text field, or enter "%" in the text field.

Server Build Properties

System Property Name

Environment Variable Name




The version of TeamCity server. This property can be used to determine the build is run within TeamCity.



The name of the project the current build belongs to.



The name of the Build Configuration the current build belongs to.


Is set to true if the build is a personal one. Is not defined otherwise.



The build number assigned to the build by TeamCity using the build number format. The property is assigned based on the build number format.


The internal unique id used by TeamCity to reference builds.



A generated username that can be used to download artifacts of other build configurations. Valid only during the build.



A generated password that can be used to download artifacts of other build configurations. Valid only during the build.

build.vcs.number.<VCS root ID>


The latest VCS revision included in the build for the root identified. See Configuring VCS Roots for the <VCS root ID> description. If there is only a single root in the configuration, the build.vcs.number property (without the VCS root ID) is also provided.

Please note that this value is a VCS-specific (for example, for SVN the value is a revision number while for CVS it is a timestamp)

In versions of TeamCity prior to 4.0, a different format for the VCS revision number when specified in a build number pattern was used: {build.vcs.number.N} where N is the VCS root order number in the build configuration. If you still need this to work, you can launch TeamCity with a special internal option:


Configuration Parameters

{show-if:mode=edit} These properties are available only *since TeamCity 4.5*. In TeamCity 4.0.x you could only use [#Dependencies Properties] in the build number and VCS labeling pattern.{show-if}
These are the parameters that other properties can reference (only if defined on the Build Parameters page), but that are not passed to the build themselves.

You can get the full set of such server properties by adding the system.teamcity.debug.dump.parameters property to a build configuration and examining the "Available server properties" section in the build log.

Among these properties are the following:

Dependencies Properties

These are properties provided by the builds the current build depends on (via a snapshot or an artifact dependency).

Dependencies properties have the following format:

dep.<btID>.<property name>

VCS Properties

These are the settings of VCS roots attached to the build configuration.

VCS properties have the following format:

vcsroot.<VCS root ID>.<VCS root property name>

If there is only one VCS root in a build configuration, the <VCS root ID>. part can be omitted.

Properties marked by the VCS support as secure (for example, passwords) are not available as reference properties.

Branch-Related Parameters

When TeamCity starts a build in a build configuration where Branch specification is configured, it adds a branch label to each build. This logical branch name is also available as a configuration parameter:

To distinguish builds started on a default and a non-default branch, there is an additional boolean configuration parameter available since 7.1.5 which allows differentiating these cases:|false

For Git & Mercurial, TeamCity provides additional parameters with the names of VCS branches known at the moment of the build start. Note that these may differ the from the logical branch name as per branch specification configured.
This VCS branch is available form a configuration parameter with the following name:<VCS root ID>

Where <VCS root ID> is the VCS root ID as described on the Configuring VCS Roots page.

Other Parameters

Parameter Name


Since TeamCity 8.1, a human-friendly description of how the build was triggered

Since TeamCity 8.1, if the build was triggered by a user, the username of this user is reported. When a build is triggered not by a user, this property is not reported.

Agent Properties

Agent-specific properties are defined on each build agent and vary depending on its environment. Aside from standard properties (for example, or teamcity.agent.jvm.os.arch, etc. — these are provided by the JVM running on agent) agents also have properties based on installed applications. TeamCity automatically detects a number of applications including the presence of .NET Framework, Visual Studio and adds the corresponding system properties and environment variables. A complete list of predefined agent-specific properties is provided in the table below.

If additional applications/libraries are available in the environment, the administrator can manually define the property in the <agent home>/conf/ file. These properties can be used for setting various build configuration options, for defining build configuration requirements (for example, existence or absence of some property) and inside build scripts. For more information on how to reference these properties, see the Defining and Using Build Parameters in Build Configuration page.

In the TeamCity Web UI, the actual properties defined on the agent can be reviewed by going to the Agents tab at the top navigation bar|<Agent>|<Agent> page|the Agent Parameters tab:

Predefined Property


The name of the agent as specified in the agent configuration file. Can be used to set a requirement of build configuration to run (or not run) on particular build agent.

The path of Agent Work Directory.


The path of Agent Home Directory.

The corresponding JVM property (see JDK help for properties description)


The corresponding JVM property


The corresponding JVM property

The corresponding JVM property


The corresponding JVM property


The corresponding JVM property

The corresponding JVM property


The corresponding JVM property


The corresponding JVM property


The corresponding JVM property


The corresponding JVM property


The corresponding JVM property


This property is defined if the corresponding version(s) of .NET Framework is installed. (Supported versions are 1.1, 2.0, 3.5, 4.0)


This property value is set to the corresponding framework version(s) path(s)


This property is defined if the corresponding version(s) of .NET Framework SDK is installed. (Supported versions are 1.1, 2.0)


This property value is the path of the corresponding framework SDK version.


This property is defined if the corresponding version of Windows SDK is installed. (Supported versions are 6.0, 6.0A, 7.0, 7.0A, 7.1)


This property is defined if the corresponding version(s) of Visual Studio is installed


This property value is the path to the directory that contains devenv.exe


This property value is the path to the directory that contains the standalone NUnit test launcher, NUnitLauncher.exe. The version number refers to the version of .NET Framework under which the test will run. The version equals the version of .NET Framework and can have a value of 1.1, 2.0, or 2.0vsts.


The property value is the path to the directory that contains the MSBuild task dll providing the NUnit task for MSBuild, Visual Studio (sln).


The property value is the path to the directory that contains MSBuild 2.0 listener and tasks assemblies.


The property value is the path to the directory that contains MSBuild 4.0 listener and tasks assemblies.

  • Make sure to replace "." with "_" when using properties in MSBuild scripts; e.g. use teamcity_dotnet_nunitlauncher_msbuild_task instead of teamcity.dotnet.nunitlauncher.msbuild.task
  • _x86 and _x64 property suffixes are used to designate the specific version of the framework.
  • teamcity.dotnet.nunitlauncher properties cannot be hidden or disabled.

This is not supported

You can disable the automatic detection of the predefined properties by editing the {{}} file and adding the *disableDotNetDetection* property.

{note}Please note that {{disableDotNetDetection}} property is case-sensitive.{note}

This property can have the following values:
|| Value || Description \\ ||
| empty string | All versions of .NET Framework will be detected and added to the Agent Properties |
| '*' | All existing versions of .NET Framework will not be detected and thus not included in the Agent Properties |
| version number(s) (Values should be separated by commas) | Excludes versions of .NET Framework starting with that number |
| 'windowsSDK6.0' or 'w' | Excludes Windows SDK 6.0 |
| VS<X> | Excludes Visual Studio version <X>, where <X> can be 2003, 2005, 2008, 2010, 2012, 2013 or left blank to exclude all existing versions of Visual Studio \\ |
|| Examples || Description \\ ||
| {{disableDotNetDetection=3}} | Excludes .NET Framework 3.0, 3.5 and all other versions starting with 3 |
| {{disableDotNetDetection=1.1,2.0}} | Excludes .NET Framework versions 1.1 and 2.0 |
| {{disableDotNetDetection=w,2.0,VS2003}} | Excludes Windows SDK 6.0, .NET Framework 2.0 and Visual Studio 2003 |


Agent Environment Variables

An agent can define some environment variables. These variables can be used in build scripts as usual environment variables.

Java Home Directories

When a build agent starts, first the installed JDK and JRE are detected; when they are found, the Java-related environment variables are defined as described in the section below.

The environment variables are defined only if they are not already present in the environment: if a started agent already has the Java-related environment variables set, the are not redefined.

Detecting Java on Agent

The installed Java is searched for in the ALL locations listed below. Then, every discovered Java is launched to verify that it is a valid Java installation, and the Java version and bitness are determined based on the output.

The following locations are searched (a number of locations is common for all operating systems; some of them are OS-specific):

For All OS

OS-specific locations



The following directories are searched for for Java subdirectories:

Mac OS
The following directories are searched:

Defining Custom directory to Search for Java

You can define a custom directory on an agent to search for Java installations in by adding the property to the file.

You can define a list of directories separated by an OS-dependent character.

Defining Java-related Environment Variables

For each major version V of java, the following variables can be defined:

The JDK variables are defined when the JDK found, the JRE variables are defined when the JRE found but the JDK is not found.
The _x64 variables point to 64-bit java only; the variables without the _x64 suffix may points to both 32-bit or 64-bit installations but 32-bit ones are preferred.
If several installations with the same major version and the same bitness but different minor version/update are found, the latest one is selected.

In additional, the following variables are defined:

The JRE_HOME and JDK_HOME variables may points to different installations; for example, if JRE 1.7 and JDK 1.6 but no JDK 1.7 installed - JRE_HOME will point to JRE 1.7 and JDK_HOME will point to JDK 1.6.

All variables point to the java home directories, not to binary files. For example, if you want to execute javac version 1.6, you can use the following path:

In a TeamCity build configuration:


In a Windows bat/cmd file:


In a unix shell script:


Agent Build Properties

These properties are unique for each build: they are calculated on the agent right before build start and are then passed to the build.

System Property Name

Environment Variable Name



Checkout directory used for the build.


Working directory where the build is started. This is a path where TeamCity build runner is supposed to start a process. This is a runner-specific property, thus it has different value for each new step.


Full path of the build temp directory automatically generated by TeamCity. The directory will be cleaned after the build.


Full name (including path) of the file containing all the system.* properties passed to the build. "system." prefix stripped off. The file uses Java properties file format (for example, special symbols are backslash-escaped).


Full path to a file with information about changed files included in the build. This property is useful if you want to support running of new and modified tests in your tests runner. This file is only available if there were changes in the build.