Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Geo and Disaster Recovery

The Geo Team

Geo is a Premium feature, built to help speed up the development of distributed teams by providing one or more read-only mirrors of a primary GitLab instance. This mirror (a Geo secondary node) reduces the time to clone or fetch large repositories and projects, or can be part of a Disaster Recovery solution.

Team members

Person Role
Nick Nguyen Engineering Manager, Geo
Valery Sizov Senior Backend Engineer, Geo
Gabriel Mazetto Backend Engineer, Geo
Douglas Barbosa Alexandre Staff Backend Engineer, Geo
Toon Claes Senior Backend Engineer, Geo
Michael Kozono Staff Backend Engineer, Geo
Alex Ives Senior Backend Engineer, Geo
Zack Cuddy Frontend Engineer, Geo

Stable counterparts

Person Role
Jennie Louie Software Engineer in Test, Enablement:Geo Replication
Fabian Zimmer Senior Product Manager, Geo
Sunjung Park Product Designer, Geo/Distribution

Goals and Priorities

Our priorities are aligned with the product direction. You can read more about this on the Geo Product Vision page.

Alongside the items listed in our Product Vision, we need to constantly assess issues that our customers bring to our attention. These could take the form of bug reports or feature requests. Geo users are often our largest customers and some rely on Geo as a critical part of their workflow.

We also work constantly to keep housekeeping chores to a manageable level. Where possible, we address these issues as part of a related project. Where this is not possible, we use time around our projects to make this happen.

Geo's Relationship to Disaster Recovery

Disaster Recovery (DR) is a set of policies, tools and procedures put in place to be able to recover from a disaster.

Geo provides data redundancy. The customer will have a redundant copy of data in a separate location. If anything were to happen to their primary instance, a secondary instance still retains a copy of the data.

However, data redundancy is only one part of a complete DR strategy.

High Availability (HA) is also a step towards Disaster Recovery. At the moment Geo does not provide true HA because if the primary instance is not available, certain actions are not possible.

How to ask for support from Geo

We like to use issues when customers need help from the Geo Team. This helps us to prioritize work and make sure that we don't lose history in context when the Slack retention policy activates.

Type Who is the right person How should they be contacted What is the expected first response time
1. General question about Geo features or functionality. This includes how things work, when a feature was released, or when a feature is expected to be released. Most people in Geo can answer this, but can always be answered by the EM or PM. Ask a question in #g_geo on Slack. Within 24 hours. (Week days only)
2. Specific question about Geo relating to a specific customer installation question. Usually quite a technical question. Usually an Engineer Raise the issue in the Geo Customers Project and ping #g_geo with the issue. Within 24 hours. (Week days only)
3. Request to join a call that will happen more than 24 hours in the future. Most likely to request technical support from the Geo team Usually an Engineer. Sometimes the EM or PM Raise the issue in the Geo Customers Project and ping #g_geo with the issue. Comment added within 24 hours with name of Engineer who will join call. (Week days only)
4. Emergency! Fire! Help! Usually an Engineer Raise the issue in the Geo Customers Project and ping #g_geo with the issue. Be clear in the slack message that this is an emergency. Within 4 hours. (Week days only)


Other Resources

Planning and Process

Our planning and build process is recorded on the process page.


The demos are recorded and should be stored in Google Drive under "GitLab Videos –> Geo Demos". If you recorded the demo, please make sure the recording ends up in that folder.

Geo Terminology

Term Definition
Geo The product name given to the feature that provides the ability to create one or more read-only mirrors for the main/primary instance
Primary The main, primary instance where read-write operations are allowed
Secondary An instance that synchronizes with the Primary node where only read-only operations are permitted