Jakob Ackermann
37e27bb22e
* [monorepo] reduce writes from chrome in cypress Chrome puts its shared memory in /dev/shm, and docker's default 64MB is far too small for it - which is why Cypress passes --disable-dev-shm-usage, spilling those segments to files on the container's writable layer instead. Under one spec that is a few hundred MB of write-then-delete churn; under the CI fan-out it was most of the disk bandwidth on the whole box. So every service built from dockerfiles/cypress gets shm_size 1gb and every cypress config drops the flag again: the SaaS e2e service, web's CI and local component-test services plus its standalone cypress one, and server-ce's e2e and native cypress services. Both e2e-open variants inherit the setting through `extends`; the native one is a service of its own, and would be left running Chrome against 64MB once the flag is gone. * [monorepo] adopt cypress-pnp-reporter Materializing the reporter packages copied 267 packages / 3779 files (59MB) into /tmp on every container start, once per spec. Resolving them through PnP inside Cypress's Electron process instead drops that to zero: the entrypoint shell went from 55.6MB of write_bytes to 0. * [web] serve built assets from a prepared buffer between builds Serving a chunk cost ~2ms whatever its size, and an editor page pulls ~144 of them, so webpack-dev-server burned 2-3 cores through an e2e run purely answering requests for output that had not changed since the last build. It is not bytes: cutting the bundle 2.6x with a cheaper devtool moved CPU by 8%, and an empty 304 cost nearly as much as the full body. It is the per-request work - reading the asset out of the in-memory filesystem and re-hashing the whole body for a strong ETag, on every request. Three things a build does that this has to respect, each found by tracing the hooks rather than by reading them: - `done` fires twice per build, for the compilation and for the manifest, both with the same hash. A flag would have been cleared by the second while the first was still running, so the gate is a counter. - An incremental `done` reports only the assets it rewrote - 16, not 630 - so asset names accumulate. Resetting them on `invalid` left the manifest's two behind and nothing was served from here again. - webpack-dev-middleware holds requests during a rebuild. This sits in front of it, so it steps aside for that window and drops the cache when a rebuild starts. Whether a response can be kept is then decided as it ends rather than as it began: an epoch bumped on `invalid` names the build its bytes were read from, and only a response from the current build with no rebuild in flight is stored. A rebuild starting mid-response can no longer write the previous build's bytes in behind the cache being dropped, which eviction by asset name could not catch anyway - an incremental build does not name the assets it left alone. Measured on the editor entrypoint, 16 concurrent clients: 0.26-0.31s -> 0.045-0.050s of webpack CPU per page load, and 0.0455s immediately after a rebuild. Same chunk graph, byte-identical output. GitOrigin-RevId: 08b4ab2d665414069bc01b4763dd64faa9b4e5cb
An open-source online real-time collaborative LaTeX editor.
Wiki • Server Pro • Contributing • Mailing List • Authors • License
Figure 1: A screenshot of a project being edited in Overleaf Community Edition.
Community Edition
Overleaf is an open-source online real-time collaborative LaTeX editor. We run a hosted version at www.overleaf.com, but you can also run your own local version, and contribute to the development of Overleaf.
Caution
Overleaf Community Edition is intended for use in environments where all users are trusted. Community Edition is not appropriate for scenarios where isolation of users is required due to Sandbox Compiles not being available. When not using Sandboxed Compiles, users have full read and write access to the
sharelatexcontainer resources (filesystem, network, environment variables) when running LaTeX compiles.
For more information on Sandbox Compiles check out our documentation.
Enterprise
If you want help installing and maintaining Overleaf in your lab or workplace, we offer an officially supported version called Overleaf Server Pro. It also includes more features for security (SSO with LDAP or SAML), administration and collaboration (e.g. tracked changes). Find out more!
Keeping up to date
Sign up to the mailing list to get updates on Overleaf releases and development.
Installation
We have detailed installation instructions in the Overleaf Toolkit.
Upgrading
If you are upgrading from a previous version of Overleaf, please see the Release Notes section on the Wiki for all of the versions between your current version and the version you are upgrading to.
Overleaf Docker Image
This repo contains two dockerfiles, Dockerfile-base, which builds the
sharelatex/sharelatex-base image, and Dockerfile which builds the
sharelatex/sharelatex (or "community") image.
The Base image generally contains the basic dependencies like wget, plus texlive.
We split this out because it's a pretty heavy set of
dependencies, and it's nice to not have to rebuild all of that every time.
The sharelatex/sharelatex image extends the base image and adds the actual Overleaf code
and services.
Use make build-base and make build-community from server-ce/ to build these images.
We use the Phusion base-image
(which is extended by our base image) to provide us with a VM-like container
in which to run the Overleaf services. Baseimage uses the runit service
manager to manage services, and we add our init-scripts from the server-ce/runit
folder.
Contributing
Please see the CONTRIBUTING file for information on contributing to the development of Overleaf.
Authors
License
The code in this repository is released under the GNU AFFERO GENERAL PUBLIC LICENSE, version 3. A copy can be found in the LICENSE file.
Copyright (c) Overleaf, 2014-2025.