Overleaf is a collaborative LaTeX editor loved by researchers and tech teams. Our cloud version is available at overleaf.com. These docs are specifically for people interested in setting up and maintaining Overleaf Server Pro or Community Edition.

Overview of Server Pro and Community Edition

Both Server Pro and Community Edition run in Docker containers, isolating them from other applications on the same host. This provides an additional layer of security by preventing potential cross-application attacks.

They can run on air-gapped servers, which means they can be completely isolated from other networks, including the Internet. Docker provides tooling for transferring the application from an internet-connected to an air-gapped environment.

After the initial download, no internet connection is required, significantly reducing the risk of external threats.

Stay up to date

to get updates on:

• New releases and features

• Enhancements

• Security patches

Quick links

In this section we will guide you through downloading the Toolkit from GitHub, familiarizing yourself with some of the Toolkit's commands and configuring some basic settings. By the end of this page you should have a running on-premises instance over Overleaf.

Server Pro version support

To remain on a supported track, you should be running one of the supported release numbers listed below in the rightmost column (Latest Patch).

Benefits for users

We recommend that the on-site administrator of your Overleaf instance has:

• General IT administration skills

• Familiarity with Linux command line tools

• General networking knowledge and troubleshooting skills

• Experience backing up and restoring production systems

Make sure you read this section thoroughly before proceeding with any installation of Overleaf.

Requirements for installing Server Pro and Community Edition

Whether you're a researcher interested in running the Community Editition in your trusted workgroup or an enterprise organisation wanting to integrate Server Pro into your existing infrastructure, to get started, we always highly recommend setting up your new instance using our with the default Community Edition image as doing so is a great way to familiarize yourselves with the platform's requirements and helps ensure a smooth experience when deciding to upgrade to Server Pro.

Like the Community Edition, Server Pro comes as a Docker container and is a direct drop in replacement and additionally includes features such as SSO provided via LDAP and SAML2, improved security, tracked changes, comments, our optimized version of TeX Live, templates and administration panel.

Once you've depolyed the Community Edition using the Toolkit and familiarized yourself with the application, you can easily switch to Server Pro by following the instructions .

Before you install Overleaf, it's important to familiarize yourself with the requirements, installation process, configuration options, and upgrade sections of this documentation. It's also crucial to have a solid understanding of your organization's requirements for using Overleaf and the necessary underlying infrastructure needed for its successful operation.

What can I do to prepare?

Understand the requirements for running Overleaf. This involves evaluating your organization's existing server environment, network capabilities and storage resources. Ensure that your infrastructure meets or exceeds the specified requirements outlined in this documentation.

Before initiating the installation process, ensure you have administrative access to the server where you intend to deploy Overleaf. This may involve coordinating with your IT team or system administrators to obtain the necessary permissions and resources. Additionally, review any security considerations or network policies that might impact the installation.

What if I have a problem?

If you encounter any problems, we recommend first consulting the section of the documentation as it contains common issues and required information needed by the support team if you need to reach out for assistance.

By following these steps and thoroughly reading the documentation, you'll be well-prepared to install, configure, and maintain Overleaf according to your organization's requirements. Remember that a solid understanding of your infrastructure and the installation process is key to a successful deployment.

i18n Languages

Both the Overleaf Community Edition and Server Pro have been translated into multiple languages.

The language can be set via OVERLEAF_SITE_LANGUAGE with one of the following options:

• en - English (default)

• es - Spanish

• pt - Portuguese

• de - German

• fr - French

• cs - Czech

• nl - Dutch

• sv - Swedish

• it - Italian

• tr - Turkish

• zh-CN - Chinese (simplified)

• no - Norwegian

• da - Danish

• ru - Russian

• ko - Korean

• ja - Japanese

• pl - Polish

• fi - Finnish

Some of these are more complete than others, we always endeavor to have all supported languages fully translated, if you would like to help with our translations please get in touch!

Multi-language support

Overleaf can support multiple languages per container. This is done via different domains configured to respond in a set language using the environment variable OVERLEAF_LANG_DOMAIN_MAPPING with an escaped JSON string.

Server Pro 1.2.1

(Community Edition Image ID: 8e1bae81acac)

Server Pro 1.2.0

• Use both 2016 and 2017 versions of texlive, for backward compatibility

Server Pro 1.1.0

• Update texlive to 2017.1

• Use https for the learn-wiki proxy by default

Server Pro 1.0.2

• A new option, keep the pdf view in sync while you type

• A new feature, replacing the public/private permissions system

• New administration interface

• Package-aware Autocomplete

Server Pro 1.0.0

• Upgraded all internal services to latest node-js runtime

• Per-User Track Changes

• Improved Autocomplete

• Improved Spellcheck

Initializing the configuration

Let's initialize our new server's configuration files with some sensible defaults by running the bundle bin/init script.

bin/init

This script will not overwrite any existing configuration files.

Now let's check the contents of the config/ directory using the ls command:

ls config

If everything was successfully initialized you should see three configuration files overleaf.rc, variables.env and version. These are the main server configuration files and allow you to customize how your server operates and how your users interact with your instance.

You can enable access to Overleaf's Learn pages within your Server Pro instance by simply adding OVERLEAF_PROXY_LEARN=true to your config/variables.env file in the Toolkit and running the bin/up command.

This allows users to access current documentation and learning resources by clicking the Documentation button in the navigation menu, all without leaving your instance.

It is possible to enforce password restrictions on user accounts when using the native Overleaf login system for authentication.

To do so, you'll need to set the relevant environment variable in the Toolkits config/variables.env file.

If you're a Server Pro customer please continue with the next steps to log into our image repository and change the Toolkit configuration to use the Server Pro image. If not, you can skip this section and move on to the personalizing your instance step.

Obtaining Server Pro Image

Server Pro is distributed as a Docker image on the quay.io registry: quay.io/sharelatex/sharelatex-pro

You will have been supplied with a set of credentials when you signed up for a Server Pro license.

First use your provided credentials to log in to the quay.io repository:

docker login quay.io
Username: <sharelatex+your_provided_username>
Password: <your_provided_password>

Then run bin/docker-compose pull to pull the Server Pro image from the registry.

Switching to Server Pro

If you're deploying an on-premises version of Overleaf for the first time we highly recommend first setting up the Overleaf Toolkit with the Community Edition before switching to Server Pro as this will help you get familiarized with the process.

As Server Pro can be used as a drop-in replacement for the Community Edition you'll be able to use all your existing settings and customizations. When you're ready, Toolkit deployments can enable Server Pro by editing the config/overleaf.rc file and changing the SERVER_PRO environment variable to true.

The next time you run bin/up, the Toolkit will automatically download and use the Server Pro image.

If you're upgrading from the Community Edition to Server Pro you can do that now. If not, please move onto the next step in the deployment guide to personalize your instance.

Server Pro licensing is quite different from other cloud-based solutions in that there is no concept of free collaboration, any user who logs in and accesses a project is considered an active user by the system, necessitating a corresponding license.

The active/inactive flag for an account is just a high-level indicator for administrators to help indicate usage. If a user who holds a Server Pro license leaves your organization, there is no immediate requirement to delete their account and their associated projects. This action is often required for regulatory and compliance purposes, but from a licensing point of view, the license allocated to the departing user can be reassigned to their successor, allowing for a seamless transition.

In general, it's advisable not to delete accounts (unless they are no longer required), as this action would lead to the removal of the account's projects and prevent any collaborators from accessing them.

Presently, there is no provision for deactivating accounts; they either exist with retained data or don't exist at all. The recommended approach is to leave the account and its associated data within Server Pro, ensuring any projects are part of your backup process.

Over time, unused accounts will transition to an inactive state (as they will not have accessed a project within the past 12 months), denoting that they no longer require a license, even though the accounts and associated projects are retained. In the event a user returns, they can access their account and projects, reinstating their status as an active user and once again requiring a licence.

It's important to highlight that in Server Pro, Administrators retain the capability to access the projects of any user, even after that user has left the organization. This maintains a certain degree of access and authority over projects. Additionally, Administrators hold the ability to transfer ownership of projects from one user to another, offering full control over your data.

As Server Pro is architected to work offline, we have purposely chosen not to enforce a strict user limit, and there are no restrictions that would prevent new users from being onboarded in cases where deployments are over their seat limit. This helps ensure that users can access their projects when needed and are not hindered by a temporary lack of seats.

In cases where you go over your seat limit, we would request that you reach out to the Success team () to let us know at your earliest convenience. The Success team can then provide you with prorated pricing for adding more seats, either midterm or aligned with your subsequent renewal.

When it comes to renewals, as Server Pro doesn't transmit usage information back to us, we rely on customers to report their user count for license compliance. As mentioned above, as Server Pro doesn't enforce a strict user limit, and there's no explicit 'inactive' setting for users -- this means that if you're aware of inactive users, you have the option to exclude them when reporting your seat count to us.

If you are using SSO, an alternative way would be to report the number of users within your authorized group rather than the total number of active users in the Server Pro instance, as the latter might encompass older, inactive accounts.

Downloading the Toolkit

The Toolkit is compatible with both the Server CE and Server Pro and is the recommend installation method. Using the Toolkit will allow you to easily get started with Server CE and seamlessly upgrade to Server Pro if required.

To install the Toolkit you'll need to navigate to the intended installation path and then clone the Overleaf Toolkit GitHub repository using this command:

git clone https://github.com/overleaf/toolkit.git ./overleaf-toolkit

Wait for the cloning process to complete then let's switch into the newly created overleaf-toolkit directory:

If an individual user would like to use a template from the Template Gallery on overleaf.com they would need to:

1. Navigate to the Template Gallery on overleaf.com and locate the required template, for example IEEE Photonics Journal Paper Template - Example Submission

2. Click on the Open as Template button

3. Click on the project menu and choose Download Source

4. Next, log into their on-premise Server Pro account

5. Click the New Project button from the projects dashboard and choose Upload Project

6. Click the Select a .zip file button and choose the downloaded template zip file

The user can then use this newly uploaded template as required.

The following pages provide detailed descriptions of the various configuration files and settings that are required to configure and customize your deployment when using the Overleaf Toolkit.

Each of these files plays a specific role in the configuration process, and understanding their functions will help you to tailor your on-premises version of Overleaf to your specific needs.

Enabling password authentication

If you're you're using an external Redis service and need to provide a password you can do this by setting the OVERLEAF_REDIS_PASS and REDIS_PASSWORD environment variables in the config/variables.env file and running the bin/up -d command to recreate the sharelatex container.

If you're running a local instance of Redis, you'll need to configure the redis service to start with password authentication. After setting the above environment variables, you'll also need to complete these additional steps:

If an error occurs in any of the processes it will be written to the respective log file such as /var/log/overleaf/web.log.

Toolkit users can have a look at the logs inside the container using the bin/logs script:

You can use the bin/logs script to view logs for the following services: clsi, contacts, docstore, document-updater, filestore, git-bridge, mongo

To save bandwidth, both the Overleaf Community Edition and Server Pro images only come with a minimal install of . You can install more packages or upgrade to a complete TeX Live installation using the command in the sharelatex container.

Taking a look around

Now that we have a local copy of the Toolkit, let's take a look at the structure of the repository using the ls command:

Operating systems

For the best experience when running Overleaf, we highly recommend using a Debian-based operating system, such as Ubuntu. This choice aligns with the software's development environment and is the preferred option among the majority of Overleaf users.

Personalizing your instance

Before we start your Overleaf instance for the first time we're going to update the config/variables.env configuration file with your custom information.

Open the config/variables.env file using your favourite text editor and update each of the following environment variables with the required information.

The is a git repository, so it's easy to get new Toolkit features. Just run the bin/upgrade command and follow the on-screen prompts.

It is worth noting that the Docker image version (at config/version), is managed separately from the Toolkit code updates. Updating the Toolkit code will not automatically change the version of the Docker image that you are running. This means that in most cases, you are able to upgrade your Toolkit version without upgrading your deployment.

The bin/upgrade Script

Creating your first administrator account

In a browser, open . You should see a form with email and password fields. Fill these in with the credentials you want to use as the administrator account, then click Register.

Then click the link to go to the login page (). Enter the credentials. Once you're logged in, you'll see the welcome page.

Click the green button at the bottom of the page to start using Overleaf.

To aid with the handover for all of a users projects to another user, Server Pro includes a script for bulk transfer of project ownership.

The projects will be added to a new tag in the new project owners account. The tag is named after the current users email address and has prefix "transferred-from", example: "[email protected]".

Added in Server Pro version 5.5.3.

Usage

It's possible to extend an existing TeX Live image using a new Dockerfile and configure the application to use the new image.

Here we offer some guidelines to install new packages or fonts, but the configuration of a custom image is not covered by our support terms.

The TeX Live images receive infrequent updates. We suggest rebuilding custom images when upgrading Server Pro.

Server Pro 6.0.1

Release date: 2025-11-17

• Server Pro Image ID: a339d58ea444

• Community Edition Image ID: 719649cd32f8

• Git Bridge Image ID: 38f569f6f277

This release fixes several compile issues emerging after the latest runc updates.

Server Pro 6.0.0

Release date: 2025-10-30

• Server Pro Image ID: 579c87536b16

• Community Edition Image ID: 21b21080312f

• Git Bridge Image ID: 38f569f6f277

Binary file migration

This new release reduces the storage usage of binary files in half.

An online migration is included in version 5.5, allowing for minimal downtime as part of the upgrade. Before upgrading to Server Pro v6 make sure you're already running the latest version of Server Pro v5.5 () and have run the migration.

.

MongoDB upgrade to v8

This release bumps the minimum MongoDB version to 8.0

If you're currently using MongoDB v6 or earlier, you'd need to update your versions one major version at a time (v6 → v7 → v8).

For instructions on how to upgrade MongoDB v6 → v7 → v8 see our step-by-step guide .

Redis upgrade to v7.4

This release also bumps the minimum Redis version to 7.4.

Update your REDIS_IMAGE in your config/overleaf.rc to REDIS_IMAGE=7.4.

New Features

• Link sharing now can be disabled with OVERLEAF_DISABLE_LINK_SHARING=true.

• OVERLEAF_MAINTENANCE_MESSAGE and OVERLEAF_MAINTENANCE_MESSAGE_HTML are now available to customise the title and content of the Maintenance page.

• OVERLEAF_USER_HARD_DELETION_DELAY and OVERLEAF_PROJECT_HARD_DELETION_DELAY

Bugfixes

• Fixed footer rendering with links.

• Improved error messages on SAML login errors.

• Fixed audit log entry not added when a user's admin state is updated on SSO login.

• Fixed History panel errors when TLS is enabled in Redis.

Other changes

• All the links to the status page (set via OVERLEAF_STATUS_PAGE_URL) now use HTTPS and open in a new browser tab.

In Server Pro and Community Edition 5.4.0 we have included a script that allows Administators to export all user projects (including those still visible in the Deleted and Trashed folders) to a directory on disk.

Limitations

The export script has the following limitations:

• No project settings, such as the TeX Live image name or compiler, are exported. These must be set when the project is uploaded to the user's account.

• Exported projects don't contain any version history.

• No collaborator information is preserved. Projects will need to be reshared. If using link-sharing, View and Edit links will be regenerated (they won't be the same as before).

• Any comments and tracked change information won't be exported.

Flags

Usage

Use the following command to export projects for all users:

Completion

Once the export is completed, you can access the files via the directory on the host that is bind-mounted to /var/lib/overleaf in your docker-compose.yml file or the OVERLEAF_DATA_PATH environment variable in the config/overleaf.rc file if you are using the Toolkit.

Header

In this section, we'll cover how to personalize key elements of your on-premises instance. You can customize the site title, navigation links, header, footer, and logo according to your preferences.

Site title

The navigation bar title can be customized with the OVERLEAF_NAV_TITLE environment variable, this text is used in the top left corner of navigation if no logo is set.

Logo

You can add a custom logo rather than using text by setting the environment variable OVERLEAF_HEADER_IMAGE_URL. This value should point to an externally hosted image file.

Header navigation links

Extra navigation items can be added to the navigation header by setting the OVERLEAF_HEADER_EXTRAS environment variable to a JSON array of objects. For example:

Footers

It is possible to customize both the left and smaller right footer which is found on pages like /project using the environmental variables OVERLEAF_LEFT_FOOTER and the smaller OVERLEAF_RIGHT_FOOTER

Both expect an array of JSON which will be inserted.

This data needs to be valid JSON to work, with quotes escaped when passed through as an environmental variable.

An optional TLS proxy for terminating HTTPS connections, using NGINX.

Run bin/init --tls to initialise local configuration with NGINX proxy configuration, or to add NGINX proxy configuration to an existing local configuration. A sample private key is created in config/nginx/certs/overleaf_key.pem and a dummy certificate in config/nginx/certs/overleaf_certificate.pem. Either replace these with your actual private key and certificate, or set the values of the TLS_PRIVATE_KEY_PATH and TLS_CERTIFICATE_PATH variables to the paths of your actual private key and certificate respectively.

A default config for NGINX is provided in config/nginx/nginx.conf which may be customised to your requirements. The path to the config file can be changed with the NGINX_CONFIG_PATH variable.

Add the following section to your config/overleaf.rc file if it is not there already:

In order to run the proxy, change the value of the NGINX_ENABLED variable in config/overleaf.rc from false to true and re-run bin/up.

By default, the HTTPS web interface will be available on https://127.0.1.1:443. Connections to http://127.0.1.1:80 will be redirected to https://127.0.1.1:443. To change the IP address that NGINX listens on, set the NGINX_HTTP_LISTEN_IP and NGINX_TLS_LISTEN_IP variables. The ports can be changed via the NGINX_HTTP_PORT and TLS_PORT variables.

If NGINX fails to start with the error message Error starting userland proxy: listen tcp4 ... bind: address already in use ensure that OVERLEAF_LISTEN_IP:OVERLEAF_PORT does not overlap with NGINX_HTTP_LISTEN_IP:NGINX_HTTP_PORT.

Switching from a self-hosted Server Pro instance to a new cloud-based Overleaf Group Professional subscription is a big change, so to make this process as smooth as possible we've put together the following guidance.

In general, we propose a three-month overlap period starting on your renewal date. This means that:

• Your existing Server Pro instance and your new Group Professional subscription will both be fully active.

• Your technical team can schedule time to get the Group Professional subscription set up and decide on the future of your on-premises deployment of Server Pro.

• Most importantly, your users will have ample time to copy their projects over to the new Overleaf Group Professional platform.

This quick guide will walk you through the key steps for this migration. Let’s get you started!

Phase 1: Setup and Configuration

• Overleaf will create your Group Professional subscription and add your Lead Administrator.

• Your group administrator will now be able to enable , configure , and .

Phase 2: User Migration & Data Management

This is the primary migration window and has the following responsibilities:

End-Users

• Users should actively migrate any projects they wish to keep from your Server Pro instance to their new accounts on . The process involves from Server Pro and to their account on . If a user doesn't already have an account, they can make one at .

Technical Staff

• During this phase, your technical team should plan for the post-migration handling of your on-premises Server Pro instance and its data.

• Data Backup: You can export all projects before decommissioning. This creates an archive that allows you to assist users who may have forgotten to migrate or download their work. Instructions can be found .

• Server Pro Decommissioning: After the migration window closes and your license key is disabled, you have two main options for the Server Pro instance itself:

Phase 3: Server Pro Decommission

• The Overleaf team will formally deactivate your Server Pro license key. We will send a confirmation once this is complete. This is when you will need to either uninstall Server Pro completely or switch to Community Edition as described above.

This page describes the configuration files that are used by the Toolkit to configure your on-premises deployment of Overleaf.

Persistent Data

The Overleaf Toolkit needs to store persistent data, such as the files required to compile LaTeX projects, and the contents of the MongoDB database. This is achieved by mounting a few directories from the host machine into the Docker containers, and writing the data to those directories.

Data Directories

The sharelatex container requires a directory in which to store data relating to LaTeX compiles. This directory is set with the OVERLEAF_DATA_PATH variable in config/overleaf.rc.

The mongo container, if it is enabled, requires a directory in which to store it's database files, and the same is true of the redis container. These directories can also be configured in config/overleaf.rc.

File Permissions

Because Docker runs as root, the data directories will end up being owned by the root user, even if the Toolkit is being used by a non-root user. This is not a problem, but is worth being aware of, if you intend to alter the persistent data from outside of the containers.

Configuration file location

All user-owned configuration files are found in the config/ directory.

This directory is excluded from the git revision control system, so it will not be changed by updating the Toolkit code. The Toolkit will not change any data in the config/ directory without your permission.

The overleaf.rc file

The config/overleaf.rc file contains the most important top level configuration settings used by the Toolkit. It contains statements that set variables, in the format VARIABLE_NAME=value.

To see a breakdown of all available configuration options see our settings section.

The variables.env file

The config/variables.env file contains environment variables that are loaded into the sharelatex container, and used to configure the Overleaf microservices. These include the name of the application, as displayed in the header of the web interface, settings for sending emails, and other premium settings such as SSO for use with Server Pro.

To see a breakdown of all available environment variables see the section.

The version file

The config/version file contains the version number of the Docker image that will be used to create the running instance of your Overleaf server.

The docker-compose.override.yml file

If present, the config/docker-compose.override.yml file will be included in the invocation to docker compose. This is useful for overriding configuration specific to Docker compose.

See the for more details.

Services

The Server Pro infrastructure comprises four primary services: sharelatex, git-bridge (optional), mongo and redis. The sharelatex service, which runs the main Server Pro application, depends on the mongo and redis services for its database and caching/real-time functionalities and the git-bridge to handle the (optional). The only port published on the host machine is port 80, which is by the sharelatex container.

Server Pro also optionally supports for project files and full project history as well as being able to proxy access to the main . For more information, see our guide on pages.

Compiling

For , the sharelatex container will orchestrate the creation of new containers to handle project compiles, it does this via the Docker socket on the host machine. You can read more about the editor and end-to-end compile/caching process .

Networking

Communication between containers is facilitated through Docker's internal DNS resolution via a dedicated bridge network, and no firewalls are enabled. By default, the above services use their respective standard ports but are configurable by environment variables. The sharelatex container uses port 80 for external web access (served by Nginx), the mongo container uses port 27017 and redis uses port 6379.

For customers using our managed solution , you can optionally for terminating HTTPS connections using Nginx via an environment variable. Alternatively, you can use your existing TLS proxy.

Summary

• Outside the Docker network, only port 80 is accessible and bound to Nginx. Note: The sharelatex container runs many that communicate with each other via HTTP. However, these ports are not accessible from outside the Docker network.

• Inside the Docker network, Overleaf services, MongoDB, Redis and Git Bridge can talk to each other freely.

• Inside containers, no network is available.

Overleaf Community Edition and Server Pro have both been architected to work offline, which means that it may not always be possible to reach the quay.io registry to pull the required sharelatex , sharelatex-pro and TeX Live images. This is not a problem as Docker provides tooling for exporting and importing images that will help you with an offline/air-gapped deployment.

At a high level, you'll download the required images on a device with internet connectivity, export them to a portable device (or transfer them using SCP/Rsync), and import them on the air-gapped server.

To do this, you'll need to complete the following steps:

• Pull all the required images (sharelatex, sharelatex-pro, git-bridge, mongo, redis + any required for use with ) on a machine with internet connectivity

  • docker pull quay.io/sharelatex/sharelatex-pro:5.1.1

  • docker pull quay.io/sharelatex/git-bridge:5.1.1 (tag must be the same as sharelatex-pro)

  • docker pull mongo:6
• For each of the pulled images, you'll need to then export them to a .tar file. For example, docker save quay.io/sharelatex/sharelatex-pro:5.1.1 > sharelatex-pro:5.1.1.tar

• Using your preferred method, transfer the .tar files from your internet-connected machine to the offline/air-gapped server

• For each of the .tar files, use the docker load command to load the image from the .tar file. For example, docker load < sharelatex-pro:5.1.1.tar

• Finally, run the docker images command to view/confirm the loading of images was successful and that they are available

When provisioning hardware to run Overleaf, the main factor to consider is how many concurrent users will be running compiles.

For example, if you have a license for 100 total users, but only expect ~5 to be working at the same time, the minimal install will be sufficient. If you expect a higher proportion to be working (and compiling) simultaneously, you should consider provisioning a server with a higher specification.

Minimal install

A minimum base requirement of 2 cores and 3GB memory is required for basic operations with around 5 concurrent users. This minimum requirement will also be sufficient for larger groups where there is less concurrent usage, or where it is OK for compile times to be longer during heavier usage.

From a login perspective, the primary identifier for a user is their email address. If you are migrating from locally based authentication to SSO or you're migrating from one IdP to another, you may be required to update users email addresses.

To help with this, a script is provided that will migrate user emails using a CSV file with the following format:

oldEmail,newEmail

After performing some validation checks, the script will iterate through the CSV file and update the users' email addresses from oldEmail to newEmail.

Viewing a projects audit log

Administrators can see an Audit Log for each project. This audit log shows events such as when link-sharing changed between private/token-based, when invites were sent/accepted and when a user joined the project using a token. Administrators can view these logs on a per-project basis via Your Instance -> Admin -> Manage Users then:

• Search for the user

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:

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

If you're currently using Docker Compose via a docker-compose.yml file, migrating to the Toolkit can make running an on-premises version of Overleaf easier to deploy, upgrade and maintain.

To migrate, you'll need to convert your existing Docker Compose setup into the format used by the Toolkit. This process involves copying existing configuration into the Toolkit.

This guide will walk you through each step of this process, ensuring a smooth migration from Docker Compose to the Toolkit.

Updates to this page:

• (2024-04-22 13:40 BST): Added step "Stop new updates from getting into the system and flush all changes to MongoDB".

• (2024-04-23 11:45 BST): Account for broken flushes in 5.0.1 and skip flushes when 5.0.2 was started.

The duration of the recovery will depend on the number and size of projects in your instance and the storage backend used by the history store for chunks (as defined in OVERLEAF_HISTORY_CHUNKS_BUCKET).

The recovery process will delay the application start inside the Server Pro container. The site will appear offline during that time. We only support running the recovery from a single instance of the Server Pro container, all other horizontal scaling workers need to be offline.

You can stop and resume the recovery process if needed.

Based on our performance tests, the recovery process can process approximately 10k small projects per minute on modern hardware (3GHz CPU clock speed and local NVMe storage). As an example, for an instance with 100k projects, schedule a maintenance window that allows at least 10+2min of downtime. Use the following query to estimate the number of projects in your instance:

Please read the following recovery steps in full before you start. Server Pro customers are more than welcome to reach out to [email protected] with any questions.

Recovery process

With Server Pro, you have the ability to create and publish your own templates, within your self-hosted environment, as well as re-distribute downloaded templates from the Template Gallery on overleaf.com.

Setting up the templates user

In Server Pro, a single user is responsible for publishing the curated list of templates that are visible on your local template gallery /templates.

To do this, you'll need to set the environment variable OVERLEAF_TEMPLATES_USER_ID in toolkit/config/variables.env to the ID of the user who will be responsible for template management within your instance, for example:

To obtain the ID of the user you wish to publish public templates:

1. Log in using an Administrator account and go to Admin > Manage Users.

2. Search for the user using their email address and click through to their user admin page. There you will find the ID:

3. Copy that ID and use it to set the environment variable OVERLEAF_TEMPLATES_USER_ID

Publishing templates

If you'd like to make templates available to all of your on-premise Server Pro users you'll need to:

1. Log in as the templates user.

2. As the templates user, create or upload a project containing the template's source code and make sure it compiles.

3. In the editor's left-hand menu, choose Manage Template.

4. Enter a custom description of the template

Unpublishing templates

If you'd like to unpublish a template you'll need to:

1. Log in as the templates user.

2. Open the previously existing project containing the template's source code.

3. In the editor's left-hand menu, choose Manage Template.

4. Once the confirmation popup is displayed, click Unpublish.

Once this has been done, the template should have been removed from the templates list.

Linking to your templates

Your gallery

On the templates gallery page, /templates, templates are grouped together using the tag which the user assigns to the projects, e.g. Journals, Reports etc. To see all templates add /all to the URL /templates/all, which can also be used as the default URL if you do not wish to use tags for groupings.

Like-wise, you can view/link to templates within a specific category by appending the tag name to the templates URL, for example: /templates/journals.

New project menu

When a user creates a new project, they can be shown customized links to template categories. These links are set via the OVERLEAF_NEW_PROJECT_TEMPLATE_LINKS environment variable in toolkit/config/variables.env, for example:

Transferring templates from overleaf.com

As Server Pro has been architected to work offline, there isn't an automated way to integrate gallery templates into your on-premise installation, it is however possible to do this manually on a per template basis.

By default, Server Pro is configured to use a basic scheme version of TeXLive for compiles. This basic version is lightweight and only contains a very limited subset of LaTeX packages which, will most likely result in missing package errors for your users when attempting to use templates from on your local on-premise instance.

Unfortunately, whilst there isn't an automatic way to install missing packages, we do have a configurable setting within Server Pro that will allow your users to compile projects with access to more packages, and in a more secure way. This feature is called (also known as Sibling Containers).

To ensure that downloaded templates are compatible with your on-premise Server Pro instance, we highly recommend that you enable as this feature will provide your users with access to the same TeX Live environment as that on . These images contain the most popular packages and fonts and have already been tested against our gallery templates.

You can find additional information about configuring what TeX Live versions users are able to choose from within their project along with setting the default TeX Live image version for new projects in the section of our documentation.

1. Navigate to the on and locate the required template, for example

2. Click on the Open as Template button

3. Click on the project menu and choose Download Source

4. Next, log into the on-premise Server Pro account

The user can then use this newly uploaded template within their own account, or, as the templates user, you can publish it for other users to use.

Release notes 0.6.x

Server Pro 0.6.3

The Doctor

The Overleaf Toolkit comes with a handy doctor script, to help with debugging. Just run bin/doctor and the script will print out information about your host environment, your configuration, and the dependencies the Toolkit needs. This output can also help the Overleaf support team to help you figure out what has gone wrong, in the case of a Server Pro installation.

Thinking about changing how your users log in to Overleaf Server Pro? You're in the right place! This guide is for you if you're currently using our native username and password login and want to switch to an external one like LDAP/Active Directory or SAML 2.0. It also covers how to switch back if you ever need to.

We’ll use LDAP in our examples, but don't worry—the process is exactly the same if you're using SAML. Let's dive in!

Switching from native authentication

Let's imagine you've been running Server Pro for a while or have recently upgraded from the Community Edition. You have user, Alice, who logs in with their email, [email protected], and a password they created in Overleaf. Behind the scenes, their Overleaf accounts look something like this:

The Overleaf Toolkit is the recommended deployment method for on-premises installations of the Community Edition and Server Pro and has been designed to work with the most common environment: a single physical server or virtual machine. The Toolkit uses docker compose to manage your server's Docker containers and provides a set of scripts which wrap docker commands to assist with the more technical side of managing an on-premises version of Overleaf.

The bin/docker-compose wrapper

The bin/docker-compose

Overleaf supports sending email through two methods: Simple Mail Transfer Protocol (SMTP) and Amazon Simple Email Service (SES). SMTP can be used if you have an email server enabled on your localhost that is listening for local connections.

Configuration

Email is configured using the following environmental variables.

Sender Configuration

SMTP

Amazon SES SMTP interface

You can read more about using the Amazon SES SMTP interface to send email .

Amazon SES API

You can read more about using the Amazon SES API to send email .

AWS SES with Instance Roles

Customisation

Server Pro provides LDAP server integration for user authentication and is compatible with Active Directory systems. For Toolkit deployments, the LDAP integration is configured via the config/variables.env file.

Overview

Internally, the LDAP integration uses the library. Most of these configuration options are passed through to the server config object which is used to configure passport-ldapauth. If you are having issues configuring LDAP, it is worth reading the for passport-ldapauth

This page describes the environment variables that are supported in the config/variables.env file for Toolkit deployments.

The config/variables.env file consists of variable definitions in the form NAME=value, lines beginning with # are treated as comments.

Provisioning users

In Server Pro, we only support using a single method of authentication at any one time. Once SSO has been enabled, users/administrators won't be able to log in using an Overleaf password, and you won't be able to create new users from the https://{your-instance-url}/admin/user URL.