GitLab — Self-Hosted Git for Institutional Data

What GitLab is

GitLab is a Git hosting and DevOps platform. Functionally it covers the same ground as GitHub — repositories, branches, code review (called merge requests rather than pull requests), issues — with a mature continuous-integration system built in rather than bolted on.

The reason it appears separately in this directory is not features but hosting. GitLab can be self-hosted, and a great many universities run their own instance. That means your repository lives on institutional infrastructure, inside the institution’s legal and technical boundary, subject to its data-protection arrangements rather than a commercial provider’s. For research that touches personal data, that is often not a preference but a requirement, and it is the whole reason to know this tool exists.

Why researchers use it

Your institution probably already runs one — and code that can live there can hold data that github.com cannot.
Data sovereignty by construction — repositories on university servers, under university agreements, in the right jurisdiction. This is the argument that ends the discussion with a data protection officer.
CI without a third party — a .gitlab-ci.yml file runs your tests, rebuilds your figures, or recompiles your paper on every push, on infrastructure you already trust.
Unlimited private repositories and groups — lab-scale organisation without a per-seat conversation.
The workflow transfers — if you know Git and GitHub, you know GitLab; the vocabulary changes and almost nothing else does.

Where it fits in a research workflow

GitLab occupies exactly the same slot as GitHub — the versioned home for code, manuscripts, environment definitions, and container recipes — but on the other side of a governance boundary. The practical consequence is that many labs run both: the sensitive project on the institutional GitLab, the open-source tool on github.com where the community will find it.

Its distinctive contribution is CI. Because pipelines run on institutional runners, you can build genuinely useful automation without sending anything outside: recompile the LaTeX manuscript and attach the PDF on every commit, re-run the analysis and regenerate figures when the data version changes, rebuild the Docker image when the environment file changes. That is reproducibility as a continuous property rather than an end-of-project scramble, and it is available in about ten lines of YAML.

Getting started

An hour, and the first step decides everything.

Find out whether your institution runs an instance before doing anything else — usually gitlab.<institution>.edu or similar, often listed by research computing. Which instance you use is a governance decision, not a preference.
Mirror your existing Git habits; only the vocabulary differs. Merge requests are pull requests, and everything else you know applies.
Add a minimal .gitlab-ci.yml that runs one thing — your test script, or a LaTeX compile. Seeing a pipeline succeed on push is what makes CI click.
The step people skip: confirm what the institutional instance actually promises. Backup schedule, retention after you leave, and whether it survives a departmental reorganisation are all questions with real answers, and researchers discover them at the worst possible moment.

GitLab vs the alternatives

Alternative	Does it better	Pick it if
GitHub	Community visibility, ecosystem, and citation of open code	You want the work found, forked, and used
OSF	Research-native project structure and preregistration	The project is a study, not a codebase
REDCap	Compliant capture of the participant data itself	You are collecting data, not versioning code
Zenodo	Permanent archival and DOIs	You need the citable version of record

Use GitLab where governance is the constraint and GitHub where visibility is. Publishing an open-source tool on an institutional GitLab that outsiders cannot easily discover is a common and avoidable mistake.

Cost, licensing, and your data

GitLab has an open-source Community Edition and a commercial Enterprise Edition; gitlab.com offers a free tier with limited CI minutes plus paid plans. Self-hosted institutional instances are typically free to you and paid for centrally, so the cost question rarely reaches the individual researcher.

The data question is the whole point and is worth stating precisely: on a self-hosted instance, your repositories sit on infrastructure your institution controls, under its data-protection arrangements and in its jurisdiction. That is what makes it acceptable for projects a commercial US-hosted service is not. Two caveats. It is still Git, so committed data is still effectively permanent — governance-compliant hosting does not make it safe to commit a participant spreadsheet. And institutional instances vary enormously in maintenance quality; a poorly maintained instance is a single point of failure with your thesis inside it, so keep a mirror.

The honest review

Strengths. GitLab is the pragmatic answer when a data protection officer is in the room. It gives you the full modern Git workflow, plus genuinely good built-in CI, on infrastructure that satisfies rules github.com cannot. For labs handling personal data, that combination is not a nice-to-have — it is the difference between having version control and not.

Limitations. Visibility is the real cost. Code on an institutional GitLab is often invisible outside the institution: not indexed, not forkable by a stranger, not where anyone looks. For a tool you want adopted and cited, that is a serious handicap and the single best reason to publish on GitHub instead. gitlab.com’s free CI minutes run out quickly for anything compute-heavy. Self-hosted instances vary in upkeep, and an under-resourced one means slow runners, deferred upgrades, and occasionally a migration you did not plan. And the interface, while capable, is heavier and less pleasant than GitHub’s.

Verdict. Adopt it when governance rules decide the question — which for anything involving personal data they usually do. Skip it for open-source work you want the community to find, where GitHub’s network effects are the actual product. The condition that flips the answer is the audience: internal collaborators, GitLab; the world, GitHub.

When NOT to use this Do not assume an institutional instance is backed up, or that your repositories survive your departure. Ask research computing three specific questions before your thesis depends on the answer: what the backup schedule is, what happens to your account when your contract ends, and who to contact when the instance is down at 2am before a deadline. Keep a mirror somewhere you control. And self-hosting does not make committed participant data safe — Git history is permanent wherever it is hosted.

Common questions

Is GitLab free?

There is an open-source Community Edition, a free tier on gitlab.com with limited CI minutes, and paid commercial plans. Most academic users are on an institutional self-hosted instance paid for centrally, at no cost to the individual.

GitLab or GitHub for research?

GitLab when data governance rules out commercial hosting — that is the deciding factor. GitHub when you want the code found, forked, and cited, because its community reach is far greater. Many labs use both for different projects.

Does GitLab have CI built in?

Yes, and it is one of its strongest features. A .gitlab-ci.yml file in your repository defines pipelines that run on every push — recompiling a manuscript, running tests, or rebuilding a container — on runners your institution controls, with nothing leaving the boundary.