Kostenlose CI-Minuten: was sie abdecken und was nicht

Was kostenlose Minuten abdecken

GitHub stellt jedem Konto ein monatliches Kontingent an Actions-Minuten für private Repositories bereit. Mit Stand September 2026 nennt GitHubs Abrechnungsdokumentation:

• GitHub Free: 2.000 Minuten pro Monat
• GitHub Pro und GitHub Team: 3.000 Minuten pro Monat
• GitHub Enterprise Cloud: 50.000 Minuten pro Monat

Standardmäßige GitHub-gehostete Runner sind in öffentlichen Repositories kostenlos. Die enthaltenen Minuten werden zu Beginn jedes Abrechnungszyklus zurückgesetzt. Einige Details bestimmen, wie weit sie reichen:

• GitHub rundet die Minuten jedes Jobs auf die nächste volle Minute auf.
• Enthaltene Minuten können nicht für GitHubs größere Runner genutzt werden.
• Oberhalb des Kontingents kostet ein Standard-Linux-Runner mit 2 Kernen $0.006 pro Minute (Windows und macOS kosten pro Minute mehr).

Für Rechenleistung ist das ein großzügiges Angebot. Für viele Teams ist es auch das richtige, und das sagen wir unten ausdrücklich.

Wie weit 2.000 Minuten reichen

1. GitHub rundet jeden Job von 2 Minuten 20 Sekunden auf 3 Minuten auf, ein Lauf wird also mit 4 × 3 = 12 Minuten abgerechnet.
2. 2.000 ÷ 12 = 166,7, das Free-Kontingent deckt also 166 vollständige Läufe pro Monat ab.
3. 166 ÷ 21 sind etwa 7,9 Läufe pro Arbeitstag, für das gesamte Team.
4. Jeder Lauf über dem Kontingent kostet 12 × $0.006 = $0.072.

Zum Vergleich wird derselbe Lauf auf CRACI sekundengenau abgerechnet: 4 × 140 Sekunden = 560 Sekunden, also etwa 9,33 Minuten. Auf einem Runner mit 2 vCPU zu $0.004 pro Minute kostet ein Lauf etwa $0.037, und die 166 Läufe, die das GitHub-Free-Kontingent abdeckt, kosten etwa $6.20. CRACI hat keinen kostenlosen Plan und keine Monatsgebühr: Sie zahlen pro Build-Minute. Aktuelle Zahlen finden Sie auf der Preisseite.

Kostenlose Minuten können gar nichts kosten, CRACI kann das nicht. Die bessere Frage ist, was jede Option Ihnen über die Rechenleistung hinaus gibt.

Was kostenlose Minuten nicht abdecken

Minuten kaufen Zeit auf einer Maschine. Sie sollten nie die Fragen beantworten, die aufkommen, wenn Sie Software an Kunden ausliefern:

• Welche Pakete hat dieser Build tatsächlich heruntergeladen, und woher?
• Hätte eine kompromittierte Abhängigkeit während des Builds einen unerwarteten Host erreichen können?
• Ist das ausgelieferte Artefakt dasjenige, das dieser Build erzeugt hat?
• Wenn eine neue Schwachstelle veröffentlicht wird: Welche unserer veröffentlichten Builds enthalten sie?
• Welche Nachweise können wir einem Kunden oder Auditor vorlegen?

Sicherheit

GitHub bietet kostenlose Lieferkettenfunktionen, die neben Actions arbeiten und sich zu aktivieren lohnen. Dependabot-Warnungen scannen den Default-Branch Ihres Repositorys und benachrichtigen Sie, wenn der GitHub Advisory Database eine neue Schwachstelle hinzugefügt wird. Außerdem können Sie den aktuellen Stand des Abhängigkeitsgraphen eines Repositorys als SBOM im SPDX-Format exportieren.

Diese Funktionen beschreiben das Repository. CRACI zeichnet den Build auf. Seine Runner beobachten während des Jobs den Datenverkehr zu Paketquellen. Die SBOM listet daher, was der Job tatsächlich geladen hat, einschließlich aus CI-Caches wiederhergestellter Pakete, und gibt an, ob die Aufzeichnung für jeden Job und Cache vollständig ist. Netzwerk-Egress-Richtlinien können alles außer den von Ihnen zugelassenen Softwarequellen sperren. Details stehen auf der Seite zur SBOM-Generierung.

Resilienz

Wenn eine neue CVE auftaucht, ist die nützliche Antwort nicht, ob Ihr Repository das Paket heute deklariert, sondern welche ausgelieferten Builds es enthalten. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu. So finden Sie die Builds, die eine verwundbare Abhängigkeit teilen. Siehe Schwachstellenverfolgung.

Compliance-Nachweise

Kunden und Regulierungsbehörden verlangen immer häufiger SBOMs und Belege dafür, wie Software gebaut wurde. Die CRACI-API liefert SBOMs, Netzwerk-Traces und Provenienz, und SBOMs lassen sich als CycloneDX oder SPDX exportieren. CRACI automatisiert einen erheblichen Teil der Transparenz über die Software-Lieferkette und der Nachweise, die Unternehmen für ihren übergreifenden CRA-Compliance-Prozess brauchen. Allein macht es ein Unternehmen nicht konform.

Wann kostenlose Minuten wirklich genügen

Bleiben Sie bei kostenlosen Minuten und aktivieren Sie GitHubs kostenlose Sicherheitsfunktionen, wenn das meiste hiervon zutrifft:

• Ihr Code ist Open Source in öffentlichen Repositories, wo standardmäßige gehostete Runner kostenlos sind.
• Sie bauen Prototypen, und nichts davon hat bisher Kunden erreicht.
• Ihre Builds passen bequem in das monatliche Kontingent.
• Kein Kunde, Auditor und keine Regulierungsbehörde verlangt SBOMs oder Build-Nachweise von Ihnen.
• Sie verkaufen keine Produkte mit digitalen Elementen auf dem EU-Markt.

In dieser Situation bezahlen Sie bei CRACI für Nachweise, die noch niemand braucht. Kommen Sie wieder, wenn sich das ändert.

Anzeichen, dass es Zeit ist, über kostenlose Minuten hinauszugehen

• Ein Sicherheitsfragebogen eines Kunden verlangt eine SBOM des ausgelieferten Releases.
• Sie verkaufen in der EU. Die Pflichten des Cyber Resilience Act zur Meldung von Schwachstellen gelten ab September 2026, die vollständige Anwendung folgt im Dezember 2027. Unser CRA-Überblick erklärt die Grundlagen.
• Nach einem Vorfall fragen Sie sich, welche Builds ein Paket geladen haben, und niemand kann es schnell beantworten.
• Sie überschreiten jeden Monat das kostenlose Kontingent und zahlen bereits für Minuten.

Ein Mittelweg für Startups

Berechtigte Startups erhalten über das Startup-Programm mindestens 100.000 kostenlose Build-Minuten und ein persönliches Onboarding durch unser Team. So sehen Sie an Ihrer eigenen Pipeline, wie Nachweise aus dem Build aussehen, bevor Sie dafür zahlen.