# gitlabhq/gitlabhq: self-hosting GitLab CE from the mirror repository

> The gitlabhq/gitlabhq repository is the read-only CE mirror of GitLab, an open-core Rails application for hosting Git repositories, merge requests and CI. This article covers what it ships, how to install it with the Omnibus package or the Docker image, and where the mirror stops being the right place to work.

**gitlabhq/gitlabhq** — GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com

- Repository: https://github.com/gitlabhq/gitlabhq
- Website: https://about.gitlab.com/getting-help/
- Stars: 24,553 · Forks: 5,984
- Language: Ruby
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/gitlabhq-gitlabhq

## What gitlabhq/gitlabhq actually is, and who it is for

GitLab is a Ruby on Rails application that hosts Git repositories, and the gitlabhq/gitlabhq repository is a read-only mirror of the Community Edition. The README is explicit about the arrangement: the canonical source is on GitLab.com, and anyone cloning the mirror is told not to submit issues or merge requests there. That single sentence defines the audience. You are meant to consume this repository as a deployment artifact or a reading copy, not as a contribution target.

The feature set described is the familiar one: fine-grained access controls on repositories, merge requests for review, CI/CD pipelines, and a per-project issue tracker, issue board and wiki. The README claims more than 100,000 organizations use GitLab and calls it the most popular on-premises Git repository manager. Treat that as vendor copy rather than an audited figure.

The fit is an organization that has decided its source code cannot leave its own network, or that wants CI runners and an issue tracker in the same product rather than stitched from three vendors. The mismatch is a small team that just wants a remote for git push. They will pay for PostgreSQL, Redis, Gitaly and a pile of background workers to get a feature set they will not open.

## Rails, Gitaly and the pinned component versions

The stack is a Rails monolith in front of separate services. The README lists the base requirements as Ubuntu, Debian, CentOS, RHEL or OpenSUSE, Ruby (MRI) 3.3.10, Git 2.33+, Redis 6.0+ and PostgreSQL 16.5+. Those are floors, not suggestions, and the Ruby version is pinned tightly enough that a distribution Ruby will usually be wrong.

The repository root shows how the non-Ruby pieces are versioned. Files named GITALY_SERVER_VERSION, GITLAB_SHELL_VERSION, GITLAB_WORKHORSE_VERSION, GITLAB_PAGES_VERSION, GITLAB_KAS_VERSION, GITLAB_OPENBAO_VERSION, GITLAB_ELASTICSEARCH_INDEXER_VERSION and GITLAB_ZOEKT_VERSION each hold a component release. Gitaly handles Git access, GitLab Shell handles SSH, Workhorse sits in front of the Rails app for large uploads and git-over-HTTP, and KAS is the agent server. A self-compiled install means building and matching all of them. The Omnibus packages exist so you do not.

The frontend lives in the same tree, with a private package.json that wires Jest, Vitest, ESLint, Stylelint, webpack and Vite build paths. That matters only if you are modifying the UI. For an operator, the relevant fact is that the repository is a monorepo for a distributed system, and the version pins are the contract between the parts.

## Installing GitLab CE with the Omnibus package

The README names the Omnibus packages as the recommended install and describes the self-compiled route as slower and more error prone. The procedure it gives is: pick your operating system, download the Debian or RPM package from the package server, and install it with the system package manager. The repository does not reproduce the per-distribution commands, so the exact apt or dnf invocation depends on the package you download.

What the repository does give is the minimal Docker Compose file at the top level:

```yaml
app:
  image: gitlab/gitlab-ce:latest
```

That is the whole file. It declares one service using the gitlab/gitlab-ce image and nothing else: no ports, no volumes, no environment variables, no PostgreSQL or Redis. The README does not document this Compose file, so do not read it as a supported deployment recipe. It is a starting point, and a real deployment needs persistent volumes for configuration, logs and data, or a container restart will take the instance with it.

If you are working on GitLab itself rather than running it, the README points at the GitLab Development Kit and warns that installing the dependencies by hand is a lot of work. It gives one manual step for that path:

```bash
cp config/puma.example.development.rb config/puma.rb
```

That copies the example Puma configuration into place so the development server has a config file to read.

## The mirror is read-only, and that changes your workflow

The most consequential limitation is not technical. The README states that the canonical source is hosted on GitLab.com and that the gitlabhq/gitlabhq repository is a mirror. It then asks that you do not submit issues or merge requests to the mirror project. If your team's habit is to fork, patch and open a pull request against the repository you cloned, that habit breaks here. Your patch has no upstream to land in until you redo it against the canonical project.

A second constraint is the edition split. The README describes GitLab as open-core: most of the code is MIT, while files under /ee are proprietary but source available and open to contributions. The repository metadata reports the licence as NOASSERTION, which is consistent with a tree that carries more than one licence. Reading the code and running the code are therefore two different questions, and the answer depends on which directory you are in.

Finally, the README's own requirements page is where operating system support lives, and it is not reproduced in the repository text. Anyone planning an install on an unlisted distribution should check that page rather than assume the list of supported platforms is open-ended.

## GitLab CE against a bare Git server plus separate CI

The honest alternative for a small team is a plain Git server such as Gitea or a bare repository over SSH, paired with a standalone CI system. The difference in approach is integration versus surface area. GitLab bundles repository hosting, merge requests, issues, a wiki, a container registry and CI runners behind one Rails application and one set of credentials. A bare server plus separate CI gives you fewer moving parts and no PostgreSQL to tune, but you own the glue: webhooks, access control, and a second place to look when a pipeline fails.

GitLab's own answer to the enterprise tier is GitLab Enterprise Edition, which the README says adds features aimed at organizations with more than 100 users and comes with official support for subscribers. That is a licensing and support decision rather than an architectural one, and it is the choice most growing installations eventually face.

A third option worth naming is GitLab.com itself. The README lists hosted GitLab as a free service. If your reason for self-hosting is not a data residency or network isolation requirement, running the same software on someone else's infrastructure removes the whole upgrade treadmill described in the next section.

## Upgrade cost, release cadence and licence boundaries

The README points upgrading questions at the update page on about.gitlab.com rather than documenting a procedure in the repository. That is a signal about where the operational knowledge lives: outside this tree. The repository does carry a CHANGELOG.md and a release cycle document reference, but the upgrade path itself is external documentation.

The practical cost is the version pins. Because Gitaly, GitLab Shell, Workhorse, Pages, KAS and the rest are separate components with their own version files, an upgrade is a coordinated move across all of them, not a git pull. The Omnibus packages and the gitlab/gitlab-ce image exist precisely to make that coordination someone else's problem. Self-compiled installs inherit it.

On licensing, the README's own summary is the safest thing to quote: GitLab CE is available freely under the MIT Expat license, files in /ee are proprietary but source available, and the LICENSE file governs the repository. The metadata reports NOASSERTION, which means an automated licence classifier could not reduce the tree to one identifier. If you are redistributing a modified build, that distinction is the one to resolve with your own counsel before you ship.

## Conclusion

Adopt gitlabhq/gitlabhq if you need a self-hosted Git server with merge requests, issue trackers and CI in one Rails application, and you accept the Omnibus package or the gitlab/gitlab-ce image as the supported install path. Do not adopt it if you want to file issues or merge requests against the code you are reading: the README states this mirror is read-only and that development happens on GitLab.com. Before you commit, verify the PostgreSQL 16.5+, Redis 6.0+ and Git 2.33+ floors against your hosts, and decide which edition you are deploying, because the /ee directory carries different licensing from the MIT-licensed CE code.

## FAQ

### What do people use GitLab for?

The README describes it as software for collaborating on code: managing Git repositories with access controls, reviewing code through merge requests, and running CI/CD pipelines. It also gives each project an issue tracker, issue board and wiki.

### Is GitLab.com safe?

The README does not make any security claims about the hosted service. It only lists GitLab.com as a place to use GitLab as a free service and links to the getting help page for support options.

### Is GitLab a legitimate company?

The repository does not address this. What it does state is that GitLab is an open source project, that the canonical source is hosted on GitLab.com, and that the company is hiring developers, support engineers and production engineers, with a jobs page linked from the README.

### Is GitLab an Ukrainian company?

The README says nothing about where the company is based. It describes three editions, CE, EE and JiHu Edition, the last of which it says is tailored specifically for the Chinese market.

## Sources

- [gitlabhq/gitlabhq on GitHub](https://github.com/gitlabhq/gitlabhq)
- [Issues](https://github.com/gitlabhq/gitlabhq/issues)
- [Project website](https://about.gitlab.com/getting-help/)
- [README](https://github.com/gitlabhq/gitlabhq/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gitlabhq-gitlabhq