Push. Ogschaut. Dann live.

GitHub-Deployment für DACH-Teams: Jeder Push wird zu einer prüfbaren Preview, und das exakt freigegebene Image geht in Production.

Für Production-Releases gebaut
Deployment starten Workflow verstehen
  • Org-Zugriff
  • Webhook-Signatur
  • Exakte Messung

bergwerk/kundenportal

Produktansicht · Beispieldaten

Preview · PR #184

Release für feature/customer-export

a81fc2d · Verschlüsseltes Exportarchiv hinzufügen

Preview bereit
  1. 1

    GitHub-Ereignis verifiziert

    Repository und Commit sind an die Installation gebunden

    Empfangen
  2. 2

    Deployment eingereiht

    Preview-Variablen und Release-Reihenfolge stehen fest

    Erfasst
  3. 3

    Artefakt gebaut

    Unveränderliches Image für diesen Release gespeichert

    Bereit
  4. 4

    Preview veröffentlicht

    kundenportal-pr-184.preview.ogschaut.de

    Öffnen

Beispieldaten, echter Produktpfad: signiertes GitHub-Ereignis, isolierter Build, unveränderliches Image und geroutete Preview.

Eine Release-Historie vom Push bis Production

Die Preview ist kein Wegwerf-Nebenpfad. Sie ist derselbe geordnete Release – mit demselben Artefakt und klaren Umgebungsgrenzen.

  1. 1

    Repository verbinden

    Installieren Sie die GitHub-App nur für Repositories, die diese Organisation deployen darf.

  2. 2

    Release anlegen

    Ein signierter Push oder Pull Request wird zu einem geordneten Deployment mit klar abgegrenzten Variablen.

  3. 3

    Preview anschauen

    Status, URL und Logs erscheinen im Pull Request – genau dort, wo die Prüfung bereits stattfindet.

  4. 4

    Ohne neuen Build promoten

    Production erhält das geprüfte, unveränderliche Artefakt; ein Rollback verwendet einen bekannten Release erneut.

Eine Plattformgrenze vom Quellcode bis zur Runtime

Die Control Plane prüft die Absicht, BuildKit erzeugt ein unveränderliches Artefakt und die Runtime veröffentlicht es erst nach erfolgreicher Readiness-Prüfung.

GitHub rein, geordnetes Release raus

Der Repository-Zugriff ist auf die Installation begrenzt. Signierte Push- und Pull-Request-Ereignisse erstellen mandantenbezogene, monotone Deployments.

Isolierte BuildKit-Builds

Kurzlebige Quellcode-Zugangsdaten und Build-Variablen bleiben an der Build-Grenze. Das Ergebnis ist immer ein inhaltsadressierter Image-Digest.

Readiness vor Traffic

Preview-Routen bleiben unabhängig. Production wechselt erst, wenn der neue Workload bereit ist; das vorherige Image bleibt für ein Rollback verfügbar.

So funktioniert GitHub-Deployment Die Vercel-Alternative vergleichen

Tarife passend zu den durchgesetzten Limits

Wählen Sie nach Teamgröße und tatsächlicher monatlicher Nutzung. Jeder Tarif nennt seine Build-, Runtime- und Aufbewahrungslimits vor dem Checkout.

Pro

Für Einzelentwickler, die echte Projekte ausliefern.

€29,00 / Monat

Tarif wählen

€24,16 / Monat (jährlich bezahlt)

Tarif wählen
  • 10 Projekte
  • 3 Teammitglieder
  • 1.000 Build-Minuten pro Monat
  • 500 Runtime-GB-Stunden pro Monat
  • 7 Tage Log-Aufbewahrung

Team

Beliebteste ✨

Für Teams, die jeden Tag gemeinsam deployen.

€99,00 / Monat

Tarif wählen

€82,50 / Monat (jährlich bezahlt)

Tarif wählen
  • 50 Projekte
  • 10 Teammitglieder
  • 5.000 Build-Minuten pro Monat
  • 3 gleichzeitige Builds
  • 30 Tage Log-Aufbewahrung

Business

Für Organisationen, die Produktions-Workloads im großen Maßstab betreiben.

€299,00 / Monat

Tarif wählen

€249,16 / Monat (jährlich bezahlt)

Tarif wählen
  • 200 Projekte
  • 25 Teammitglieder
  • 20.000 Build-Minuten pro Monat
  • 10 gleichzeitige Builds
  • 90 Tage Log-Aufbewahrung

Was Teams vor dem Verbinden eines Repositorys fragen

Kurze Antworten zum GitHub-Deployment- und Runtime-Pfad.

Was passiert nach einem GitHub-Push? Ein signiertes Ereignis erstellt ein geordnetes Deployment. Ein isolierter BuildKit-Worker checkt den exakten Commit aus, pusht einen unveränderlichen Image-Digest und veröffentlicht eine Preview, sobald der Workload bereit ist.
Warum sind Builds und Runtime getrennt? Die Build-Grenze erhält den Quellcodezugriff und erzeugt ein unveränderliches Artefakt. Die Runtime erhält nur dieses Artefakt und Umgebungswerte – niemals das Repository-Token.
Welche Projekte kann ich deployen? Das erste Release unterstützt GitHub-Repositories mit Dockerfiles, Node- und Next.js-Anwendungen sowie Static-Builds. Nuxt-, SvelteKit- und Astro-Projekte funktionieren, wenn ihr Production-Startbefehl auf Port 8080 bereitstellt.
Wie funktioniert ein Rollback? Ein Rollback veröffentlicht einen zuvor gespeicherten Image-Digest mit einer neuen Production-Sequenz. Der Traffic wechselt erst nach erfolgreicher Readiness-Prüfung, ohne den Quellcode neu zu bauen.
Was bedeutet ogschaut? Das ist Fränkisch für ‚angeschaut‘: der Preview-Moment, bevor ein freigegebenes Artefakt zu Production wird.

Bereit, den nächsten Release anzuschauen?

Verbinden Sie GitHub und bringen Sie das erste Projekt vom Push bis Production.

Organisation erstellen