Git is a distributed version control system for software source code and other files. Using version management makes it possible to track changes made to files. It facilitates collaboration between multiple people on a project because concurrent changes cannot lead to accidental overwriting of files, hence preventing information loss. Changes made by multiple people can be merged using the Git software. Versioning of files is often used in software development, but it is also suitable for working on scientific texts such as graduation and doctoral theses that are often written using the LaTeX document preparation software.

With GitLab, LRZ offers a web-based service for managing Git repositories. In addition to the actual repositories where the files are stored, GitLab provides tools such as wikis and an issue tracker. With "Merge Requests", code reviews can be carried out collaboratively and transparently.

Below you will find an overview of the LRZ GitLab installation. Further information can be found in the GitLab-FAQ.

Table of Contents


02.12.2021LRZ GitLab was upgraded to version 14.5.
04.11.2021LRZ GitLab was upgraded to version 14.4. A new section Visibility of projects and groups was added on this page.
21.10.2021LRZ GitLab was upgraded to version 14.3.3. Activating the Two-Factor-Authentication works now again.
13.10.2021Activating the Two-Factor-Authentication does not work since the upgrade last week. Users who have already previously activated 2FA are not affected. The problem will be solved in the next update.
07.10.2021LRZ GitLab was upgraded to version 14.3.
09.09.2021LRZ GitLab was upgraded to version 14.2.

LRZ GitLab was upgraded to version 14.0. For new features and other changes please see the following articles on the GitLab site:

Due to the duration of the background migrations the most recent version 14.2 was not installed today. We plan to install it next week on Thursday 9. September.

12.08.2021LRZ GitLab was upgraded to the most recent patchlevel of version 13.12. We are planning to upgrade to the next major version GitLab 14 in the beginning of September.
08.07.2021LRZ GitLab was upgraded to the most recent patchlevel of version 13.12.
01.07.2021All LRZ GitLab users will need to explicitly agree to the Terms of Service. The dialog will show up once latest upon the next login. In case you have set up automatic processes which access the system through the API and do not work after this change, you may need to log in once manually through the web interface.
17.06.2021Links to detailed information added in the Terms of Service section. From 2021-07-01 onwards, we will require all LRZ GitLab users to explicitly agree to the GitLab Terms of Service in order to be able to continue using the GitLab service.
10.06.2021LRZ GitLab was upgraded to version 13.12.
06.05.2021LRZ GitLab was upgraded to version 13.11. The name of the initial branch that is created automatically when creating repositories is now “main” instead of “master”. We are thus following the new naming scheme of and supporting efforts to make language non-discriminatory. The change only affects newly created projects. Existing projects and external repositories that are moved to LRZ GitLab remain unchanged.

Terms of service

All members of TUM, LMU and other Munich universities are entitled to use the LRZ GitLab service. This requires an LRZ, TUM or LMU user ID.

If no automatic activation has been made, individual user IDs can be activated by the responsible master user via our ID Portal. If this is not possible, please contact the LRZ Servicedesk.

Please note that LRZ GitLab can only be used for instructional-use or non-commercial academic research. IT professional use and/or use for institutional administration is not permitted under the educational license. Detailed information on the GitLab site:

You don't need to register as person or entity in the Education Program on the GitLab website. That has already been done by LRZ on behalf of the participating universities.

Storage space

Since Git is designed for versioning of text files (source code and other files in text format), Git repositories should remain relatively small (< 1 GB).

For binary formats such as image archives, Microsoft Office files (.doc, .docx, .xls, .xlsx etc.), LibreOffice / OpenOffice files (.odt, .ods etc.) or very dynamic data, GitLab supports the extension Large File Storage (LFS). If you have binary files in your project, please install and activate LFS from the beginning. A later migration of the files under LFS is much more complicated.

The limits in the LRZ GitLab are currently:

  • Maximum file size for upload: 2 GB
  • Maximum size of the repository including LFS files: 10 GB

The size of the repository can be found at the top of the project page in GitLab (value "X MB Files") . The value "Storage" shows the total size of the project including artifacts which are allowed to exceed the limit. Please note that the values are cached and may therefore not immediately reflect the actual size shortly after changes in the repository are made.

The maximum size of the repository can be increased by the administrators for individual projects if necessary. Proper use of Git LFS is a prerequisite for this. Please contact the LRZ Servicedesk.

In order to ensure stable operation, we will introduce an automatic storage space limitation (quota) in January 2021. New projects can thereafter no longer exceed the set limit. For existing larger projects where LFS is properly configured, we will automatically set a higher limit before enforcing the quota. Owners of oversized projects without LFS will be contacted and asked to reduce the size of their repositories. Instructions for this can be found in the GitLab-FAQ.

Project limit

10 personal projects may be created at most. This limit can be raised in justified cases. Please contact the LRZ Servicedesk. As an alternative, please organize your projects in groups (see below).


For logically related projects, the use of GitLab groups is recommended. Within a GitLab group, the number of projects is not limited. A group also has the advantage that rights management usually becomes easier and clearer. In addition, the role of a user of a group is inherited to all projects in the group.

Project and group visibility 

There are three levels of visibility for projects and groups in LRZ GitLab:

VisibilityMeaning / Impact
  • Access to the project or group must be granted explicitly to each user. The rights depend on the role which the person has in the project or the group. 
  • In case of a group, the list of authorized persons (and their roles) is inherited to all sub-groups and projects inside the group. 
  • In LRZ GitLab, the visibility "Private" is the default setting.
  • As with "Private", access rights can be granted explicitly.
  • (warning) In addition, all users who are logged in to the LRZ GitLab have read access: They can see the projects and groups and download the content. Only users who have been invited with GitInvited are excluded from this (due to their status "external user").
  • As a project or group owner you can set the visibility "Internal" yourself.
  • As with "Private", access rights can be granted explicitly.
  • (warning) In addition, any person has read access (see "Internal"). They do not need to have a User ID and do not need to be logged in.
  • In LRZ GitLab only the LRZ-GitLab-Team can set the visibility "Public". If you want to publish your project, please read the description in the section Public projects.

Details about the levels of visibility as well as roles and rights can be found in the following GitLab articles: 

Wichtige Sicherheitshinweise

  • Over 100,000 people can log into the LRZ GitLab! This includes all persons who belong to the LMU, TUM and also some other Munich universities and scientific institutions.
  • With such a large number of authorized persons, it may happen that one or more user IDs are compromised and unauthorized persons (criminals, etc.) use these IDs. These unauthorized persons then also have read access to all projects and groups with the visibility "Internal".
  • LRZ GitLab can be accessed from anywhere in the world. There are no geographical or other restrictions.

Conclusion: For your own protection, consider the "Internal" visibility almost like "Public".

Public projects

It is possible to publish projects so that they can be cloned without logging in. The required setting for the project can only be made by the GitLab administrators. Please pass on the project name or path with a corresponding message to the LRZ Servicedesk and use the button "Selfservice" to make an authenticated request.

We recommend grouping all public projects into groups so that they are not dependent on personal GitLab identifiers. If a project is to be publicly visible, the group which the project belongs to must also be made public.

For public projects, the following information is publicly visible (generally accessible):

  • On every commit: The name and email address stored in the Git configuration
  • The GitLab username as defined in the User Settings in the Account section. For personal projects, the username is visible in the path of the project.

Until January 2020 the GitLab username was initialized at first login with the user's own user ID, which is assigned by their own institution (LMU, TUM, HM, HSWT). We ask all these members of public projects to change their GitLab username (Settings → Account → Change Username), so that the user ID will not become generally visible. Reasons in detail:

  • For privacy reasons, the LRZ must treat the user ID as confidential information.
  • The user ID can be used in a social engineering attack in order to build confidence in the victim: << Dear customer with the identifier Abcxyz >>
  • There are several variants of password attacks. In the "Online Attack" scenario the attacker attempts to gain access using the normal log procedure. However, the attacker must know or guess both the user ID and the associated password.

When the GitLab username is changed, GitLab automatically adjusts the web addresses and repository URLs of the user's personal projects accordingly. For projects that belong to a group, nothing changes because there is no username in those URLs. Further details on changing your own GitLab username can be found in the GitLab documentation.

GitLab Pages

The GitLab Pages feature makes it possible to create and publish static web pages directly from a repository. All LRZ GitLab Pages are served as subdomains under All LRZ GitLab Pages can be reached using a secure connection (HTTPS).

By default, a new GitLab Page is accessible only to project members who are logged in. However, the Page can also be made generally accessible (Settings → General → Pages access control → Everyone).

A CI runner is required for the Pages functionality.

The CI/CD integration can be activated at the project level (Settings → General → Permissions → Pipelines). However, you can only configure the communication with a CI runner. LRZ does not provide shared CI runners until further notice, which means you will have to set up and operate a CI runner yourself.

See the following GitLab documentation for more details:

The GitLab Pages documentation presents the Pages functionality in detail. There you will find for example a detailed description about how the address of your GitLab Page is formed. (The documentation uses as an example domain which corresponds to on the LRZ GitLab platform.) Please note that the contents of your Pages site must be placed in the directory public in your repository. 

The size of Pages sites is limited to 1 GB. This limit can be raised in justified cases. Please contact the LRZ Servicedesk.

  • No labels