Geo Frequently Asked Questions

What are the minimum requirements to run Geo?

The requirements are listed on the index page

How does Geo know which projects to sync?


At the start, this tracking database is empty, so Geo will start trying to update from every project that it can see in the GitLab database.

For each project to sync:

  1. Geo will issue a git fetch geo --mirror to get the latest information from the primary site. If there are no changes, the sync will be fast and end quickly. Otherwise, it will pull the latest commits.
  2. The secondary site will update the tracking database to store the fact that it has synced projects A, B, C, etc.
  3. Repeat until all projects are synced.


To ensure that problems with pipelines (for example, syncs failing too many times or jobs being lost) don’t permanently stop projects syncing, Geo also periodically checks the tracking database for projects that are marked as dirty. This check happens when the number of concurrent syncs falls below repos_max_capacity and there are no new projects waiting to be synced.

Geo also has a checksum feature which runs a SHA256 sum across all the Git references to the SHA values. If the refs don’t match between the primary site and the secondary site, then the secondary site will mark that project as dirty and try to resync it. So even if we have an outdated tracking database, the validation should activate and find discrepancies in the repository state and resync.

Can I use Geo in a disaster recovery situation?


Read the documentation for Disaster Recovery.

What data is replicated to a secondary site?


Can I git push to a secondary site?

Yes! Pushing directly to a secondary site (for both HTTP and SSH, including Git LFS) was introduced in GitLab Premium 11.3.



What if the SSH server runs at a different port?


Is this possible to set up a Docker Registry for a secondary site that mirrors the one on the primary site?

Yes. See Docker Registry for a secondary site.

Can I login to a secondary site?

Yes, but secondary sites receive all authentication data (like user accounts and logins) from the primary instance. This means you will be re-directed to the primary for authentication and routed back afterwards.