# Admin Settings Reference
The Admin perspective provides a view for configuring various settings in Teamscale. Options that are not explained elsewhere are listed here:
TIP
You can also configure all of these settings using a configuration file.
# Setting: Teamscale instance base URL
This allows to set the URL Teamscale is running in. The value here is important for providing links to Teamscale in notification emails and exported files.
# Setting Group: Server Limits
This section describes the configurations to help protecting the server from being overloaded by too many requests.
# Setting: Pre-Commit Limits
Pre-commit analysis is triggered from the IDEs by developers. If a high number of developers is using this feature, a considerable number of requests is sent to the Teamscale server. The maximum number of files and the maximum individual file size per pre-commit as well as the minimum waiting time between pre-commit requests can be configured.
# Setting: Late External Upload Processing
When external analysis data (e.g., coverage) is uploaded to Teamscale, a rollback is performed to integrate the external data with code from the repository. Especially for old uploads that require a rollback of several days, the following reanalysis can take a considerable amount of time. As a solution to this problem, Teamscale can postpone these uploads to a time where such a reanalysis does not disrupt normal operation, e.g., during the night.
The setting requires a crontab expression that defines at which time rollbacks and reanalysis from those late uploads may be performed, and a threshold that defines how many minutes in the past an upload must be to be considered old. The setting is active if a non-empty crontab expression is provided.
# Setting: Git
This setting is relevant when Teamscale should connect to a Git repository over Secure Shell (SSH).
# Setting: Repository Clone Directory
Allows to configure the path to the directory where Teamscale stores clones remote repositories (e.g. Git or SAP).
Relative paths are supported and defaults to a folder repo in the JVM process working directory.
# Setting: Shadow Mode
Useful when setting up a "mirror" Teamscale instances with the same configuration as an existing instance, e.g., for preparing an update. During the time when the new instance is online but not yet ready to be used in production (e.g., while performing history analysis), Shadow Mode should be enabled for that instance. In this mode, Teamscale will not publish data to external systems (e.g., via notifications or merge-request annotations).
ABAP integration in Shadow Mode
The shadow mode will also prevent synchronizations of the ABAP Git bridge.
# Setting: File-System-Access Whitelist
Teamscale supports a generic connector type that can read any kind of directory structure from the local file system. However, security policy may mandate that project administrators, as opposed to Teamscale administrators, should not have access to the entire file system. The File-System-Access Whitelist option allows Teamscale administrators to set global file-system access restrictions which affect all Teamscale projects, so they cannot be overridden by project administrators.