Overleaf docs
Plans and pricingTemplatesUser docsGo to Overleaf
On-premises
On-premises
  • Welcome
    • Server Pro vs. Community Edition
  • Release notes
    • Release notes 5.x.x
      • Doc version recovery
    • Release notes 4.x.x
    • Release notes 3.x.x
      • Full project history migration
    • Release notes 2.x.x
    • Release notes 1.x.x
    • Release notes 0.x.x
  • Getting started
    • Before you start
    • Requirements
      • Skills needed
      • Hardware requirements
      • Software requirements
    • Microservices
    • Server Pro infrastructure
    • What is the Overleaf Toolkit?
  • Installation
    • Introduction
    • Using the Toolkit
      • 1: Download the Toolkit
      • 2: Familiarize yourself with the Toolkit
      • 3: Initialize the configuration
      • 4. Choose Community Edition or Server Pro
      • 5. Personalizing your instance
      • 6. Post-installation tasks
    • Air-gapped/offline deployments
    • Upgrading TeX Live
  • Configuration
    • Overleaf Toolkit
      • Files and locations
      • Toolkit settings
      • Environment variables
      • Server Pro-only configuration
        • LDAP
        • SAML 2.0
        • Sandboxed Compiles
        • Git integration
        • Templates
        • Adding LaTeX user help
      • Logging
      • TLS proxy
      • Branding
      • Localization
      • Email delivery
      • Redis
      • S3
  • Maintenance
    • docker-compose.yml to Toolkit migration
    • Upgrading your deployment
    • Data and backups
      • Exporting projects
    • Extending TeX Live
    • Horizontal scaling
    • S3 migration
    • Updating MongoDB
  • User and project management
    • User management
      • Username migration
    • Understanding license usage
    • Project management
  • Support
    • Project limits
    • Troubleshooting
    • Getting help
    • Support guides
      • Using templates as an individual
    • Overleaf user docs
Powered by GitBook
LogoLogo

Discover Overleaf

  • Home
  • Features

Solutions

  • Plans and pricing
  • For universities
  • For business
  • For government

Resources

  • Templates
  • User docs and LaTeX learning
  • Blog

© Overleaf

On this page

Was this helpful?

Export as PDF
  1. Configuration
  2. Overleaf Toolkit
  3. Server Pro-only configuration

Git integration

PreviousSandboxed CompilesNextTemplates

Last updated 5 months ago

Was this helpful?

The Git integration is available since Server Pro 4.0.1.

User documentation for this feature can be found .

If you’re using the Toolkit, the git-bridge can be enabled by setting GIT_BRIDGE_ENABLED=true in your config/overleaf.rc file.

For users running a custom docker-compose.yml, add the following container configuration to your compose file:

git-bridge:
    restart: always
    image: quay.io/sharelatex/git-bridge:4.0.0 # tag should match the `sharelatex` container tag
    volumes:
        - ~/git_bridge_data:/data/git-bridge
    container_name: git-bridge
    expose:
        - "8000"
    environment:
        GIT_BRIDGE_API_BASE_URL: "http://sharelatex:3000/api/v0/" # "http://sharelatex/api/v0/" for version 4.1.6 and earlier
        GIT_BRIDGE_OAUTH2_SERVER: "http://sharelatex"
        GIT_BRIDGE_POSTBACK_BASE_URL: "http://git-bridge:8000"
        GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
    user: root
    command: ["/server-pro-start.sh"]

You’ll also need to add a link to the git-bridge container in the sharelatex container, and define new environment variables:

sharelatex:
    links:
        - git-bridge
    environment:         
         GIT_BRIDGE_ENABLED: true
         GIT_BRIDGE_HOST: "git-bridge"
         GIT_BRIDGE_PORT: "8000"
         V1_HISTORY_URL: "http://sharelatex:3100/api"

We recommend you monitor your host resources after enabling the git-bridge. The load increase will depend on the number of users accessing the feature and the type of projects hosted in your instance (larger projects will generally be more resource intensive).

Swapping projects to S3

The Git integration stores a complete git repository on disk for each project that gets cloned by a user. If you have limited disk space, you can activate a swap job that will move repositories that are less used to AWS S3. If a swapped repository is needed again, it gets moved back to the disk. The following environment variables control the swap job:

Name
Description

GIT_BRIDGE_SWAPSTORE_TYPE

Set this to "s3" to activate the swap job.

GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY

Your AWS access key

GIT_BRIDGE_SWAPSTORE_AWS_SECRET

Your AWS secret

GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME

This bucket will contain the zipped git repositories

GIT_BRIDGE_SWAPSTORE_AWS_REGION

The bucket’s region

GIT_BRIDGE_SWAPJOB_MIN_PROJECTS

How many projects to keep on disk, at a minimum. - Default: 50

GIT_BRIDGE_SWAPJOB_LOW_GIB

Low watermark for swapping. The swap job will move projects until disk usage is below this value. - Default: 128 GB

GIT_BRIDGE_SWAPJOB_HIGH_GIB

High watermark for swapping. The swap job will start swapping when disk usage reaches this value. - Default: 256 GB

GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS

The amount of time between checking disk usage and running the swap job. - Default: 3600000 ms = 1 hour

When authenticating a git client, users need a Personal Access Token. Users can manage the Personal Access Tokens through the application UI (see the ).

here
documentation