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 your repositories, provided that you configure the repository host and LGTM to use secure connections.
The architecture of LGTM workers is similar to that of continuous integration tools like Jenkins and Atlassian Bamboo. The build and analysis processes run using a single operating system user name for multiple builds. LGTM does not enforce any barriers between builds running on the same machine, either concurrently or consecutively.
Individuals with write access to the LGTM build and analysis configuration for a project can specify exactly which commands are run during the analysis. LGTM configuration files are stored in the repository with the source code, consequently any changes to them are subject to your organization's code review process.
If a malicious developer wanted to introduce an LGTM configuration that accessed the source code of other projects, they would need to submit it as a normal code change. Depending on the configuration of the version control system, this may be apparent in commits, limiting the severity and likelihood of such an activity.
If you're concerned about securing one or more code bases from potential attacks by your own developers, you are advised to run a separate installation of LGTM Enterprise for such projects with workers run on dedicated machines.