For a live site deployment, the system is scaled by being installed on a server cluster containing control pool and work pool servers. When the web pool contains more than one machine, you can use an external load balancer, or round-robin DNS, to share the load between the web pool machines.
In the following diagram, the arrow directions indicate connection requests from one system component to the component to which the arrow points. Where an arrow points from A to B, A must be able to see B, and B must accept requests from A on the specified port.
All LGTM components use secure channels, protected by SSL certificates, to communicate with each other. LGTM also uses secure connections to fetch source code from your repositories, provided that you configure the repository host and LGTM to use secure connections. For more information, see
The architecture of LGTM workers is similar to that of continuous integration tools like Jenkins and Atlassian Bamboo. That is:
- No barriers are enforced between builds running on the same machine, either concurrently or consecutively.
- A single operating system user name is used for multiple build and analysis tasks.
- Data is cached between tasks on LGTM workers to improve performance. This is principally the data extraction tools, but may also include the credentials required to access one or more repositories.
- The LGTM configuration for a repository, which controls the build and analysis process, is stored in the repository.
If you're concerned about securing one or more codebases from potential attacks by your own developers, deploy a separate instance of LGTM for these projects. Set this instance up to run its worker daemons on machines that serve exclusively as worker hosts for this LGTM.