--- title: "Veröffentlichte Versionen und Deploy-Hooks | Briks" url: https://briks.dev/de/docs/publish-history description: "Veröffentlichte Versionen ansehen, wiederherstellen, Deploy-Hooks anlegen: private Adressen, die Ihre Website neu veröffentlichen, wenn ein Tool sie aufruft." last_updated: 2026-10-08 --- # Veröffentlichte Versionen und Deploy-Hooks Jede Veröffentlichung Ihrer Website wird als nummerierte Version aufbewahrt, und der Bereich **Versions** in den **Settings** des Projekts listet sie auf. Mit **Deploy hooks** in denselben Settings kann ein anderes Tool Briks bitten, Ihre Website erneut zu veröffentlichen. Diese Seite behandelt beides. 7 Minuten Lesezeit Am 8. Oktober 2026 mit dem Studio abgeglichen ## Die Liste der veröffentlichten Versionen Wo 1. Projects 2. Your project 3. Settings 4. Versions Der Bereich listet die letzten 100 Versionen auf, die neueste zuerst. Jede Zeile zeigt: - **Version** und ihre Nummer, mit einem grünen Tag **Live** bei der Version, die Besucher gerade sehen. - Wie es dazu kam: **Built**, **Changed**, **Checked and repaired** oder **Published again**, und wer es angefordert hat. - Datum und Uhrzeit der Veröffentlichung, etwa 8. Okt. 2026, 14:32. - Eine kurze Zusammenfassung. Bei einer Änderung sind es die Worte, mit denen Sie gefragt haben. Bei einem Aufbau oder einer neuen Veröffentlichung ist es das, was Briks getan hat. - Sobald eine Version eine Woche live ist, folgt eine Zeile dazu, ob sie geholfen hat (siehe unten). | Label | Was die Version erstellt hat | | --- | --- | | **Built** | Ein erster Aufbau oder ein neues Projekt, kopiert aus einer Vorlage oder einem anderen Projekt | | **Changed** | Eine Änderung, um die Sie gebeten haben, Code, den Sie im File Explorer gespeichert haben, oder ein Bild, das Sie aus der Medienbibliothek getauscht haben | | **Checked and repaired** | Eine Website-Prüfung, die etwas Gefundenes behoben hat | | **Published again** | Ein Wechsel in die Produktion oder zurück zur Vorschau, **Apply to the live site**, eine neue Adresse, eine Domain, die live geht, oder ein Deploy-Hook. Die Zusammenfassung nennt, was es war, etwa „Published again with the site's settings.“ | Alle Aufträge des Projekts, auch solche, die nichts veröffentlicht haben, finden Sie unter [Protokolle](https://briks.dev/de/docs/logs). ### Hat die Änderung geholfen? Sobald eine Version 7 Tage live ist, erhält ihre Zeile eine Zeile, die für die Seiten, die die Version geändert hat, die Besuche davor mit den Besuchen seither vergleicht, jeweils als Wochendurchschnitt über bis zu 14 Tage auf jeder Seite. Sie lautet zum Beispiel: „Since version 12 (Add a prices section), enquiries from /prices went from 3 to 5 a week, on similar visits.“ Hatten diese Seiten weniger als 25 Besucher pro Woche, steht dort, dass es zu wenige Besuche gab, um etwas zu sagen. Eine Änderung, die ein Agent vorgenommen hat, wird als dessen Änderung genannt. Die Zeile wird aus Ihrer eigenen [Analytics](https://briks.dev/de/docs/analytics) ohne KI berechnet und kostet nichts. Versionen, die nur erneut veröffentlicht wurden, und der erste Aufbau erhalten keine Zeile. Die letzten 12 Versionen werden gelesen, und eine Auswertung ist endgültig, wenn 14 Tage vergangen sind. ### Eine Version wiederherstellen 1. Die Version finden Wo: Settings, Versions Jede Zeile außer der Live-Version hat einen Button **Restore**, sofern Ihre Rolle das Projekt bearbeiten darf. 2. Wiederherstellen Wo: Restore version Klicken Sie auf **Restore**. Der Dialog sagt „It goes back on the live site exactly as it was published. The versions after it stay saved, so you can come back.“ Klicken Sie auf **Restore version** und die Nummer. 3. Der Veröffentlichung zusehen Wo: Studio Briks führt Sie ins Studio, während veröffentlicht wird. Die Meldung lautet zum Beispiel: „Version 12 is live again, exactly as it was published.“ Das Label **Live** wechselt zu dieser Zeile. Eine Wiederherstellung nutzt keine KI. Owner, Admins und Editors können wiederherstellen; Viewers sehen die Liste. Während ein A/B-Test läuft, ist es nicht möglich. [Versionen, Rückgängig und Wiederholen](https://briks.dev/de/docs/versions) behandelt denselben Verlauf aus dem Studio heraus. ## Was ein Deploy-Hook ist Ein Deploy Hook ist eine private Webadresse, die Ihre Website erneut veröffentlicht, sobald sie aufgerufen wird. (Deployen heißt veröffentlichen.) Sie geben die Adresse an ein anderes Tool weiter, zum Beispiel einen Zeitplan-Dienst, und dieses Tool ruft sie auf, wenn es eine frische Veröffentlichung auslösen will. Ein Aufruf veröffentlicht die Live-Version erneut aus ihren eigenen Dateien, mit den Einstellungen des Projekts, wie sie gerade sind. Es läuft keine KI, es wird nichts berechnet, und es ändert sich nichts, was Sie nicht schon geändert haben. Die Seiten Ihrer Website werden beim Veröffentlichen zusammengesetzt, nicht bei jedem Besuch. Eine neue Veröffentlichung übernimmt also: - die zuletzt veröffentlichten Datensätze aus der Datenbank der Website, für alle Seiten, die daraus aufgebaut sind; - Einstellungen, die Sie seit der letzten Veröffentlichung geändert haben, etwa Logo, Favicon oder Sucheinstellungen; - alles, was eine Seite in dem Moment berechnet, in dem sie zusammengesetzt wird. Sie ändert nichts, was Sie beschreiben, liest keine Daten aus dem aufrufenden Tool und führt die Startprüfung nicht aus. Wann Sie keine brauchen Änderungen, die Sie im Studio anfordern, werden von selbst veröffentlicht. Das gilt auch für Bearbeitungen im Tab **Database**: Die Website wird direkt nach einer Bearbeitung erneut veröffentlicht, danach höchstens einmal alle fünf Minuten, egal wie viele Bearbeitungen Sie vornehmen. Ein Deploy-Hook ist für Veröffentlichungen gedacht, die außerhalb des Studios starten. ## Deploy-Hook erstellen 1. Deploy hooks öffnen Wo: Settings, Deploy hooks Öffnen Sie Ihr Projekt, klicken Sie auf den Tab **Settings** und dann in der Gruppe **Developer** auf **Deploy hooks**. 2. Eines hinzufügen Wo: Add a deploy hook Drücken Sie **Add deploy hook**. Benennen Sie ihn nach dem, was ihn aufrufen wird, zum Beispiel `Nightly scheduler`, und drücken Sie **Make hook**. 3. Adresse kopieren Wo: Your deploy hook Briks zeigt die Adresse nur einmal an. Klicken Sie auf **Copy** und fügen Sie sie direkt in das Tool ein, das sie aufrufen wird. Briks speichert keine lesbare Kopie, daher können Sie sie später nicht erneut ansehen. 4. Abschließen Wo: Your deploy hook Drücken Sie **Done**. Der Hook erscheint in der Liste mit dem Erstellungsdatum und „never called“. Hooks funktionieren, sobald das Projekt veröffentlicht wurde; bis dahin weist der Bereich darauf hin. Owners, Admins und Editors können Hooks anlegen und löschen. Privat halten Wie der Dialog warnt, kann jeder mit der Adresse Ihr Projekt erneut veröffentlichen. Bewahren Sie sie dort auf, wo nur Ihre Tools sie lesen können. Wenn sie durchsickert, löschen Sie den Hook und erstellen Sie einen neuen. ## Einen Hook aufrufen Das Werkzeug muss eine POST-Anfrage an die Adresse senden (eine Art Webanfrage, die etwas auslöst, statt nur eine Seite zu lesen). Die meisten Automatisierungs- und Planungswerkzeuge haben dafür eine Einstellung. Der Dialog zeigt, wie ein Aufruf aus einem Terminal aussieht: `curl -X POST https://app.briks.dev/api/hooks/bdh_…`, mit Ihrer vollständigen Adresse anstelle der gekürzten. | Wenn der Aufruf eintrifft | Was passiert | | --- | --- | | Die Website ist fertig | Eine Veröffentlichung startet und erscheint im Studio wie jede andere. | | Ein Build oder eine Veröffentlichung läuft bereits | Der Aufruf wird angenommen und mit dem laufenden zusammengeführt, sodass mehrere Aufrufe in kurzer Zeit nur einmal veröffentlichen. | | Der Hook wurde in der letzten Stunde sechsmal aufgerufen | Abgelehnt: „Dieser Hook wurde in der letzten Stunde sechsmal aufgerufen. Versuchen Sie es später erneut.“ | | Das Projekt wurde noch nie veröffentlicht | Abgelehnt: „Das Projekt wurde noch nicht veröffentlicht.“ | | Ein A/B-Test läuft | Abgelehnt: „An A/B test is running on this site. End it by keeping one version first.“ | | Weder die Person, die den Hook erstellt hat, noch die, die das Projekt erstellt hat, hat noch ein Briks-Konto | Abgelehnt: „This hook has no owner left. Make a new one in the project's Deploy hooks.“ | | Der Hook wurde gelöscht | Die Adresse funktioniert nicht mehr. | Jeder Aufruf aktualisiert die Zeit „zuletzt aufgerufen“ in der Zeile des Hooks, so sehen Sie, dass Ihr Tool funktioniert. Einen Scheduler außerhalb von Briks verwenden Die **Scheduled tasks** des Projekts können keinen Deploy Hook aufrufen, weil sie Adressen auf briks.dev ablehnen. Um nach Zeitplan zu veröffentlichen, nutzen Sie einen Planungsdienst, den Sie schon haben. ## Ein durchgespieltes Beispiel Beispiel Eine nächtliche Veröffentlichung für einen Laufclub > Die Website des Northside Running Club listet kommende Läufe aus Datensätzen in ihrer Datenbank. Die Organisatorin fragte im Studio, ob die Laufseite beim Veröffentlichen etwas aus dem Datum berechnet. Die Antwort war ja: Sie wählt die Läufe, die in diesem Moment noch anstehen. Also legte sie einen Hook namens `Nightly scheduler` an und stellte den Zeitplan-Dienst, den sie schon für Vereins-E-Mails nutzte, so ein, dass er jede Nacht um 03:00 einen POST dorthin sendet. Jeden Morgen beginnt die Rennseite mit dem Stand dieses Tages. Die Zeile des Hooks zeigt, wann er zuletzt aufgerufen wurde, und unter **Versions** kommt jede Nacht eine Zeile mit der Zusammenfassung „Published again with the site's settings.“ hinzu. Bedenken Sie, dass jede Veröffentlichung eine Version hinzufügt: Ein nächtlicher Hook fügt **Versions** also etwa dreißig Zeilen im Monat hinzu, und die Liste zeigt die neuesten 100. Wenn Sie nicht sicher sind, ob eine Seite vom Datum abhängt, fragen Sie zuerst im Studio nach (siehe [Fragen stellen](https://briks.dev/de/docs/asking-questions)); Fragen werden ohne Build beantwortet. ## Deploy-Hooks und Webhooks | | Deploy hook | Webhook | | --- | --- | --- | | Richtung | Ein anderes Tool ruft Briks auf | Briks ruft ein anderes Tool auf | | Was es tut | Veröffentlicht Ihre Website erneut | Teilt dem Tool mit, dass etwas passiert ist | | Wann | Immer wenn er aufgerufen wird | Bei site.published, form.received oder record.changed | | Wo | **Settings**, **Deploy hooks** | **Settings**, **Webhooks** | Sie arbeiten gut zusammen. Ein Webhook auf site.published kann ein anderes Tool jedes Mal benachrichtigen, wenn eine Veröffentlichung abgeschlossen ist, auch eine, die ein Deploy-Hook gestartet hat (siehe [Webhooks](https://briks.dev/de/docs/webhooks)). ## Einen Hook löschen Klicken Sie in der Zeile des Hooks auf **Delete**. Die Bestätigung lautet „Its address stops working at once.“ Klicken Sie erneut auf **Delete**. Tools, die ihn noch aufrufen, lösen keine Veröffentlichung mehr aus, entfernen Sie die Adresse also auch dort. ## Als Nächstes lesen - [An einem Projekt arbeiten **Versionen, Rückgängig und Wiederholen** Jeder Build und jede Änderung ist eine Version. Rückgängig, wiederholen oder jede frühere Version unverändert live setzen, ohne reservierte Credits.](https://briks.dev/de/docs/versions) - [Daten und Automatisierung **Webhooks** Signierte Nachricht an ein Tool bei Veröffentlichung, Formularversand oder Datensatzänderung. Payloads, Signaturen, Wiederholungen und Zustellungen erklärt.](https://briks.dev/de/docs/webhooks) - [Daten und Automatisierung **Geplante Aufgaben** Geplante Aufgaben auf Ihrer Website zu festen Zeiten: Morgenübersicht, wöchentliches Aufräumen. Zeitplan schreiben, Läufe lesen, Fehler beheben, Plan-Limits.](https://briks.dev/de/docs/crons) - [Daten und Automatisierung **Logs** Build-Protokoll und Anfragen des letzten Tages lesen, nach Level oder Status filtern, ein defektes Formular, einen defekten Job, eine langsame Seite finden.](https://briks.dev/de/docs/logs) Noch nicht weitergekommen? Schreiben Sie an [hello@briks.dev](mailto:hello@briks.dev) mit dem Namen Ihres Projekts und dem, was Sie erwartet haben. Ein Screenshot hilft.