Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage).
Currently, secondary sites can use either:
- The same storage bucket as the primary site.
- A replicated storage bucket.
- GitLab manage replication, follow Enabling GitLab replication.
- Third-party services manage replication, follow Third-party replication services.
Introduced in GitLab 12.4.
Secondary sites can replicate files stored on the primary site regardless of whether they are stored on the local file system or in object storage.
To enable GitLab replication:
- On the top bar, select Menu > Admin.
- On the left sidebar, select Geo > Nodes.
- Select Edit on the secondary site.
- In the Synchronization Settings section, find the Allow this secondary node to replicate content on Object Storage checkbox to enable it.
For LFS, follow the documentation to set up LFS object storage.
For CI job artifacts, there is similar documentation to configure jobs artifact object storage
For user uploads, there is similar documentation to configure upload object storage
If you want to migrate the primary site’s files to object storage, you can configure the secondary in a few ways:
- Use the exact same object storage.
- Use a separate object store but leverage your object storage solution’s built-in replication.
- Use a separate object store and enable the Allow this secondary node to replicate content on Object Storage setting.
GitLab does not currently support the case where both:
- The primary site uses local storage.
- A secondary site uses object storage.
When using Amazon S3, you can use CRR to have automatic replication between the bucket used by the primary site and the bucket used by secondary sites.
For manual synchronization, or scheduled by