Brauche ich eine OAuth-App oder einen bestimmten Anbieter?

Nein. Ein Deploy-Ziel ist am Ende eine URL, die Zuuna mit deinen Headern und deinem Body aufruft — GitHub-Workflow, GitLab-Pipeline, Jenkins-Job, n8n-Flow oder dein eigenes Skript.

Wird eine Freigabe ungültig, wenn noch Commits dazukommen?

Ja. Die Freigabe ist an den Commit-Stand gepinnt, den sie freigegeben hat. Kommt danach etwas dazu, gilt sie nicht mehr — freigegeben wurde ein bestimmter Stand, nicht die Idee des Releases.

Kann ich am Gate vorbei?

Nur mit Freigaberecht, einer schriftlichen Begründung und einem Audit-Eintrag. Break-Glass ist für den Produktions-Notfall gedacht, nicht für den Alltag — und es hinterlässt sichtbare Spuren.

Wie viele Ziele kann ich anlegen?

Eines pro Umgebung und Gruppe — Staging und Produktion sind also zwei Ziele mit getrennten Credentials und getrennten Gates.

Deploy-Ziel und Freigabe einrichten

Deployen heißt in vielen Teams: das richtige Skript finden, den richtigen Branch, die richtige Person mit den richtigen Rechten. In Zuuna heißt es: Knopf am Release — mit einem Freigabe-Gate davor, wenn ihr eines wollt. Deploy-Ziele gehören zum Developer-Plan.

Was du brauchst

Den Developer-Plan — siehe Preise.
Ein Release, das an einen Git-Tag gebunden ist.
Eine Pipeline, die sich per HTTP anstoßen lässt — praktisch jede.

1. Voraussetzungen prüfen

Das Deploy-Ziel hängt an der Gruppe, der Deploy-Knopf am Release. Ohne getaggtes Release gibt es nichts zu deployen.

2. Deploy-Ziel anlegen

Ein Ziel ist eine URL plus das, was deine Pipeline erwartet: GitHub-Workflow-Dispatch, GitLab-Pipeline-Trigger, Jenkins-Job, n8n-Webhook — oder ein einfacher Webhook mit deinen Headern und deinem Body. Das Credential wird verschlüsselt gespeichert und nie wieder angezeigt.

3. Verstehen, warum das Credential an der URL hängt

Eine Eigenheit mit Absicht: Wer die URL ändert, verliert das Credential. Sonst könnte jemand mit Schreibrecht die URL still auf einen eigenen Server drehen und das hinterlegte Secret dorthin umleiten. URL neu, Credential neu — der kleine Mehraufwand ist der Schutz.

4. Freigabe-Modus wählen

Drei Stufen, ehrlich benannt:

Kein Gate — der Knopf deployt sofort. Für Staging meist richtig.
Protokollieren — Freigaben werden erfasst, aber nichts blockiert. Die Einführungsstufe.
Hart blockieren — ohne Freigabe kein Deploy. Für Produktion.

Dazu die Entscheidung, ob Selbstfreigabe erlaubt ist — ob also dieselbe Person anstoßen und freigeben darf. Vier-Augen-Prinzip heißt: nein.

5. Aus Zuuna deployen

Am Release: Deploy klicken, die ausgeschriebene Version lesen, zur Bestätigung tippen. Das Tippen ist kein Ritual — es verhindert den Muskel-Klick auf das falsche Release.

6. Status im Board mitlesen

Die Pipeline meldet ihren Fortschritt zurück, und das Release zeigt ihn: queued → building → deploying → live, bei einem Gate auch waiting, im Fehlerfall failed. Wer wissen will, ob v2026.08.1 draußen ist, schaut aufs Release — nicht in drei CI-Tabs.

7. Break-Glass kennen

Für den Ernstfall gibt es den Weg am Gate vorbei — aber er ist bewusst unbequem: Freigaberecht nötig, schriftliche Begründung Pflicht, Audit-Eintrag garantiert. Und eine Grenze, die das Feature selbst offen ausspricht: Das Gate bewacht Zuunas Knopf, nicht deine Pipeline. Wer direkt in der CI deployen kann, wird hier nicht aufgehalten — Branch Protection bleibt deine Aufgabe.

Wenn es nicht klappt

Der Deploy startet nicht. Credential prüfen — und ob die URL seit dem Anlegen geändert wurde (dann ist das Credential weg, siehe oben).
„Freigabe erforderlich." Das Gate steht auf hart. Freigeben lassen — oder begründet Break-Glass.
Die Freigabe ist plötzlich weg. Nach der Freigabe kamen Commits dazu; sie war an den alten Stand gepinnt. Neu freigeben.
Status bleibt auf queued. Die Pipeline meldet nicht zurück — der Rückkanal (deployments:write) fehlt im Pipeline-Token.

Nächste Schritte

Den Code-Graph lesen — was wirklich live ging.
Ein Release an einen Git-Tag binden.
Projektmanagement für Entwickler.