> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/de/wartung/upgrading-your-deployment.md).
# Ihr Deployment aktualisieren
{% hint style="danger" %}
Es ist wichtig sicherzustellen, dass Sie ein [konsistentes Backup](/on-premises/de/wartung/data-and-backups.md#performing-a-consistent-backup) **bevor** bei jedem Upgrade auf eine Hauptversion erstellen, damit Sie bei Bedarf zurückrollen können.
{% endhint %}
Das [Overleaf Toolkit↗](https://github.com/overleaf/toolkit) ist ein Git-Repository, sodass es einfach ist, neue Toolkit-Funktionen zu erhalten. Führen Sie einfach den `bin/upgrade` Befehl aus und folgen Sie den Anweisungen auf dem Bildschirm.
Es ist erwähnenswert, dass die Version des Docker-Images (unter `config/version`) wird getrennt von den Aktualisierungen des Toolkit-Codes verwaltet. Das Aktualisieren des Toolkit-Codes wird **nicht** automatisch die Version des Docker-Images ändern, das Sie ausführen. Das bedeutet, dass Sie in den meisten Fällen Ihre Toolkit-Version aktualisieren können, ohne Ihre Bereitstellung zu aktualisieren.
#### Das `bin/upgrade` Skript
Wenn Sie den `bin/upgrade` Befehl ausführen, prüft das Skript, ob ein verfügbares Update für den Toolkit-Code vorhanden ist, und bietet an, Ihr Toolkit zu aktualisieren. Sie können dieses Upgrade jederzeit ablehnen, und es wird sich nichts ändern.
Wenn Sie sich dafür entscheiden, den Toolkit-Code zu aktualisieren, prüft das Skript anschließend, ob die *Standard* Docker-Image-Version geändert hat, und bietet an, Ihre lokale Versionsdatei (unter `config/version`) zu aktualisieren, damit sie dem neuen Standard entspricht.
Wenn Sie sich dafür entscheiden, Versionen zu wechseln, führt Sie das Skript dann durch einen Prozess, bei dem die Docker-Dienste heruntergefahren, ein Backup erstellt und die Docker-Dienste neu gestartet werden. Ihre alte Versionsdatei wird automatisch nach `config/__old-version`, falls Sie zu dieser Version der Docker-Images zurückkehren müssen.
{% hint style="danger" %}
Bei einem Upgrade von Server CE/Pro empfehlen wir, zunächst auf die neueste Veröffentlichung der eingesetzten Hauptversion zu aktualisieren **bevor** auf die neueste Veröffentlichung der **nächsten** Hauptversion zu aktualisieren. Wenn Ihre Bereitstellung mehr als eine Hauptversion hinter der neuesten zurückliegt, müssen Sie ein mehrstufiges Upgrade durchführen.
Wenn Sie beispielsweise 3.5.10 verwenden, müssen Sie auf 3.5.13 aktualisieren -> die Full-Project-History-Migration durchführen -> 4.2.9 -> 5.5.4.
Sie sollten **niemals** Hauptversionen überspringen (3.5.10 -> 5.5.4). Wenn Sie das Toolkit verwenden und mehr als eine Hauptversion hinter der neuesten zurückliegen, müssen Sie **nicht** das `bin/upgrade` Skript verwenden, da Sie ein manuelles mehrstufiges Upgrade durchführen müssen.
{% endhint %}
{% hint style="info" %}
Für air-gapped Setups, die Docker-Images manuell importieren, setzen Sie bitte `PULL_BEFORE_UPGRADE=false` in Ihrer `config/overleaf.rc` Datei.
Bitte prüfen Sie [hier](/on-premises/de/installation/air-gapped-offline-deployments.md) für weitere Informationen zur Bereitstellung in air-gapped-/Offline-Umgebungen.
{% endhint %}
### Upgrade-Pfad
Das `bin/upgrade` Befehl wählt immer die zu diesem Zeitpunkt neueste verfügbare Version von Server Pro/CE aus. Wenn Ihre Upgrade-Zyklen selten sind, kann dies dazu führen, dass Hauptversionen übersprungen werden und Sie möglicherweise auf eine Version aktualisieren, die Sie nicht erwartet hätten.
Bei der Durchführung eines Upgrades empfehlen wir, zunächst auf die neueste Veröffentlichung der aktuellen Hauptversion zu aktualisieren, bevor Sie auf die neueste Veröffentlichung der nächsten Hauptversion aktualisieren. Wenn Sie beispielsweise derzeit 3.3.2 verwenden und die neueste verfügbare Version 5.3.1 ist, wäre der richtige Upgrade-Pfad:
* 3.3.2 -> 3.5.13
* 3.5.13 -> 4.2.9
* 4.2.9 -> 5.5.1
Um Probleme beim Upgrade zu vermeiden, empfehlen wir, unsere [Versionshinweise](https://docs.overleaf.com/on-premises/release-notes) vor der Durchführung von Upgrades zu konsultieren, da bestimmte Versionen zusätzliche Schritte erfordern können, wie z. B. manuelle Änderungen am Toolkit, das Upgrade von Datenbanken oder das Ausführen von Migrationsskripten.
Falls Sie dies noch nicht getan haben, melden Sie sich für unsere [Mailingliste](https://mailchi.mp/overleaf.com/community-edition-and-server-pro) an, damit Sie benachrichtigt werden, wenn neue Versionen/Updates veröffentlicht werden. So können Sie regelmäßige Wartungsfenster planen, die eng an unserem Veröffentlichungsplan ausgerichtet sind.
---
# 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://ayakaleaf-pro.ayaka.space/on-premises/de/wartung/upgrading-your-deployment.md?ask=&goal=
```
`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.