This page contains some notes on running Overleaf using the new "toolkit" deployment developed by Overleaf that automatically pulls and builds all dependencies in order to avoid requiring people to scrounge together the correct dependent versions and set up configurations that are not-so-relevant.

The page mentions ARM64 because using Overleaf toolkit is also the safe way of creating containers that will be able to run on ARM64 as well.

cd OVERLEAF_HOME
git clone https://github.com/overleaf/toolkit.git
cd toolkit
bin/init

where:

• OVERLEAF_HOME is any directory root where overleaf and dependencies will be installed to; from the FSH, /opt should be the correct directory

After the commands run, the configuration file config/overleaf.rc should be edited to set:

• OVERLEAF_LISTEN_IP to 0.0.0.0 and,
• OVERLEAF_PORT to any custom port number

The next step is to actually build the relevant containers:

cd OVERLEAF_HOME
git clone https://github.com/overleaf/overleaf.git
cd overleaf/server-ce
 
make ARCH=arm build-base
make ARCH=arm build-community

This process will take a long while and it will build the basic container that containers all the instrumentation necessary to run Overleaf and then it will build the community edition of Overleaf itself.

Finally the build overleaf image must have its name changed according to the version found in OVERLEAF_HOME/toolkit/config/version by running the command:

docker image tag sharelatex/sharelatex:main sharelatex/sharelatex:OVERLEAF_VERSION

where:

• OVERLEAF_VERSION is the version mentioned in OVERLEAF_HOME/toolkit/config/version

The documentation mentions running Overleaf by running:

bin/up -d

which will start Overleaf and all dependent containers.

However, it is clear that this will have to be changed in an OS-compliant manner, for instance, by using SystemD. Before that, the command bin/up -h can be ran in order to receive the list of parameters that can be passed to the bin/up script. Out of all parameters, the following parameters will be used to run Overleaf:

./bin/up --remove-orphans --no-recreate --attach-dependencies 

where:

• –remove-orphans will remove any leftovers when the containers are restarted,
• –no-recreate will not rebuild all the containers and dependencies if they already exist and this is essential because the building process can take hours,
• –attach-dependencies will make the script attach to the log output of Overleaf and all dependencies, which is useful for keeping the script running.

Wrapping that up for SystemD, something like the following should work:

[Unit]
Description=Overleaf
After=docker.service traefik.service
StartLimitIntervalSec=0

[Service]
Restart=always
RestartSec=5s
ExecStartPre=/bin/sh -c '/usr/bin/docker network create entertainment || true'
ExecStart=/opt/overleaf/toolkit/bin/up --remove-orphans --no-recreate --attach-dependencies
WorkingDirectory=/opt/overleaf/toolkit
TimeoutSec=300
Environment=DOCKER_CONFIG=/etc/docker

[Install]
WantedBy=multi-user.target

Note that the SystemD service file creates the entertainment network and it is left there to match the Servarr complete stack that we devised because running Overleaf along the rest is compact and fun.

Note that the Overleaf toolkit does not really allow the level of customization that docker compose allows but the Overleaf toolkit can be modified in order to make Overleaf bind to the network that traefik listens on. This setup is entirely compatible with both the LAN auto-discovery feature as well as the all-in-one traefik template that bundles reverse-DNS, automatic dynamic DNS as well as authelia for global authentication and authorization with pluggable modules such that there are really no other changes required to Overleaf other than extending its network to the network that the other projects operate on (in our examples, the network is called entertainment).