TeamCity Data Directory

This is the directory used by TeamCity to store configuration and system files. It is usually named .BuildServer. The config subdirectory contains the configuration of your TeamCity projects, and the system subdirectory contains build logs, artifacts, and database files (if HSQLDB is being used by default). See more on the directory structure data_directory_structure.

By default, the <TeamCity data directory> is placed in the user's home directory (e.g. it is $HOME/.BuildServer under Linux and C:\Documents and Settings\<user_name>\.BuildServer) under Windows. Alternatively, you can define this directory in one of the following ways:

• as a Tomcat system property teamcity.data.path (see TeamCity Startup Properties

• in the TEAMCITY_DATA_PATH environment variable (this will be used if the teamcity.data.path JVM system property is not found)

The TeamCity Windows installer can configure the TeamCity data directory during one of the installation steps.

The data directory used by the running TeamCity server can be looked up on the Administration > Server Configuration page.

Structure of TeamCity Data Directory

• .BuildServer/config — a directory where projects, build configurations and general server settings are stored.

  • <project name> — configuration settings specific to a particular project

    • project-config.xml — main project configuration, contains configurations of a project's Build Configuration

    • plugin-settings.xml — auxiliary project settings, like custom project tabs content

    • project-config.xml.N and plugin-settings.xml.N--- backup copies of corresponding files created when a project's configuration is changed via web UI

    • <buildConfigurationID>.buildNumbers.properties — build number settings for a build configuration with internal id "buildConfigurationID"

  • _trash — backup copies of deleted projects, it's OK to delete them manually.

  • main-config.xml — server-wide configuration settings

  • database.properties — database connection settings

  • vcs-roots.xml — VCS roots configurations file (both shared and not shared)

  • roles-config.xml — roles-permissions assignment file

  • email-config.xml — the e-mail notification template

  • jabber-config.xml — the Jabber notification template

  • win32-config.xml — the Windows Tray Notifier notification template

  • ide-notificator-config.xml — the IDE notification template

  • default-feed-item-template.ftl — default RSS feeds template

• .BuildServer/plugins — a directory where TeamCity plugins can be stored to be loaded automatically on TeamCity start. The structure of a plugin is described in Plugins Packaging.

• .BuildServer/system — a directory where build results data are stored, namely:

  • license.keys — a file which stores the license keys entered into TeamCity.

  • responsibles.xml — a file which stores the Responsibility data.

  • artifacts — a directory where the builds' artifacts are stored. The format of artifact storage is <project name>/<build configuration name>/<internal_build_id>

  • messages — a directory where Build Log are stored in internal format. Please note that test output and test failure details are stored in the build log files on disk.

  • changes — a directory where the Personal Build changes are stored in internal format.

  • buildserver.* — a set of files pertaining to the embedded HSQLDB.

  • version.dat — a file which contains the internal version of the configuration files and database. For backup purposes, ensure it is saved/restored in sync with other data files and the database data.

  • caches — a directory with internal caches (of the VCS repository contents, search index). It can be manually deleted to clear caches: they will be restored automatically as needed. However, it's more safe to delete the directory while server is not running.

Direct configuration files modifications

The files in the config directory can be edited manually. They can even be edited without stopping the server. TeamCity monitors these files for changes and rereads them automatically when modifications are detected. Bear in mind that it is easy to break the physical or logical structure of these files, so edit them with extreme caution. Always TeamCity Data Backup your data before making any changes.