You are viewing the documentation of TeamCity 10.x and 2017.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.


Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • man-in-the middle concerns
    • between the TeamCity server and the user's web browser: It is advised to use HTTPS for the TeamCity server. During login, TeamCity transmits the user login password in an encrypted form with a moderate encryption level.
    • between a TeamCity agent and the TeamCity server: see the section.
    • between the TeamCity server and other external servers (version control, issue tracker, etc.): the general rules apply as for a client (the TeamCity server in the case) connecting to the external server, see the guidelines for the server in question.
  • users that have access to the TeamCity web UI: the specific information accessible to the user is defined via TeamCity user roles.
  • users who can change the code that is used in the builds run by TeamCity: the users have the same permissions as the system user under whom the TeamCity agent is running. Have access to OS resources and other applications installed on the same machine. Can access and change source code of other projects built on the same agent, modify the TeamCity agent code, publish any files as artifacts for the builds built run on the agent (which means the files can be then displayed in the TeamCity web UI and expose web vulnerabilities or can be used in other builds), etc. Can impersonate a TeamCity agent (run a new agent looking the same on to the TeamCity server). Also, the users can do everything that users with the "View build configuration settings" permission for all the projects on the server can do (see below). It is advised to run TeamCity agents under users with only necessary set of permissions and use the agent pools feature to insure ensure that projects requiring a different set of access are not built on the same agents.
  • users with the "View build configuration settings" permission (the "Project developer" TeamCity role by default) can view all the projects on the server, but since TeamCity 9.0 there is a way to restrict this, see details in the corresponding issue TW-24904.

  • users with the "Edit project" permission (the "Project Administrator" TeamCity role by default) in one project, by changing settings can retrieve artifacts and trigger builds from any build configuration they have only the view permission for (TW-39209).
  • users with the "Change server settings" permission (the "System Administrator" TeamCity role by default): It is assumed that the users also have access to the computer on which the TeamCity server is running under the user account used to run the server process. Thus, some operations like server file system browsing can be accessible by the users.
  • TeamCity server computer administrators: have full access to TeamCity stored data and can affect TeamCity executed processes. Passwords that are necessary to authenticate in external systems (like VCS, issue trackers, etc.) are stored in a scrambled form in TeamCity Data Directory and can also be stored in the database. However, the values are only scrambled, which means they can be retrieved by the users who have access to the server file system or database.
  • Users who have read access for TeamCity server logs (TeamCity server home directory) can escalate their access to TeamCity server administrator
  • Users who have read access to TeamCity Data Directory can access all the settings on the server, including configured passwords
  • Users who have read access to the build artifacts in TeamCity Data Directory (<TeamCity Data Directory>\system\artifacts) get the same permissions as users with the "View build runtime parameters and data" permission (in particular, with access to the values of all the password parameters used in the build)
  • TeamCity agent computer administrators: same as "users who can change code that is used in the builds run by TeamCity".
  • TeamCity users with administrative permissions have non-trivial passwords
  • When storing settings in VCS is enabled:
    • any user who can access the settings repository (including users with "View file content" permission for the build configurations using the same VCS root) can see the settings and retrieve the actual passwords based on their stored scrambled form
    • any user who can modify settings in VCS for a single build configuration built on the server, via changing settings can retrieve artifacts and trigger builds from any build configuration they have only view permission for (TW-39192).
    • users who can customize build configuration settings on a per-build basis (e.g. one who can run personal builds when versioned settings are set to "use settings from VCS") via changing settings in a build can retrieve artifacts and trigger builds from any build configuration they have only view permission for (TW-46065).
  • Other:
    • TeamCity web application vulnerabilities: the TeamCity development team makes a reasonable effort to fix any significant vulnerabilities (like cross-site scripting possibilities) once they are uncovered. Please note that any user that can affect build files ("users who can change code that is used in the builds run by TeamCity" or "TeamCity agent computer administrators") can make a malicious file available as a build artifact that will then exploit cross-site scripting vulnerability. (TW-27206)
    • TeamCity agent is fully controlled by the TeamCity server: since TeamCity agents support automatic updates download from the server, agents should only connect to a trusted server. An administrator of the server computer can force execution of arbitrary code on a connected agent.


TeamCity tries not to pass password values in the web UI (from a browser to the server) in clear text and uses RSA with 1024 bit key to encrypt them. However, it is recommendd recommended to use the TeamCity web UI only via HTTPS so this precaustion shoul dnot precaution should not be relevant.
TeamCity stores passwords in the settings (where the original password value is necessary to perform authentication in other systems) in a scrambled form. The scrambling is done using 3DES with a fixed key.

TeamCity stores user passwords when built-in authentication is used in solteda salted hashed (MD5) form.
Hidden because of https://youtrack.jetbrains.com/issue/TW-41757