- server started in build messages processor mode handles all of the data produced by running builds (build logs, artifacts, statistic values), pre-processes it and stores it in the database and on disk
- in a two-node installation the main TeamCity server handles all other tasks: user interface, VCS related activity, management of agents, etc.
- both the main TeamCity server and the build messages processor require access to the same data directory (which must be shared somehow if the nodes are installed on separate machines) and to the same database
- the URL where the build messages processor operates must be accessible by the agents and the main TeamCity server (occasionally the main TeamCity server also communicates with the build messages processor by HTTP)
First of all, ensure that both machines where TeamCity software will be installed can access the same TeamCity data directory in read/write mode. For large installations we recommend using NAS. It is possible to share directory using NFS, or Windows share, although the performance of such installation can be worse.
<processor url> is the URL of the build messages processor. This URL must be accessible by both the agents and main server. If you do not have an HTTP proxy installed in front of the TeamCity servlet container and you did not change the port in the servlet container during the installation, then by default this URL will be:
http://<your host name>:8111/
Startup & shutdown
Both main TeamCity server and build messages processor can be started / stopped using regular TeamCity scripts : (
teamcity-server.sh) or Windows services.
The build messages processor uses the same approach to logging as the main server. You can check how the startup is doing in the
teamcity-server.log file. You can also open
<processor URL> in your browser, there you should see regular TeamCity startup screens.