TeX im Web (Overleaf / Cloud LaTeX)

Overleaf gibt einem Projekt im kostenlosen Tarif 10 Sekunden zum Kompilieren, im bezahlten 240 Sekunden (Overleafs eigene Dokumentation, geprüft im August 2026). Dieser Faktor vierundzwanzig ist der anschaulichste Einstieg in die Frage, ob man LaTeX weiter in der Cloud schreibt oder eine eigene Umgebung unterhält. Das eigentliche Argument dreht sich allerdings nicht um Geschwindigkeit. Es geht darum, auf wessen Server das Manuskript liegt, ob sich die TeX-Live-Version wählen lässt und ob man die Quellen herausbekommt, wenn der Dienst endet. Diese Seite ist keine Einführung für Neulinge, sondern die Entscheidung Cloud gegen lokal für Leute, die bereits schreiben. Beginnen wir mit dem Ereignis von 2017, das erklärt, warum sich ausgerechnet Overleaf auf einem eigenen Server betreiben lässt.

Dass Overleaf quelloffen ist, verdankt sich einer Fusion im Juli 2017

Am 20. Juli 2017 übernahm Overleaf den Wettbewerber ShareLaTeX (Scribtex Limited). Die Ankündigung hielt zweierlei fest: Der ShareLaTeX-Editor werde „im Kern der neuen Plattform“ stehen, und die gesamte offene ShareLaTeX-Codebasis bleibe quelloffen und werde weiterentwickelt. Diese beiden Zusagen erklären die heutige Lage genau. Overleaf selbst begann Ende 2012 als WriteLaTeX, gegründet von John Hammersley und John Lees-Miller, und wurde 2015 in Overleaf umbenannt. Das „Overleaf v2“ nach der Fusion wurde auf der Editor-Engine von ShareLaTeX errichtet, und diese quelloffene Linie erscheint bis heute als overleaf/overleaf unter der AGPL v3.

Diese Episode zählt in der Praxis, weil die Entscheidung für die Cloud nicht heißen muss, die Arbeit aus der Hand zu geben. Cloud LaTeX und Papeeria sind reine Hosting-Dienste; sie selbst zu betreiben ist nicht vorgesehen. Unter den großen Diensten lässt sich faktisch nur Overleaf im Haus betreiben, und der Grund dafür ist nicht technisch, sondern jene Fusion von 2017. Damit ist die scheinbar binäre Frage in Wahrheit eine Wahl zwischen dreien: dem Server eines anderen, dem eigenen Server oder dem eigenen Rechner. Im Folgenden wird zuerst die binäre Frage mit Zahlen geklärt; der dritte Weg kommt am Schluss.

Was der kostenlose Overleaf-Tarif nicht erlaubt

Drei Grenzen greifen wirklich: Kompilierzeit, Projektgröße und Git. Für die Zahl der kostenlos geschriebenen Seiten gibt es keine Obergrenze, für die Zahl der Projekte ebenso wenig; von den Werten in der offiziellen Dokumentation begegnet man in der Praxis jedoch vor allem diesen dreien. Der Git-Punkt wird am leichtesten übersehen: Die Git-Anbindung ist eine Premium-Funktion, der Plan „kostenlos anfangen und später alles samt Historie herunterziehen“ geht also nicht auf. Die Tabelle gibt die Zahlen aus Overleafs Dokumentation wieder (Stand August 2026).

Lässt sich die TeX-Live-Version in der Cloud festnageln?

Bei Overleaf ja. Der TeX-Live-Jahrgang ist eine Einstellung je Projekt, und die im eigenen Blog angekündigten Versionen reichen bis 2016 zurück. Ein neues Projekt nutzt standardmäßig die neueste auf den Servern installierte Ausgabe; verlangt ein Verlag ein bestimmtes Jahr, stellt man ausdrücklich um. Dieser eine Schalter wiegt schwerer, als er aussieht: Die meisten Fälle von „auf Overleaf läuft es, auf meinem Rechner nicht“ gehen auf den Jahrgang der Distribution zurück, nicht auf den Editor. Wo die Einstellung in der Oberfläche sitzt, behandelt die Overleaf-Seite.

Andere Dienste lösen es anders. Cloud LaTeX beschreibt seine Umgebung als das jeweils vollständige TeX Live, stabil und Entwicklung, aktualisiert vom Dienst statt gewählt von der Nutzerin. Japanische Einreichungsrichtlinien verlangen häufig „gesetzt mit TeX Live 20xx“, der Unterschied ist also nicht akademisch. Hat Reproduzierbarkeit Vorrang, schlägt ein Container-Image-Digest jeden Jahrgangswähler in der Cloud – das ist schlicht so, und für eine Dissertation oder für Arbeiten, die Jahre später reproduziert werden müssen, ist der praktische Kompromiss: in der Cloud schreiben und nur den finalen Build einem Container übergeben.

Cloud LaTeX und die KAKENHI-Vorlagen: die Option für japanische Texte

Cloud LaTeX verkauft zwei Dinge: Japanisch, das ohne Konfiguration gesetzt wird, und eine Vorlagensammlung von über hundert Stück, in der die KAKENHI-Antragsformulare enthalten sind. Betrieben wird der Dienst von Acaric. Japanisch auf Overleaf zu setzen kostet einen Handgriff – etwa den Wechsel des Compilers vom voreingestellten pdfLaTeX zu LuaLaTeX –, bei Cloud LaTeX ist das der Ausgangszustand. Dazu kommen Dropbox-Synchronisation und eine VS-Code-Anbindung, sodass man nicht in einem Browser-Tab eingeschlossen ist. Da japanische Förderanträge ihr Layout jährlich ändern, liegt der praktische Wert darin, ob diese Vorlagen weiter gepflegt werden.

Die dritte Option, Papeeria, bietet einen dauerhaft kostenlosen Tarif mit unbegrenzt vielen öffentlichen Projekten, aber nur einem privaten. Auch Git ist angebunden, im Gratistarif jedoch nur für öffentliche Repositorien – private sind kostenpflichtig. Grob zusammengefasst: Cloud LaTeX, wenn überwiegend Japanisch geschrieben wird; Overleaf bei vielen Mitautoren oder vorlagengetriebener Arbeit; Papeeria, wenn die Arbeit ohnehin öffentlich ist. Das ist allerdings nur ein Ausgangspunkt; die nächsten beiden Abschnitte – Hochschulzugänge und der Weg hinaus – wiegen über die Laufzeit eines Projekts schwerer.

Prüfen, ob die Hochschule Overleaf Commons hat

Bevor man privat einen bezahlten Tarif kauft, sollte man prüfen, ob die eigene Einrichtung eine Campuslizenz hat. Overleaf Commons ist das Abonnement, mit dem eine Organisation Overleaf für alle Angehörigen bereitstellt; wo es besteht, erhält jedes Mitglied den Premium-Funktionsumfang – längere Kompilierzeiten, mehr Mitarbeitende, Änderungsverfolgung, Git-Anbindung. Die Aufnahme erfolgt meist über die Single-Sign-On-Anmeldung der Einrichtung oder schlicht über die Bestätigung einer E-Mail-Adresse einer berechtigten Domain. Viele Hochschulen nutzen es: Die UCLA etwa gab bekannt, dass seit dem 7. April 2025 alle eingeschriebenen Studierenden sowie Lehrende und Beschäftigte ein kostenloses Overleaf-Professional-Konto erhalten. Zuerst die Seiten der eigenen IT-Abteilung zu durchsuchen ist der Schritt mit dem besten Verhältnis von Aufwand zu Ertrag.

Eine Campuslizenz hängt allerdings an einem Status, der abläuft. Die Aufnahme besteht, weil die Zugehörigkeit bestätigt ist; endet diese Bestätigung durch Abschluss oder Stellenwechsel, enden die Premium-Funktionen mit. Eine Masterarbeit auf einem Hochschulkonto zu schreiben, sie nach dem Abschluss auf Bitte einer Mitautorin zu öffnen und keine Historie mehr zu finden – das ist ein durchaus realistisches Missgeschick. Deshalb lautet die stehende Regel für gemeinsame Arbeiten: ein vom Labor oder Projekt verwaltetes Konto zum Eigentümer machen, nicht das persönliche Konto einer einzelnen Person – und vor dem Ausscheiden den gesamten Quelltext exportieren.

Darf unveröffentlichte Forschung in der Cloud liegen?

Das ist eine Frage der Vorschriften, nicht der Technik. Jeder Dienst beschreibt seine Verschlüsselung und Zugriffskontrollen, doch entschieden wird die Sache durch die Informationsrichtlinie der eigenen Einrichtung, die Auflagen der Förderung und die Vertraulichkeitsvereinbarung des Verbunds. Steht dort, dass Daten die Organisation nicht verlassen dürfen, kommt kein gehosteter Dienst infrage, so gut er auch sei. Wo keine solche Auflage gilt, spricht vieles für die Cloud. Der folgende Vergleich setzt voraus, dass die Regeln es erlauben, und ist nicht als „was ist besser“ zu lesen, sondern als was man abgibt und was man in der Hand behält.

Ausstiegsstrategie: Bekommt man die Quellen samt Historie heraus?

Ein ZIP exportieren kann man bei jedem Dienst. Das Problem ist die Historie. Bei Overleaf ist das git clone, das ein ganzes Projekt samt Historie herunterzieht, eine Premium-Funktion und für ein kostenloses Konto nicht verfügbar. Cloud LaTeX bietet neben dem ZIP-Export eine Dropbox-Synchronisation, sodass eine aktuelle Kopie der Quellen stets auf der eigenen Platte liegen kann. Papeeria ist um Git herum gebaut, doch der Gratistarif reicht nur an öffentliche Repositorien. Die Faustregel, die daraus folgt, ist ein Satz: Wähle einen Dienst, aus dem du dich per git clone herausbewegen kannst. Was auch immer dem Server zustößt, Manuskript und Historie bleiben bei dir.

Dieser Ausgang ist zugleich der Eingang zu CI. Hält man ein Overleaf-Projekt mit einem GitHub-Repository synchron, kann jeder Push GitHub Actions anstoßen, das Dokument in einem frischen TeX Live zu setzen und außerhalb des Browsers zu prüfen, ob das PDF wirklich entsteht. Man behält den Komfort der Cloud, während eine Maschine kontrolliert, ob die Arbeit tatsächlich reproduzierbar ist – vor allem bei gemeinsam verfassten Aufsätzen wertvoll. Wie erwähnt sind die Git- und GitHub-Anbindungen jedoch Premium-Funktionen; mit einem kostenlosen Konto lässt sich das nicht bauen. Im Alltag verhindern die folgenden drei Festlegungen die meisten ernsten Unfälle.

• Zuerst den Eigentümer festlegen. Bei gemeinsamen Arbeiten gehört ein vom Labor oder Projekt verwaltetes Konto in die Eigentümerrolle, nicht das persönliche Konto einer Einzelperson.
• Die Umgebung in die README schreiben. Eine Zeile mit Dienst, Compiler und TeX-Live-Jahrgang ist genau das, was zum Nachbauen lokal oder im Container fehlt.
• Vor der Einreichung alles exportieren. PDF, Quell-ZIP, .bib und die Rohdaten hinter den Abbildungen in einen einzigen datierten Ordner legen.

Overleaf auf dem eigenen Server betreiben

Das ist der dritte Weg. Der Kern von Overleaf erscheint als overleaf/overleaf unter der AGPL v3 – das ist die Overleaf Community Edition (CE). Ein Labor oder ein Unternehmen kann damit sein eigenes Overleaf auf eigenem Server betreiben, völlig unabhängig vom kommerziellen overleaf.com. Der empfohlene Weg ist das offizielle Overleaf Toolkit: ein Docker-Compose-Stack, der die Overleaf-Anwendung zusammen mit MongoDB als Datenbank und Redis als Cache hochfährt. overleaf/toolkit von GitHub holen, initialisieren, starten – fertig ist ein Overleaf, das im eigenen Browser erreichbar ist. Steht es einmal, läuft es auch in einem Netz ganz ohne Internetverbindung.

# 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 Compose

Man gewinnt Kontrolle über die eigenen Daten und Unabhängigkeit von Dritten. Kein Manuskript verlässt die Server der eigenen Organisation, und weder Ausfälle noch Preiserhöhungen treffen einen. Der Preis ist der Betrieb selbst: Bereitstellung, Sicherungen, TeX-Live-Aktualisierungen und Sicherheit werden zur eigenen Aufgabe. Und es gibt eine weitere Einschränkung, die sich nicht wegdiskutieren lässt. Die freie Community Edition kennt keine „Sandboxed Compiles“, die den Satzlauf isolieren. Der LaTeX-Lauf eines Nutzers arbeitet mit denselben Rechten wie der Container und erreicht dessen Dateisystem und Netzwerk. Die README des Projekts sagt unmissverständlich, CE sei für Umgebungen gedacht, in denen alle Nutzenden vertrauenswürdig sind.

Wer den Dienst breiter öffnen will oder Isolation, Single Sign-on über LDAP oder SAML, Änderungsverfolgung und weitere Unternehmensfunktionen braucht, findet die kostenpflichtige Ausgabe Server Pro. Die praktische Regel: Für ein kleines, vertrauenswürdiges Labor genügt CE; bevor man eine ganze Hochschule anschließt, prüft man Server Pro. Und nicht vergessen: Mit der Entscheidung zum Eigenbetrieb ist der größte Vorzug der Cloud – nichts warten zu müssen – dahin. Der letzte der drei Wege ist der freieste und der aufwendigste.