Overleaf Community Edition: the self-hosted server behind the LaTeX editor

The repository is a server, not a LaTeX engine

A first thing to sort out is what this codebase actually is. The description says a web-based collaborative LaTeX editor, and the hosted service at overleaf.com runs on it, but the repository contains no TeX implementation and no typesetter. TeX Live arrives from the operating system layer of the container image.

The layout in the repository explains the shape. `server-ce/` holds the Community Edition container build, `services/` the individual services, `libraries/` shared JavaScript packages, `tools/` developer tooling and `bin/` the command line entry points. There is also `doc/`, a `docker-compose.yml`, a separate `docker-compose.debug.yml` and a root `package.json` that describes a private workspace driven by Yarn.

The root package manifest pins the toolchain expectations rather than the application dependencies. It sets `packageManager` to `[email protected]` and requires Node `>=24.18.1` in its `engines` field, which is a high floor and a useful signal about how much of the old Node 18 era has been cleaned up.

The security boundary that decides who can run it

The README leads with a caution rather than a feature list, and that ordering is deliberate. Community Edition is intended for environments where all users are trusted. It is described as not appropriate for situations where user isolation is required, because Sandbox Compiles are not available in this edition. Without those compiles, a user running a LaTeX build has full read and write access to the container's filesystem, network and environment variables.

That is a concrete architectural statement rather than a policy preference. A LaTeX document is a program that the compiler executes, and this edition runs it inside the same container as the web application. Anything a hostile document can do, a user can do, including reading data belonging to other projects.

The distinction between editions is drawn around this and around identity. Overleaf Server Pro is the supported version and adds security features such as SSO with LDAP or SAML, along with administration and collaboration tooling like tracked changes. The README links sandboxed compiles to documentation that is marked as Server Pro only configuration, which tells you the capability exists in the product line and is simply not in this repository.

So the first question for an evaluator is not whether the editor works. It is who holds an account.

Two images, split because TeX Live is heavy

The build is described in enough detail in the README to be useful, which is unusual for a project of this size. There are two Dockerfiles in `server-ce/`. `Dockerfile-base` builds the `sharelatex/sharelatex-base` image, and `Dockerfile` builds the `sharelatex/sharelatex` image that is also called the community image.

The split has a stated reason: the base image carries the basic dependencies such as wget plus TeX Live, and rebuilding that set on every change is expensive. The second image extends the first and adds the Overleaf code and services.

Both are built with make targets from the `server-ce/` directory:

make build-base
make build-community

The runtime is built on the Phusion base image, extended by the project's own `base` image, which provides a VM-like container. Baseimage uses runit as its service manager, and the project adds its init scripts from `server-ce/runit`. That detail matters if you are debugging a process that will not start, because it tells you that service management is runit-based rather than systemd-based or a plain shell entrypoint.

Mongo, Redis and the environment variables that actually matter

The compose file is the most informative artifact in the repository, and it is short. The `sharelatex` service runs the `sharelatex/sharelatex` image, waits for `mongo` to report healthy and for `redis` to have started, publishes port 80 on the host, and mounts `~/sharelatex_data` at `/var/lib/overleaf` so project files and the uploaded data survive a container replacement. It sets `stop_grace_period` to 60 seconds, which is there because compiles are long-running work that should not be killed mid-build.

The environment block is where the configuration surface shows through. Two names point at the same Redis because the property is spelled differently in different places in the codebase:

      OVERLEAF_MONGO_URL: mongodb://mongo/sharelatex

      OVERLEAF_REDIS_HOST: redis
      REDIS_HOST: redis

Further down, `ENABLED_LINKED_FILE_TYPES` controls which linked file types are offered, `ENABLE_CONVERSIONS` turns on thumbnail generation through ImageMagick, and `EMAIL_CONFIRMATION_DISABLED` is set to `true`, which is a sensible default for a fresh local instance. `OVERLEAF_INVITE_TOKEN_SECRET` is marked as required for invite token generation, with the note that it should be generated with `openssl rand -base64 32`. Branding is available too, through `OVERLEAF_SITE_URL`, `OVERLEAF_NAV_TITLE` and the header image variables, and `VIRTUAL_HOST` is present for nginx-proxy style setups.

GitHub releases stopped in 2015, and that is not an abandonment

Here is a detail worth knowing before you plan an upgrade. The release list on this repository ends at v0.1.3, published on 2015-02-26, with v0.1.2 and v0.1.1 before it and v0.1.1 described as a dependency lock-down with no code changes. The last push to `main` was on 2026-09-17, and the repository is not archived.

Both facts are true at once, and the way to hold them together is that this project stopped cutting GitHub releases and moved to a different distribution channel. The README points upgrading at the Release Notes section on the project wiki, and installation at the Overleaf Toolkit, which is a separate repository. The version a deployment actually runs is the version of the `sharelatex/sharelatex` container image, not a GitHub tag.

For an operator that means the upgrade path is not `git pull` plus a release diff. It is the wiki notes plus the Toolkit plus a change in image tag. It also means GitHub's release list is close to useless as a changelog here, and the wiki is the document to read when you are moving between versions.

Licensing is the other thing to settle early. The repository is AGPL-3.0, with the license text in the `LICENSE` file and the README stating the code is released under the GNU Affero General Public License version 3, copyright Overleaf 2014 to 2025. For a network service the AGPL has real consequences around offering a modified version, and that question is worth settling with your own counsel rather than with an article.

What running this costs you

The operational surface is bigger than a single container. You need Mongo and Redis, which the compose file supplies, and you need enough disk for project files, the compile cache and the TeX Live installation that comes baked into the base image. There is no published sizing guidance in the README, so capacity planning is on you.

The toolchain is also split in a way that affects contributors more than operators. Yarn 4 is used with a `.pnp.register.mjs` file at the root and a checked-in `yarn.lock`, and the `package.json` carries a long `resolutions` block that pins transitive packages, including a patched `sandboxed-module` from a path inside the repository. `CONTRIBUTING.md` is the entry point for the development workflow, and `tsconfig.backend.json` implies the backend is TypeScript even though the repository's primary language is JavaScript.

Compared with the alternative of running LaTeX yourself, the exchange is straightforward. A self-managed editor means maintaining the server, the database pair, the container base image and the wiki-documented upgrade path yourself. What you get back is accounts, project history, real-time collaborative editing and a compiled-PDF preview that the reader does not have to assemble. If your users are students who need version history and comments, that is a real saving. If your users are strangers who need isolation, the edition you want is the one with sandboxed compiles, and this repository is not it.

Editorial conclusion

Overleaf Community Edition is a serious piece of server software with a specific fit: a lab, a reading group or a company that already trusts everyone with an account and wants the editor on its own infrastructure. The compose file makes the deployment concrete, Mongo and Redis are required, and the build runs through a base image that carries TeX Live. The boundary to respect is the missing sandboxed compiles, which the README flags as a caution rather than a footnote, because an unsandboxed compile can reach the filesystem, network and environment of the container. Start by reading the caution block against your own threat model, then follow the Toolkit instructions, and pin the `sharelatex/sharelatex` image tag rather than tracking whatever the latest tag holds.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. overleaf/overleaf on GitHub
4. README
5. Releases