BuildMaster Documentation

Architecture & Components

BuildMaster is comprised of several different components, which may be installed on different servers. See the installation guides for more details.


Web Application

This is how most users will interact with BuildMaster on a day-to-day basis, and manages the releases, applications, pipelines, plans, security, users, etc., and also hosts the API.

It is a standard ASP.NET application, and administrators familiar with IIS may tweak the application pool settings as needed. Note that modifying the web.config file for any purpose other than to change the database connection string or encryption key is not at all supported.


This runs in the background and actually runs your deployment plans using the execution engine. It's a standard Windows Service Application, and may be managed and configured using the Windows Service Manager or sc.exe as you see fit.

Note that modifying the BuildMaster.Service.config file for any purpose other than to change the database connection string or encryption key is not at all supported.

The Service page details how to administer this further.


This persists all of the release data, execution logs, pipelines, users, etc.

It is a standard SQL Server database, and administrators familiar with SQL Server may tweak the database settings as needed.


Sensitive data, most notably resource credentials, are encrypted before being stored. Obviously, the encryption key is not stored in the database, but in both the web.config file (used by the web application) and the BuildMaster.Service.config file (used by the service).


Experienced users are welcome to query data from the various tables, and sensitive information resource credentials are stored encrypted, and can only be decrypted by the service account. The tables/columns should be fairly obvious once you're familiar with the software, and we can answer any questions you may have about the data or relations.

We do not support... nay, we strongly discourage trying to modify any of the data in the tables directly. Instead, use the API or the non-internal Stored Procedures.


Agents are a lightweight service that are installed on remote servers that you want to configure and orchestrate. They use a highly-optimized and resilient protocol, and are secured (by default) using a FIPS-compliant symmetric AES encryption scheme.

Agents may also be configured to use SSL instead of built-in AES, see KB#1040 for those instructions.