> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/de/konfiguration/overleaf-toolkit/sandboxed-compiles.md).

# Sandboxed Compiles

Overleaf Pro bietet die Option, Kompiliervorgänge in einer abgesicherten Sandbox-Umgebung für Unternehmenssicherheit auszuführen. Dazu wird jedes Projekt in seiner eigenen abgesicherten Docker-Umgebung ausgeführt.

### Verbesserte Sicherheit

Sandboxed Compiles sind für Server Pro die empfohlene Vorgehensweise, da viele LaTeX-Dokumente als Teil des PDF-Kompilierungsprozesses Shell-Befehle beliebiger Art ausführen müssen bzw. dazu in der Lage sein müssen. Wenn Sie Sandboxed Compiles verwenden, läuft jeder Kompiliervorgang in einem separaten Docker-Container mit eingeschränkten Möglichkeiten, die nicht mit anderen Benutzern oder Projekten geteilt werden, und er hat keinen Zugriff auf externe Ressourcen wie das Host-Netzwerk.

{% hint style="warning" %}
Wenn Sie versuchen, Overleaf Pro auszuführen **ohne** Sandboxed Compiles ausgeführt, läuft der Kompiliervorgang zusammen mit anderen gleichzeitig laufenden Kompiliervorgängen im Haupt-Docker-Container, und Benutzer haben vollen Lese- und Schreibzugriff auf die `sharelatex` Container-Ressourcen (Dateisystem, Netzwerk und Umgebungsvariablen) beim Ausführen von LaTeX-Kompilierungen.
{% endhint %}

### Einfachere Paketverwaltung

Um das manuelle Installieren von Paketen zu vermeiden, empfehlen wir, Sandboxed Compiles zu aktivieren. Dies ist eine konfigurierbare Einstellung in Server Pro, die Ihren Benutzern Zugriff auf dieselbe TeX-Live-Umgebung wie auf overleaf.com bietet, jedoch innerhalb Ihrer eigenen On-Premise-Installation. Die von Sandboxed Compiles verwendeten TeX-Live-Images enthalten die beliebtesten Pakete und Schriftarten, die gegen unsere Galerievorlagen getestet wurden, und gewährleisten so maximale Kompatibilität mit On-Premise-Projekten.

Durch das Aktivieren von Sandboxed Compiles können Sie konfigurieren, aus welchen TeX-Live-Versionen Benutzer innerhalb ihres Projekts wählen können, und außerdem eine standardmäßige TeX-Live-Image-Version für neue Projekte festlegen.

{% hint style="info" %}
Wenn Sie versuchen, Overleaf Pro ohne Sandboxed Compiles auszuführen, verwendet Ihre Instanz standardmäßig für Kompiliervorgänge eine Basis-Scheme-Version von TeX Live. Diese Basisversion ist leichtgewichtig und enthält nur eine sehr begrenzte Teilmenge an LaTeX-Paketen, was bei Ihren Benutzern höchstwahrscheinlich zu Fehlern wegen fehlender Pakete führt, insbesondere wenn sie versuchen, vorgefertigte Vorlagen zu verwenden.
{% endhint %}

Da Overleaf Pro so konzipiert wurde, dass es offline funktioniert, gibt es keine automatisierte Möglichkeit, Vorlagen aus der overleaf.com-Galerie in Ihre On-Premise-Installation zu integrieren; dies ist jedoch manuell für jede Vorlage möglich. Weitere Informationen darüber, wie das funktioniert, finden Sie in unserer Anleitung zum Übertragen von Vorlagen von overleaf.com: [/pages/c8e0340ccef774c2cef246249bad022d8970b489#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/de/konfiguration/overleaf-toolkit/pages/c8e0340ccef774c2cef246249bad022d8970b489#transferring-templates-from-overleaf.com "mention").

{% hint style="info" %}
Sandboxed Compiles erfordert, dass der `sharelatex` Container Zugriff auf den Docker-Socket auf dem Host-Rechner hat (über ein Bind-Mount), damit er diese benachbarten Kompilierungs-Container verwalten kann.
{% endhint %}

## So funktioniert es

Wenn Sandboxed Compiles aktiviert sind, wird der Docker-Socket vom Host-Rechner in den `sharelatex` Container eingebunden, sodass der Compiler-Dienst im Container neue Docker-Container auf dem Host erstellen kann. Dann führt der LaTeX-Compiler-Dienst (CLSI) bei jedem Lauf des Compilers in jedem Projekt Folgendes aus:

* Schreibe die Projektdateien an einen Speicherort innerhalb des `OVERLEAF_DATA_PATH`.
* Verwende den eingebundenen Docker-Socket, um einen neuen `texlive` Container für den Kompiliervorgang zu erstellen.
* Lasse den `texlive` Container die Projektdaten vom Speicherort unter `OVERLEAF_DATA_PATH`.
* Kompiliere das Projekt innerhalb des `texlive` -Container.

### Aktivieren von Sandboxed Compiles&#xD;

#### Für Toolkit-Benutzer

Um sandboxed compiles (auch als Sibling-Container bekannt) zu aktivieren, setzen Sie die folgenden Konfigurationsoptionen in `overleaf-toolkit/config/overleaf.rc`:

{% code title="config/overleaf.rc" %}

```dotenv
SERVER_PRO=true
SIBLING_CONTAINERS_ENABLED=true
```

{% endcode %}

#### Für Docker-Compose-Benutzer <a href="#docker-compose-example" id="docker-compose-example"></a>

{% hint style="danger" %}
Beginnend mit Overleaf CE/Server Pro `5.0.3` wurden die Umgebungsvariablen umbenannt von `SHARELATEX_*` auf `OVERLEAF_*`.
{% endhint %}

Wenn Sie eine `4.x` Version (oder früher) stellen Sie bitte sicher, dass die Variablen entsprechend mit einem Präfix versehen sind (z. B. `SHARELATEX_MONGO_URL` anstatt `OVERLEAF_MONGO_URL`).

<pre class="language-yml"><code class="lang-yml">version: '2'
services:
    sharelatex:
        #...
        Volumes:
            - /data/overleaf_data:/var/lib/overleaf
<strong>            - /var/run/docker.sock:/var/run/docker.sock
</strong>        Umgebung:
            #...
<strong>            DOCKER_RUNNER: "true"
</strong><strong>            SANDBOXED_COMPILES: "true"
</strong><strong>            SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"
</strong>            #...
        #...
</code></pre>

### Ändern des TexLive-Images

{% hint style="info" %}
Für Benutzer auf dem chinesischen Festland können Sie `ghcr.nju.edu.cn` verwenden, um Ihren Download zu beschleunigen.&#x20;
{% endhint %}

Overleaf Pro verwendet drei Umgebungsvariablen, um festzulegen, welche TeX-Live-Images für Sandboxed Compiles verwendet werden sollen:

* `TEX_LIVE_DOCKER_IMAGE` **(erforderlich),** Das standardmäßige TeX-Live-Image, das zum Kompilieren neuer Projekte verwendet wird. Dieses Image muss enthalten sein in `ALL_TEX_LIVE_DOCKER_IMAGES`.
* `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(erforderlich),** Eine durch Kommas getrennte Liste lesbarer Namen für die Images, die für Frontend-Optionen verwendet wird.
* `ALL_TEX_LIVE_DOCKER_IMAGES` **(erforderlich),** Eine durch Kommas getrennte Liste von TeX-Live-Images, die verwendet werden sollen. Wenn das Overleaf Toolkit für die Bereitstellung verwendet wird, werden diese Images heruntergeladen oder aktualisiert. Um das Herunterladen zu überspringen, setzen Sie `SIBLING_CONTAINERS_PULL=false` in `config/overleaf.rc`.

Wenn Sie Ihre Overleaf-Pro-Instanz mit dem `bin/up` Befehl starten, zieht das Toolkit automatisch alle Images, die in `ALL_TEX_LIVE_DOCKER_IMAGES`.

Hier ist ein Beispiel, in dem wir für neue Projekte standardmäßig TeX Live 2025 verwenden und 2024 für bestehende Projekte beibehalten.

{% code title="config/variables.env" overflow="wrap" %}

```dotenv
ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2025.1, ghcr.io/ayaka-notes/texlive-full:2024.1
ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2025, Texlive 2024
TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2025.1
```

{% endcode %}

{% hint style="danger" %}
Es wird dringend empfohlen, **mindestens 2 texlive-full-Images**. Für eine ausführliche Begründung siehe [#known-issues](#known-issues "mention")
{% endhint %}

### Verfügbare TeX-Live-Images

Dies ist eine Reihe von TeX-Live-Images, die speziell für Overleaf optimiert sind und auch hinzugefügt werden können zu `TEX_LIVE_DOCKER_IMAGE` und `ALL_TEX_LIVE_DOCKER_IMAGES`:&#x20;

* `ghcr.io/ayaka-notes/texlive-full:2025.1` (Auch `latest` Tag)
* `ghcr.io/ayaka-notes/texlive-full:2024.1`
* `ghcr.io/ayaka-notes/texlive-full:2023.1`
* `ghcr.io/ayaka-notes/texlive-full:2022.1`
* `ghcr.io/ayaka-notes/texlive-full:2021.1`
* `ghcr.io/ayaka-notes/texlive-full:2020.1`

{% hint style="warning" %}
Es gibt ein striktes Schema dafür, wie Images **müssen** getaggt werden (der folgende reguläre Ausdruck gilt `^[0-9]+.[0-9]+`, wobei die erste Zahl das TeX-Live-Jahr und die zweite die Patch-Version bestimmt).
{% endhint %}

### Kann ich eine andere Image-Registry verwenden

> Manche Leute fragen sich vielleicht, ob ich `ghcr.io` durch eine andere Mirror-Site ersetzen oder Texlive durch ein anderes Image von Docker Hub austauschen kann?

Nein, wir empfehlen das nicht, da die Konfiguration relativ kompliziert ist. Wenn Sie von einer Mirror-Site herunterladen, können Sie Ihr Image umbenennen in `ghcr.io/ayaka-notes/texlive-full`.

Wenn Sie jedoch wirklich Ihre eigene Image-Registry verwenden möchten, fügen Sie bitte hinzu:

{% code title="config/variables.env" overflow="wrap" %}

```dotenv
IMAGE_ROOT=hub.your.com/your-repo
```

{% endcode %}

Dann müssen Sie sicherstellen, dass sich alle Texlive-Images in `your-repo`, zum Beispiel

* `hub.your.com/your-repo/texlive-full:2025.1`
* `hub.your.com/your-repo/texlive-full:2024.1`

Für detaillierte Informationen lesen Sie den Quellcode unten, um zu verstehen, wie wir Ihre Umgebungsvariable parsen:

{% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %}

```mjs
if (process.env.SANDBOXED_COMPILES === 'true') {
  // Setze das standardmäßige Image-Root, falls nicht angegeben
  let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes";
  // Exportiere imageRoot nach Settings
  Settings.imageRoot = imageRootPath

  // allowedImageNames sollte sein:
  // [
  //  { imageName: "texlive-2023:latest", imageDesc: "TeX Live 2023" },
  //  { imageName: "texlive-2022:latest", imageDesc: "TeX Live 2022" },
  // ]
  Settings.allowedImageNames = parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGES)
    .map((texImage, index) => ({
      imageName: texImage.split("/")[texImage.split("/").length - 1],
      imageDesc: parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGE_NAMES)[index]
        || texImage.split(':')[1],
    }))
  
  // Am Ende wird imageName mit imageRoot zusammengesetzt, um den vollständigen Image-Pfad zu bilden
  // Der vollständige Name sieht dann etwa so aus: ghcr.io/ayaka-notes/texlive-2023:latest

  // Setze den standardmäßigen Image-Namen, falls nicht angegeben
  if(!process.env.TEX_LIVE_DOCKER_IMAGE) {
    process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName
  }

  // Exportiere currentImageName nach Settings
  // Dies ist der Image-Name für neu erstellte Projekte
  Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE
}
```

{% endcode %}

### Bekannte Probleme

> Verwenden von `6.0.1-ext-v3.3`, ich habe diese Einstellungen in `variables.env`:
>
> ```dotenv
> TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full
> ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full
> ```
>
> Das funktioniert einwandfrei mit `texlive/texlive:latest-full`. Allerdings habe ich ein anderes texlive-Image heruntergeladen `danteev/texlive:2025-10-15` und beide dieser Variablen auf den neuen Image-Namen geändert, aber es funktioniert nicht:
>
> ```dotenv
> TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15
> ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15
> ```
>
> In den Logs sehe ich Folgendes:
>
> {% code overflow="wrap" %}
>
> ```
> {"name":"clsi","level":50,"err":{"message":"(HTTP code 404) no such container - No such image: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP code 404) no such container - No such image: texlive/texlive:latest-full ... 
> ```
>
> {% endcode %}
>
> Es scheint, dass die aktualisierten Einstellungen in `variables.env` nicht wirksam werden. Der Kompiliervorgang versucht weiterhin, das `texlive/texlive:latest-full` Image auszuführen, nicht das neue Image.
>
> Ich habe versucht, neu zu starten, die Container zu löschen und erneut auszuführen, aber das gleiche Problem besteht weiterhin.
>
> Gibt es Lösungen?

Aufgrund einiger technischer Einschränkungen gilt: Wenn Sie nur ein einziges Docker-TeXLive-Image einrichten, wie zum Beispiel `texlive-fullA:latest`&#x20;

```
ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full
ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA
TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full
```

Und nachdem Ihre Overleaf-Instanz eine Weile gelaufen ist, möchten Sie das TeXLive-Image möglicherweise ändern in `texlive-fullB:latest`. Dann werden Sie feststellen, dass Ihre Benutzer nicht alle Projekte kompilieren können.

```
ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full
ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA
TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full
```

Das liegt daran, dass der Name des TeXLive-Full-Images (für Sandboxed-Compiles) in jedem Projekt in der Datenbank gespeichert wird. *Nur wenn der Benutzer die TeXLive-Version seines Projekts wechselt, zum Beispiel von 2024 auf 2025, wird der Image-Name in der Datenbank geändert*.

Wenn CLSI ein Projekt kompiliert, verwendet es den in der Datenbank gefundenen Container-Image-Namen, um das Projekt direkt zu kompilieren.

Wenn Sie nur ein Docker-Image bereitstellen, können Benutzer das zum Kompilieren des Projekts verwendete Image nicht ändern. In diesem Fall müssen Sie ein Skript schreiben, um **manuell zu ändern** das TeXLive-Image für alle Benutzerprojekte in MongoDB.

### Debugging

Führen Sie den folgenden Befehl aus, um das CLSI-Log aus dem Toolkit zu prüfen:

{% code overflow="wrap" %}

```bash
bin/logs clsi
```

{% endcode %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/on-premises/de/konfiguration/overleaf-toolkit/sandboxed-compiles.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
