TeamCity Configuration and Maintenance
tip
Server configuration is only available to the System Administrators.
To change the server configuration, go to Administration | Global Settings. The following blocks of settings are available:
Setting | Description |
|---|---|
Database | The database used by the running TeamCity server. |
Data Directory | The <TeamCity Data Directory> path with the ability to browse the directory. |
Artifact directories | The list of the root directories used by the TeamCity server to store Build Artifact, build logs and other build data. The default location is The list can be changed by specifying a new-line delimited list of paths. Absolute and relative (to TeamCity Data Directory) paths are supported. All the specified directories use the same structure. When looking for build artifacts, the specified locations are searched for the directory corresponding to the build. The search is done in the order the root directories are specified. The first found build artifacts directory is used as the source of artifacts of this build. Artifacts for the newly starting builds are placed under the first directory in the list. |
Caches directory | The directory containing TeamCity internal caches (of the VCS repository contents, search index, other). You can manually delete files from this directory to clear caches. |
Server URL | The configurable URL of the running TeamCity server. |
Setting | Description |
|---|---|
Maximum build artifact file size | Maximum size in bytes. KB, MB, GB or TB suffixes are allowed. |
Maximum number of artifacts per build | Limits the number of artifacts published per build.
|
Default build execution timeout | Maximum time for a build. Can be overridden when defining build failure conditions. |
Setting | Description |
|---|---|
Default VCS changes check interval | Set to 60 seconds by default. Specifies how often TeamCity polls the VCS repository for VCS changes. Can be overridden when configuring VCS roots. Additionally, you can enforce the interval of VCS changes check as a minimum polling interval for all VCS roots on the server. This way, Project Administrators will only be able to set intervals that are larger than the default one. This helps restrict the frequency of polling requests thus offloading the server. |
Default VCS trigger quiet period | Set to 60 seconds by default. Specifies a period (in seconds) that TeamCity maintains between the moment the last VCS change is detected and a build is added into the queue. Can be overridden when configuring VCS triggers. |
In this block, you can choose how TeamCity will process secure values: either using the default scrambling strategy or by encrypting them with a custom key.
By default, TeamCity stores all secure values, used in project configuration files, in a scrambled form. The initial values are stored in the TeamCity Data Directory, and their safety primarily depends on the security of your environment. To minimize the risk of potential malicious actions, TeamCity can encrypt secure values with your custom key.
To use the custom encryption, select the respective option and enter an encryption key. Click Generate key to randomly generate it, or enter your own key (128-bit keys encoded with Base64 are supported). After you save the settings, TeamCity will change the strategy from scrambling secure values to encrypting them with your custom key using the AES algorithm.
Any existing secure values will remain scrambled. Note that when you change any project parameters, all the project’s secure values are reencrypted automatically using the current key.
You can change the custom key or go back to using the default strategy anytime.
note
During backup, your custom keys will be exported along with their projects and automatically available after restoring from backup. Since keys will be stored in the exported files in an open form, make sure the backup files are well-protected.
Setting | Description |
|---|---|
Enable isolation protection | If enabled, build artifacts will be loaded from a separate domain and any potential malicious content will not be able to communicate with the TeamCity server on behalf of the user viewing this content. This mitigates the risk of XSS attacks through artifacts and of other related vulnerabilities. Note that this mode requires configuring a dedicated domain for TeamCity and properly routing it via proxy. To continue using artifacts for displaying some build results (for example, custom reports), you need to specify this domain's URL below. |
Artifacts' URL | Specify a URL to serve build artifacts from. Note the URLs for artifacts isolation and the TeamCity server must have different hostnames. Using different ports of the same hostname for both resources may lead to various problems, including failed builds and issues with signing in to TeamCity. On receiving a request for a content of some artifact, TeamCity will redirect your browser to a temporary URL that uses this artifacts' URL as a base. The temporary URL expires after some time to prevent unauthorized access to the artifact. Upon accessing the expired URL, a regular authentication will be performed and a new URL will be generated. For a personal TeamCity installation, which is accessible via localhost only, a URL like For a TeamCity server used by an organization, a new DNS name, or a Note: as this is a special URL which exists for serving artifacts only, users will not be able to sign in to the TeamCity interface via it. |
Thanks for your feedback!