von Robert Klikics 4 Min Lesezeit veröffentlicht 2. Oktober 2026
Wer seine Website in einem Git-Repository pflegt, will nicht nach jeder Änderung per FTP Dateien hochladen. Plesk bringt dafür eine Git-Anbindung mit: Das Panel holt den Code aus GitHub, GitLab oder Bitbucket und legt ihn im Webverzeichnis ab, auf Wunsch automatisch nach jedem Push. Dieser Ratgeber zeigt die Einrichtung Schritt für Schritt, inklusive Deploy-Key, Webhook und zusätzlichen Befehlen wie composer install.
Kurz gefasst
- Unter Websites & Domains → Git verbindest du ein Remote-Repository oder legst ein Repository auf dem Server an, in das du direkt pushst.
- Für private Repositories zeigt Plesk einen öffentlichen SSH-Schlüssel an, den du beim Git-Anbieter als Deploy-Key einträgst.
- Mit einem Webhook landet jeder Push automatisch auf der Website. Ohne Webhook stößt du die Bereitstellung per Klick an.
- Nach der Bereitstellung kann Plesk weitere Befehle ausführen, etwa Abhängigkeiten installieren oder Caches leeren.
Wie die Git-Anbindung in Plesk funktioniert
Plesk hält eine eigene Kopie des Repositorys außerhalb des Webverzeichnisses. Bei jeder Bereitstellung kopiert es den Stand eines Branches in das Zielverzeichnis, standardmäßig /httpdocs. Der Ordner .git landet dabei nicht im öffentlich erreichbaren Verzeichnis, Besucher kommen also nicht an die Versionsgeschichte.
Es gibt zwei Arten von Repositories:
- Remote-Repository: Der Code liegt bei GitHub, GitLab, Bitbucket oder einem eigenen Git-Server, Plesk holt ihn ab. Das ist der übliche Weg, wenn mehrere Personen am Code arbeiten.
- Lokales Repository: Plesk legt ein leeres Repository auf dem Server an, und du pushst direkt von deinem Rechner dorthin, per SSH.
Remote-Repository verbinden
- In Plesk unter Websites & Domains bei der gewünschten Domain auf Git klicken.
- Remote-Git-Hosting-Repository wählen und die URL eintragen. Für private Repositories nimmst du die SSH-Adresse, etwa
[email protected]:firma/website.git. - Bei einer SSH-Adresse zeigt Plesk einen öffentlichen SSH-Schlüssel an. Trage ihn beim Git-Anbieter als Deploy-Key für dieses Repository ein, bei GitHub unter Settings → Deploy keys. Lesezugriff genügt.
- Den Bereitstellungsmodus wählen (siehe unten) und das Zielverzeichnis prüfen.
- Speichern. Plesk klont das Repository und stellt beim automatischen Modus den Branch direkt bereit.
Ein eigener Deploy-Key pro Repository ist sicherer als ein persönlicher Zugang: Er gilt nur für dieses eine Repository und lässt sich beim Git-Anbieter jederzeit widerrufen.
Die drei Bereitstellungsmodi
| Modus | Was passiert | Geeignet für |
|---|---|---|
| Automatisch | Neue Commits auf dem gewählten Branch werden sofort ins Zielverzeichnis kopiert. | Staging-Umgebungen, kleine Projekte |
| Manuell | Plesk holt die Änderungen, du entscheidest per Klick auf Bereitstellen, wann sie live gehen. | Produktivseiten, bei denen jemand freigeben soll |
| Keine Bereitstellung | Plesk speichert nur das Repository, das Webverzeichnis bleibt unverändert. | Code, der nicht öffentlich erreichbar sein soll |
Automatisch nach jedem Push: der Webhook
Bei einem Remote-Repository erfährt Plesk nicht von selbst, dass es neue Commits gibt. Dafür zeigt Plesk in den Repository-Einstellungen eine Webhook-URL an. Trägst du sie bei GitHub unter Settings → Webhooks oder bei GitLab unter Settings → Webhooks ein, ruft der Git-Anbieter sie nach jedem Push auf. Plesk holt dann die Änderungen und stellt sie bereit, wenn der Modus auf „Automatisch“ steht. Ohne Webhook klickst du in Plesk auf Updates abrufen.
Zusätzliche Befehle nach der Bereitstellung
Viele Projekte brauchen nach dem Kopieren noch einen Schritt: Abhängigkeiten installieren, Assets bauen, Caches leeren. Dafür gibt es in den Repository-Einstellungen das Feld für zusätzliche Bereitstellungsaktionen. Die Befehle laufen nach jeder Bereitstellung im Zielverzeichnis. Zwei Beispiele:
# PHP-Projekt mit Composer composer install --no-dev --optimize-autoloader # Laravel nach dem Deployment php artisan migrate --force php artisan config:cache
Schlägt ein Befehl fehl, zeigt Plesk die Ausgabe im Protokoll der Bereitstellung. Halte die Befehle schlank, denn sie laufen bei jedem Push. Composer lässt sich in Plesk auch über die Oberfläche bedienen, unter Websites & Domains → PHP Composer.
Tipps für typische Projekte
- Laravel und andere Frameworks mit
public-Ordner: Stelle in den Hosting-Einstellungen der Domain den Dokumentenstamm aufhttpdocs/public, damit nur dieser Ordner öffentlich erreichbar ist. - Zugangsdaten nicht ins Repository: Dateien wie
.envoderwp-config.phpmit Passwörtern gehören in.gitignore. Lege sie einmal per Datei-Manager oder SFTP auf dem Server an und prüfe nach der ersten Bereitstellung, ob sie noch da sind. - WordPress: Versioniere nur, was du selbst entwickelst, also Theme und eigene Plugins, und stelle nur diese Ordner bereit, etwa nach
httpdocs/wp-content/themes/mein-theme. Den WordPress-Kern und Uploads verwaltest du weiter über WordPress. - Erst testen: Hänge den Branch
developautomatisch an eine Staging-Umgebung und den Branchmainmanuell an die Produktivseite.
Wenn etwas nicht klappt
- „Permission denied (publickey)“: Der Deploy-Key fehlt beim Git-Anbieter oder wurde beim falschen Repository eingetragen.
- Push kommt nicht an: Prüfe beim Git-Anbieter die Zustellungen des Webhooks. Dort steht, ob der Aufruf fehlgeschlagen ist.
- Dateien fehlen auf der Website: Zielverzeichnis und Branch in den Repository-Einstellungen kontrollieren.
Bei turbopress
Git-Deployment ist im Webhosting und im WordPress-Hosting enthalten, ebenso SSH-Zugang, Composer und die freie Wahl der PHP-Version. Einen Überblick über das Panel gibt Was ist Plesk?, die Arbeit auf der Kommandozeile zeigt WP-CLI Grundlagen. Baust du deine Website mit Claude oder ChatGPT, geht es mit AI Launch auch ohne eigenes Git-Setup.
