An overview of the self-managed option under the GitLab for Education programme, with links to official documentation for setup and ongoing management.
The GitLab for Education programme supports both deployment options. The right choice depends on your institution's technical capacity, data policies, and compliance requirements.
Running a self-managed GitLab instance requires someone comfortable with Linux server administration. A typical split of responsibilities looks like this:
For most education deployments, the Linux package (Omnibus) on a single Linux server or cloud VM is the recommended starting point — best-supported, bundles all required services, and easiest to maintain.
GitLab does not run on Windows. A supported Linux operating system (Ubuntu, Debian, or RHEL/CentOS) is required.
The two most important configuration steps are connecting GitLab to your institution's email system and authentication directory. Both are done by editing /etc/gitlab/gitlab.rb and running sudo gitlab-ctl reconfigure.
With LDAP configured, student accounts are created automatically on first sign-in. The Admin Area provides a web interface for managing users, groups, and permissions across the instance.
Runners execute student CI/CD pipeline jobs. At least one runner is needed for pipelines to run. Install runners on a separate machine from your GitLab instance — CI/CD jobs can be resource-intensive and you don't want pipeline activity affecting GitLab's availability.
For most education deployments, a single shared instance runner using the Docker executor is the right starting point. The Docker executor runs each job in an isolated container, preventing one student's pipeline from interfering with another's.
All student work lives in your instance — regular backups are essential. GitLab's built-in backup tool creates a single archive covering repositories, the database, uploads, and CI/CD artefacts. Automate backups to run nightly and store them off-server.
/etc/gitlab/gitlab.rb (your configuration) or /etc/gitlab/gitlab-secrets.json (encryption keys). These must be backed up separately. Without the secrets file, encrypted data cannot be restored.GitLab releases a new version every month. For education deployments, upgrading once or twice per academic year during low-activity periods is a practical cadence.
Always take a full backup immediately before upgrading, and check the upgrade path — GitLab requires passing through certain versions when crossing major releases.
After initial setup, the main ongoing responsibilities are monitoring instance health, managing storage growth, and keeping the instance up to date. GitLab includes built-in Prometheus and Grafana monitoring with the Linux package.