Git Deploy

Der Tab Git Deploy im Portal verbindet deinen Server mit einem Git-Repository auf GitHub, GitLab, Gitea oder Forgejo. Dessen Dateien landen automatisch auf deinem Server — bei jedem Push, wenn du ein Release veröffentlichst, wenn du einen Tag pushst oder per Knopfdruck. Auf Wunsch wird dein Server vor dem Deploy sauber gestoppt und danach wieder gestartet.

Kurz gesagt: Code pushen, und ein paar Sekunden später läuft er auf deinem Server. Kein Hochladen per SFTP mehr, kein Entpacken von ZIP-Dateien in der Dateiverwaltung, kein vergessener Neustart.

Das lernst du hier

• Wie du ein Repository verbindest, mit der GitHub-App Daki Git Deploy oder mit einem Zugriffstoken
• Wann ein Deploy läuft und wie du selbst einen auslöst
• Wie du Welten, Datenbanken und .env-Dateien mit geschützten Pfaden absicherst
• Wie Neustart, Deploy-Verlauf, Rollback und der Status in deinem Repository funktionieren
• Wie du deinem Team die passenden Rechte gibst

Für wen es gedacht ist

• Entwickler von Discord-Bots sowie Node.js-, Python- oder Java-Anwendungen, deren Code ohnehin auf GitHub oder GitLab liegt.
• Minecraft-Netzwerke und Gameserver-Teams, die Plugins, Configs oder Datapacks in einem Repository pflegen und Änderungen nachvollziehbar ausrollen wollen.
• Teams: Mehrere Leute arbeiten im Repository, der Server ist immer auf dem neuesten Stand, und über Subuser-Rechte legst du genau fest, wer deployen darf.
• Release-basierte Projekte: Nur veröffentlichte Versionen (z. B. eine fertige .jar aus dem Release) landen auf dem Server, nicht jeder Zwischenstand.

Bevor du loslegst

• Einen Server im Portal, der den Tab Git Deploy zeigt. Er steht in der Server-Navigation unter Essentials, standardmäßig direkt nach Files.
• Ein Repository auf GitHub (github.com), GitLab (gitlab.com oder eine eigene Instanz, auch Untergruppen wie gruppe/untergruppe/projekt), Gitea oder Forgejo (z. B. Codeberg oder eine eigene Instanz). Öffentliche und private Repositories funktionieren beide.

Schnellstart mit GitHub (empfohlen)

Der schnellste Weg: Verbinde dich über Daki Git Deploy, die offizielle GitHub-App von Daki Hosting. Du meldest dich bei GitHub an und wählst deine Repositories aus — kein Token und kein Webhook nötig.

1. 1

   Öffne den Tab Git Deploy

   Öffne deinen Server im Portal und wechsle in den Tab Git Deploy. Wähle unter Git service den Dienst GitHub.

2. 2

   Mit GitHub verbinden

   Klicke im Kasten GitHub access auf Connect with GitHub. Melde dich bei GitHub an und autorisiere die App.

   Beim ersten Mal geht es danach direkt weiter zur Auswahl, auf welche Repositories die App zugreifen darf (All repositories oder nur ausgewählte) — ein Durchgang statt zwei. Anschließend landest du automatisch wieder im Portal, und der Kasten GitHub access zeigt Connected via Daki Git Deploy as mit deinem GitHub-Namen. Der Kasten Webhook bestätigt, dass nichts einzurichten ist: Pushes und Releases kommen über die App von selbst an.

3. 3

   Wähle Repository und Branch

   Klicke auf Choose from my repositories und wähle dein Repository — oder füge die Web- oder Clone-URL ein bzw. tippe den Pfad. Klicke auf Load branches und wähle den Branch, der deployt werden soll. Lässt du den Branch leer, wird der Standard-Branch des Repositorys verwendet.

4. 4

   Lege fest, wann und wie deployt wird

   Wähle unter When to deploy einen Modus (z. B. Every push). Stelle danach Zielordner, geschützte Pfade und das Neustart-Verhalten ein.

5. 5

   Speichern

   Klicke unten in der Leiste auf Save settings. Fertig: Oben im Tab steht Automatic deploys on, und dein nächster Push wird automatisch deployt. Willst du sofort deployen, klicke oben rechts auf Deploy now.

• Weiteres Repository freigeben: Choose repositories on GitHub öffnet die Repository-Auswahl auf GitHub erneut. Dort legst du fest, auf welche Repositories Daki Git Deploy zugreifen darf.
• Verbindung lösen: Klicke auf Disconnect. Danach deployt der Server nicht mehr aus privaten Repositories.

Schnellstart mit Zugriffstoken

Für GitLab, Gitea und Forgejo — und auf Wunsch auch für GitHub — hinterlegst du einen persönlichen Zugriffstoken. Öffentliche Repositories funktionieren sogar ganz ohne Token.

1. 1

   Wähle den Git-Dienst

   Öffne deinen Server → Git Deploy und wähle unter Git service deinen Dienst. Bei einer eigenen GitLab-Instanz, Gitea oder Forgejo trägst du die Server-Adresse ein (z. B. https://codeberg.org oder https://git.example.com). Bei gitlab.com lässt du sie leer.

2. 2

   Trage das Repository ein

   Trage das Repository als Pfad (besitzer/name) ein oder füge einfach die Web- oder Clone-URL ein. Bei einem öffentlichen Repository reicht das schon — ohne Token zeigt der Zugangs-Kasten No token – public repositories only.

3. 3

   Hinterlege einen Token für private Repositories

   Bei GitHub klickst du dafür zuerst im Kasten GitHub access auf Use an own access token instead. Erstelle dann bei deinem Git-Dienst einen Token — der Link Create a token on … im Portal führt dich direkt zur richtigen Seite — und speichere ihn unter Personal access token. Das Portal prüft den Token sofort. Welche Rechte er braucht, steht unter Token-Rechte.

4. 4

   Einstellungen wählen und speichern

   Lege fest, wann deployt wird, und wähle Zielordner, geschützte Pfade und das Neustart-Verhalten. Klicke dann auf Save settings.

5. 5

   Webhook anlegen

   Im Kasten Webhook stehen Payload URL und Secret, jeweils mit Kopieren-Knopf. Trage beides in deinem Repository ein, wie unter Webhook einrichten beschrieben. Unter dem Kasten zeigt Last delivery danach, ob der Webhook ankommt.

6. 6

   Automatische Deploys einschalten

   Schalte Automatic deploys active ein.

Token-Rechte

Fehlt nur das Schreibrecht für den Status, wird trotzdem deployt — im Deploy-Log steht dann ein Hinweis.

Webhook einrichten

Wann ein Deploy läuft

Unter When to deploy wählst du einen von vier Modi:

Auslöser

• Webhook: Dein Git-Dienst meldet Änderungen sofort, der Deploy startet innerhalb von Sekunden. Mit der GitHub-App passiert das automatisch, ohne eigenen Webhook.
• Update-Prüfung (Polling): optional, für Fälle, in denen dein Git-Dienst das Portal nicht erreichen kann. Intervalle von 5 Minuten bis 1 Tag.
• Deploy now: jederzeit per Knopf. Im Release-Modus kannst du ein bestimmtes Release auswählen.
• Push überspringen: Steht [skip deploy] in der Commit-Nachricht, wird dieser Push nicht deployt. [deploy skip] und [no deploy] funktionieren auch.

Auf CI-Checks warten

Ist Wait for CI checks eingeschaltet (nur im Modus Every push), wird ein Commit erst deployt, wenn seine CI grün ist — unterstützt werden GitHub Actions, GitLab CI und Gitea/Forgejo Actions. Schlägt die CI fehl, wird der Deploy übersprungen.

Alle Einstellungen erklärt

Änderungen werden erst wirksam, wenn du auf Save settings klickst. Solange etwas ungespeichert ist, zeigt eine Leiste unten Discard und Save settings, und Deploy now ist gesperrt.

Remove files that were deleted from the repository entfernt nur Dateien, die ein früherer Deploy selbst geschrieben hat — nie geschützte Pfade und nie Dateien, die du selbst angelegt hast. Leere Ordner bleiben stehen.

Geschützte Pfade

Dateien und Ordner unter Protected paths werden von einem Deploy nie überschrieben oder gelöscht. Gibt es sie noch nicht, werden sie einmal angelegt. Perfekt für Spielwelten, Datenbanken und Passwörter.

Schreibe eine Regel pro Zeile, relativ zum Zielordner. Leere Zeilen und Zeilen mit # am Anfang werden ignoriert. * passt nie über ein / hinweg.

Typische Beispiele:

world/
world_nether/
world_the_end/
plugins/*/config.yml
whitelist.json
ops.json
banned-*.json

.env
*.db
*.sqlite
node_modules/
data/

.env
*.db
venv/

Neustart-Verhalten

If the server does not stop: Manche Programme, vor allem Node.js-Anwendungen, ignorieren das Stopp-Signal. Der Server wird dann nach der gewählten Zeit beendet („gekillt“) — sofort oder nach 5 Sekunden bis 5 Minuten, standardmäßig Kill after 10 seconds —, damit der Deploy nicht hängen bleibt. Sofort beenden ist am schnellsten, lässt dem Server aber keine Zeit zum Speichern.

Was bei einem Deploy passiert

1. Ein Auslöser (Push, Release, Tag, Update-Prüfung oder Knopf) erzeugt einen Deploy.
2. Ist Wait for CI checks eingeschaltet, wartet er auf grüne CI-Checks (Waiting).
3. Das Portal lädt das Archiv von deinem Git-Dienst. Deine Zugangsdaten verlassen dabei nie das Portal und landen nie auf deinem Server.
4. Das Archiv wird vorbereitet: nur der gewählte Ordner, geschützte Pfade herausgefiltert, unsichere Inhalte wie symbolische Links verworfen.
5. Je nach Einstellung wird der Server gestoppt (und notfalls nach der gewählten Zeit beendet).
6. Die Dateien werden in den Zielordner geschrieben; optional werden gelöschte Dateien entfernt.
7. Je nach Einstellung wird der Server wieder gestartet.
8. Ergebnis und vollständiges Log erscheinen im Verlauf — und, wenn eingeschaltet, als Status am Commit.

Ein Deploy dauert typischerweise 10–40 Sekunden, plus die Zeit, die dein Server zum Stoppen braucht.

Verlauf, Logs und Rollback

Die Liste Deployments unten im Tab zeigt jeden Deploy mit Status, Branch und Commit (z. B. main @ 75cd0a1), Nummer, Auslöser, der Person, die ihn gestartet hat, der Uhrzeit und der Commit-Nachricht. Oben im Tab siehst du, wann der Server zuletzt deployt wurde.

• Log: Jeder Deploy hat ein Live-Log, das sich während des Deploys aktualisiert. Hide log blendet es wieder aus.
• Rollback mit einem Klick: Klicke bei einem früheren Deploy auf Deploy again, um diesen Stand noch einmal auszurollen.
• Abbrechen: Wartende oder eingeplante Deploys kannst du abbrechen.

Mehrere Server können gleichzeitig deployen, pro Server läuft aber immer nur ein Deploy. Ein neuer Auslöser ersetzt einen älteren Deploy, der noch wartet.

Status in deinem Repository

Ist Show deploys in the repository eingeschaltet, erscheint an deinem Commit der Status Daki Hosting / dein Servername: gelb während des Deploys, danach ein grüner Haken oder ein rotes Kreuz, mit Link zum Tab Git Deploy.

• Auf GitHub erscheint der Deploy zusätzlich unter Deployments, mit deinem Servernamen als Umgebung.
• Mit der GitHub-App schreibt Daki Git Deploy den Status und zeigt sein Logo — sonst ist nichts einzurichten. Mit Token erscheint das Bild des Token-Kontos, und der Token braucht Schreibrechte (siehe Token-Rechte).
• Du kannst es pro Server abschalten. Öffentlich sichtbar sind nur Status und Link — keine Logs und keine Fehlerdetails.

Teams und Subuser-Rechte

Subuser bekommen eine eigene Rechte-Gruppe Git Deploy:

Subuser haben standardmäßig keinen Zugriff auf Git Deploy — du entscheidest, wer welches Recht bekommt. Der Besitzer des Servers darf immer alles.

Sicherheit

• Tokens und Secrets werden verschlüsselt gespeichert und nie an deinen Browser geschickt.
• Mit der GitHub-App gibt es für Deploys gar keinen dauerhaften Token von dir: Jeder Deploy nutzt einen kurzlebigen Schlüssel (1 Stunde), der nur das Repository deines Servers erreicht.
• Welche Repositories du verbinden kannst, entscheidet dein eigener GitHub-Zugang. Niemand kann fremde Repositories auf seinen Server ziehen.
• Webhooks sind signiert, mit einem eigenen Secret pro Server. Zustellungen mit falschem Secret oder für ein anderes Repository werden abgewiesen.
• Nur wer den Token hinterlegt hat, kann das Repository wechseln. So können Subuser nicht mit dem Token des Besitzers andere private Repositories laden.
• Änderst du Git-Dienst oder Server-Adresse, wird der gespeicherte Token beim Speichern automatisch gelöscht.
• Geschützte Pfade werden nie überschrieben, und Remove files that were deleted from the repository löscht nur, was Git Deploy selbst geschrieben hat.
• Der öffentliche Status in deinem Repository enthält keine Logs und keine Fehlerdetails.

Bekannte Grenzen

• Pro Server ein Repository und ein Zugang.
• Pro Server läuft immer nur ein Deploy gleichzeitig.
• Der Status in deinem Repository erscheint erst, wenn der Deploy wirklich startet, nicht schon beim Warten auf die CI.
• Release-Dateien werden nur entpackt, wenn es .zip-Dateien sind; eine .tar.gz wird als Datei hochgeladen.
• Leere Ordner bleiben nach Remove files that were deleted from the repository stehen.
• Symbolische Links im Repository werden nicht deployt.
• GitLab kennt keine Pre-Releases; ein Release mit Datum in der Zukunft gilt als Pre-Release.
• GitLab: Release-Dateien, die als Upload im Projekt liegen (/uploads/…), lassen sich bei privaten Projekten nicht mit einem Token laden; Links auf die Package Registry funktionieren.
• Connect with GitHub gibt es nur für GitHub; GitLab, Gitea und Forgejo nutzen einen Token.

FAQ und Fehlersuche

Nächste Schritte

• Subuser — Gib deinem Team Zugriff und lege fest, wer deployen darf.
• Umgebungsvariablen — Halte Tokens und Passwörter aus deinem Repository heraus.
• Startup-Einstellungen — Lege den Startbefehl fest, mit dem dein deployter Code läuft.
• Backups — Speichere automatische Backups deines Servers in Google Drive.