Overleaf gives a free-plan project 10 seconds to compile and a paid plan 240 seconds (Overleaf's own documentation, checked August 2026). That factor of twenty-four is the most legible entry point into the question of whether to keep writing LaTeX in the cloud or to keep an environment of your own. The real argument, though, is not about speed. It is about whose server holds your manuscript, whether you can choose the TeX Live version, and whether you can get your sources out if the service stops. This page is not an introduction for first-timers; it is the cloud-versus-local decision for people already writing. Start with the event in 2017 that explains why Overleaf, of all services, can be run on your own server.
Overleaf is open source because of a merger in July 2017
On 20 July 2017 Overleaf acquired its competitor ShareLaTeX (Scribtex Limited). The announcement put two things on record: that the ShareLaTeX editor would be “at the core of the new platform”, and that all of the open ShareLaTeX code base would remain open source and continue to be actively developed. Those two promises explain the present situation exactly. Overleaf itself began at the end of 2012 as WriteLaTeX, started by John Hammersley and John Lees-Miller, and was renamed Overleaf in 2015. The post-merger “Overleaf v2” was built on ShareLaTeX's editing engine, and that open-source lineage is still published today as overleaf/overleaf under the AGPL v3.
That episode matters in practice because choosing the cloud does not have to mean handing your work to somebody else. Cloud LaTeX and Papeeria are hosting-only; there is no path to running them yourself. Among the major services, Overleaf is effectively the only one you can operate in-house, and the reason is not technical but that merger in 2017. Which means the question that looks like a binary is really a choice of three: someone else's server, your own server, or your own computer. What follows settles the binary with numbers first, and comes back to the third road at the end.
What the free Overleaf plan will not let you do
Three limits actually bite: compile time, project size and Git. There is no cap on how many pages you may write for free, and no cap on the number of projects, but of the figures in the official documentation these three are the ones you meet in practice. The Git one is the easiest to overlook: Git integration is a premium feature, so the plan “start free and pull everything down later with its history” does not work. The table below reproduces the numbers from Overleaf's documentation as of August 2026.
| Item | Overleaf value (official docs, August 2026) | How it bites |
|---|---|---|
compile timeout | 10 seconds free, 240 seconds paid | The first wall a long thesis or heavy TikZ hits |
editable material | 7 MB per project; 2 MB per individual text file | Reachable with a huge .bib or generated tables |
uploads | 50 MB per upload; 2000 files per project | A problem for manuscripts with many high-resolution figures |
project size | Under 500 MB recommended; under 100 MB when using Git or GitHub | Thin out figures early if they go into version control |
collaborators | 10 invited on Standard and Student; unlimited on Pro | Bites in a lab where the author list keeps growing |
git clone | A premium feature; also available on Server Pro 4.0 and later | No history export on the free tier — this is the exit-strategy question |
Can you pin the TeX Live version in the cloud?
With Overleaf, yes. The TeX Live year is a per-project setting, and the versions its own blog has announced go back as far as 2016. A new project defaults to the newest release installed on their servers, so when a publisher demands a specific year you switch explicitly. This one control matters more than it looks: most cases of “it compiles on Overleaf but not on my machine” come down to the distribution year rather than the editor. Where the setting lives in the interface is covered on the Overleaf page.
Other services handle it differently. Cloud LaTeX describes its environment as the latest full TeX Live, stable and development, updated by the service rather than chosen by the user. Japanese submission guidelines often demand “typeset with TeX Live 20xx”, so the difference is not academic. If reproducibility comes first, a container image digest beats any cloud year-picker — that is simply true, and for a thesis or for work that may need reproducing years later, the practical settlement is to write in the cloud and hand only the final build to a container.
Cloud LaTeX and the KAKENHI templates: the option for writing in Japanese
Cloud LaTeX sells two things: Japanese that typesets with no configuration, and a template library of over a hundred that includes the KAKENHI grant-application forms. It is run by Acaric. Typesetting Japanese on Overleaf takes a step — switching the compiler from the default pdfLaTeX to LuaLaTeX, for instance — whereas on Cloud LaTeX that is the starting state. It also offers Dropbox sync and a VS Code integration, so you are not locked inside a browser tab. Because Japanese grant forms change their layout every year, the practical value lies in whether those templates keep being updated.
The third option, Papeeria, has a permanent free tier with unlimited public projects but only one private project. It has Git integration too, though on the free tier that covers public repositories only — private repositories are a paid feature. Summarised crudely: Cloud LaTeX if you mostly write Japanese, Overleaf if you have many co-authors or work from templates, Papeeria if the work is public by default. That is only a starting point, though; the next two sections — institutional accounts and getting your sources out — matter more over the life of a project.
Check whether your university has Overleaf Commons
Before buying a paid plan personally, check whether your institution holds a site licence. Overleaf Commons is the subscription by which an organisation provides Overleaf across its whole membership; where it is in place, every member gets the premium feature set — longer compile times, more collaborators, track changes, Git integration. Enrolment usually completes by signing in through the institution's single sign-on or simply confirming an email address on an entitled domain. Plenty of universities have taken it up: UCLA, for instance, announced that from 7 April 2025 all current students, faculty and staff have access to a free Overleaf Professional account. Searching your own IT department's pages first is the highest-return move available.
A site licence, though, is tied to a status that expires. Enrolment holds because your affiliation is confirmed, so when graduation or a change of job ends that confirmation, the premium features end with it. Writing a master's thesis on an institutional account, then opening it after graduation at a co-author's request and finding no history, is an entirely plausible accident. That is why the standing rule for collaborative work is to make a lab or project-controlled account the owner rather than one person's personal account, and to export the whole source before you leave.
May unpublished research live in the cloud?
This is a question about rules, not about technology. Every service describes its encryption and access controls, but what decides the matter is your institution's information-handling policy, the terms attached to your funding, and the confidentiality agreement covering the collaboration. If any of those says data must not leave the organisation, no hosted service qualifies however good it is. Where no such constraint applies, the cloud has a great deal going for it. The comparison below assumes the rules permit it, and should be read not as “which is better” but as what you give up and what you keep in your own hands.
| Concern | A hosted service | A local installation |
|---|---|---|
where the source lives | On the provider's servers — depending on your rules, this line alone can rule it out | On your own disk; the question of data leaving never arises |
maintenance | None; updates happen on the server side | You update it and manage the packages |
devices and network | Any device with a browser, but a connection is generally required | Only the machine you installed on, and it works with no network at all |
collaboration | Real-time co-editing out of the box, capped by the plan's collaborator limit | You build it yourself, typically with Git; there is no cap on people |
compile ceiling | Whatever the plan allows — 10 seconds free, 240 seconds paid on Overleaf | No cap; your machine's speed is the only limit |
version pinning | Within what the service offers; Overleaf lets you choose the year | Any package or font freely, right down to a pinned image digest |
Exit strategy: can you take the sources out, history and all?
Every service lets you export a ZIP. The history is the problem. On Overleaf, the git clone that pulls down a whole project with its history is a premium feature and not available to a free account. Cloud LaTeX offers ZIP export plus Dropbox sync, so a current copy of the source can always sit on your own disk. Papeeria is built around Git, but its free tier reaches public repositories only. The rule of thumb that falls out is a single sentence: pick a service you can git clone your way out of. Whatever happens to the server, the manuscript and its history stay with you.
That exit doubles as the entrance to CI. Keep an Overleaf project synchronised with a GitHub repository and every push can trigger GitHub Actions to typeset it in a clean TeX Live, verifying outside the browser that the PDF really does build. You keep the comfort of the cloud while a machine checks that the work is genuinely reproducible — valuable above all on co-authored papers. As noted, though, the Git and GitHub integrations are premium features, so this arrangement is out of reach on a free account. Day to day, deciding these three things prevents most of the serious accidents.
- Decide the owner first. For collaborative work, make a lab or project-controlled account the owner, not one person's personal account.
- Write the environment into the README. One line naming the service, the compiler and the TeX Live year is what you will need to reproduce the build locally or in a container.
- Export everything before submission. Put the PDF, the source ZIP, the
.biband the source data behind the figures into a single dated folder.
Running Overleaf on your own server
This is the third road. Overleaf's core is published as overleaf/overleaf under the AGPL v3, and that is Overleaf Community Edition (CE). A lab or a company can therefore run its own Overleaf on its own server, entirely independent of the commercial overleaf.com. The recommended route is the official Overleaf Toolkit: a Docker Compose stack that brings up the Overleaf application together with MongoDB for its database and Redis for its cache. Clone overleaf/toolkit from GitHub, initialise it, start it, and you have an Overleaf reachable from your own browser. Once it is standing, it will run in a network with no internet connection at all.
# Bring up your own Overleaf with the official toolkit.
git clone https://github.com/overleaf/toolkit.git
cd toolkit
bin/init # generates the config/ directory
bin/up # starts Overleaf + MongoDB + Redis via Docker ComposeWhat you gain is control of your data and independence from an outside party. No manuscript leaves your organisation's servers, and no outage or price change touches you. The price is the operation itself: provisioning, backups, upgrading TeX Live and security all become your job. And there is one further constraint that cannot be waved away. The free Community Edition has no “Sandboxed Compiles” to isolate compilation. A user's LaTeX compile runs with the same privileges as the container and can reach its filesystem and its network. The project's own README states plainly that CE is intended for use in environments where all users are trusted.
If you need to open the service more widely, or you need isolation, single sign-on via LDAP or SAML, or tracked changes and the other enterprise features, the paid Server Pro edition exists. The practical rule: CE is enough for a small, trusted lab; consider Server Pro before opening it to a whole university. And do not forget that the moment you choose to self-host, the cloud's great advantage — not having to maintain anything — is gone. The last of the three roads is the freest and the most work.