Von GitHub zu selbstgehostetem Forgejo

1. Übersicht

GitHub verursacht für unsere Entwicklung Frustration, hohe Kosten und Ausfälle.
Eine Analyse der “ehrlicheren Statusdaten” (Februar–April 2026) zeigt:
An unseren vier genutzten Diensten lag die kombinierte Verfügbarkeit bei nur 93,4 % – im Schnitt ~11 Stunden pro Woche mit mindestens einem beeinträchtigten Dienst.
Dem sei dazu gesagt, dass dies lediglich die von Microsoft “bestätigten” Werte sind.
Ähnlich dem deutschen Bahn Trick messe ich in meinen Daten seit Oktober 2025 eine durchschnittliche Verfügbarkeit von gerade einmal 83%.
Die vier gemessenen Dienste sind hierbei:

Github Actions
Git Operations
Pull Requests
Pages

Die Lösung zu diesen Problemen ist ein selbst gehostetes Forgejo auf einem eigenen Server im Haus.
Das beseitigt die Geschwindigkeits-, Rate-Limit- und Datenhoheits-Probleme an der Wurzel, schaltet fehlende Funktionen - wie etwa Fast-Forward-Merges oder ArtefaktHandling - frei und macht zB Stakeholder-Accounts für das Produktmanagement kostenlos.
Ich möchte an dieser Stelle verdeutlichen, dass der administrative Aufwand für diesen Quellcode und BuildServer nur ein Bruchteil des Aufwands ist, der von mir Gegenwärtig auf das Github System aufgebracht werden muss.
Der grösste Pain-Point sind gegenwärtig die Github Actions,
welche für uns gleichzeitig die wichtigste Komponente des ganzen Systems ist, und welche der Produktivität jedes einzelnen Entwcklers mehrmals pro Woche einen Dämpfer verpasst.
Aus diesem Grund ist die Folgende Entscheidungsfindung bedeutend von dieser Thematik geprägt.

Eine Auswertung unserer realen CI-Last unter WarpBuild ergibt einen gemessenen Spitzenbedarf von 104 vCPU und 416 GB RAM bei maximal 13 gleichzeitig laufenden (windows) Agents. Konsektutiv ergeben sich drei Server-Konstellationen als unsere Empfehlung:

Variante	Hardware	Kerne / RAM	Preis (indikativ)
★ Empfehlung: Vorkonfektionierter Silent-Tower	Thomas-Krenn TA1506, EPYC 9555P	64 C / 128 T · 768 GB	€ 50.758,00 €
Vorkonfektionierter Silent-Tower 2	Thomas-Krenn TA1506, EPYC 9555P	64 C / 128 T · 768 GB	€ 50.758,00 €
DIY lastgen	Leiser Eigenbau-Tower, 2× EPYC 7763	128 vCPU / 1 TB	~35.000 CHF
Refurbished	Refurbished Dell R6525 (1U), 2× EPYC 7763	128 vCPU / 1 TB	~CHF 25.000
Metal Host (Cloud)	zB cloudscale	128 vcpu + 512g	~7.000 CHF / Monat

Entscheidung: vorkonfektionierter Silent-Tower-Server (1× EPYC 9555P, 768 GB DDR5-6400). Ausschlaggebend war die Verfügbarkeit: fertig konfiguriert, gebaut, getestet und mit Business-Garantie in wenigen Tagen lieferbar – ohne Sourcing- oder Bauaufwand und ohne Kühlerproblem (keine 1U/2U SchubladenTurbine).
64 schnelle Zen-5-Kerne (128 Threads) decken die gemessene 104-vCPU-Spitze.
Die Wahl der vergleichsweise überproportionierten Arbeitsspeicher Kapazität liegt hier tatsächlich nicht an der gemessenen, benötigten Kapazität,
sondern der Anzahl der einzelnen Module um die für C# am wichtigsten benötigte Ressource zu liefern,
nämlich eine Maximierung der zur Verfügung stehenden Speicher-Bandbreite.
Zusätzlich erscheinen die Alternativen durch die geringe Preisdifferenz weniger Attraktiv.

Der Lastgen Tower wäre eine 30-40% Performance einbusse gegenüber der empfohlenen Variante.
Beim Dell R6525 gestaltet sich das Bild sehr ähnlich.
Zudem ist hier auch die Verfügbarkeit, Garantie und Zustand ein weiterer Punkt, den es zu betrachten gilt.
Ebenfalls haben diese 1U Server keine guten Modifikationsalternativen.
Hierdurch wären keine Fanmods möglich, wodurch diese “Turbine” enormen Larm und Hitze erzeugt.
Diese Server versperren den Zugang zu BIOS funktionen und besitzen lediglich 40mm Lüfter.
Dadurch befinden sich damit dort kleine, heulende Lüfter, die 24/7 auf 15.000 Umdrehungen pro Minute rotieren.

Die Cloudhosted alternative fungiert hier lediglich als Referenz und ist nicht als Vorschlag zu betrachten.
Der Preis ist hier angenähert, da solch grosse Server oft nur als Offerte eingeholt werden können.
Es besteht allerdings die Möglichkeit, einzelne Server für einzelne Runner anzumieten.

Github kostet uns gegenwärtig je nach Auslastung jährlich 50.000 USD - 55.000 USD.

2. Ausgangslage: Warum weg von GitHub? {#kap-2}

Schmerzpunkt	Auswirkung heute	Lösung mit selbst gehostetem Forgejo
Langsam	Latenz bei Clone, PR, UI – verstärkt durch USA-Anbindung	Server im eigenen Haus → LAN-Latenz statt Transatlantik
Ausfälle	Tägliche Ausfälle (nicht immmer gleich schwerwiegend)	99.9% uptime möglich
API-Rate-Limit	Automatisierungen/Bots werden gedrosselt	Eigene Instanz, Limits frei konfigurierbar
Keine kostenlosen Stakeholder-Accounts	PM zahlt pro Sitz oder hat keinen Zugang	Forgejo: unbegrenzte Nutzer kostenlos
Dediziertes Accountmanagement	Jeder Entwickler braucht einen eigenen Account	Forgejo: Oidc/Ldap -> EntraID Account
Fehlende Funktionen	z. B. Fast-Forward-Merge fehlt	In Forgejo nativ vorhanden (FF-only, Rebase, Squash)
USA-Bindung	Datenhoheit, rechtliche Abhängigkeit	Daten bleiben in der Schweiz, im eigenen Haus
Tägliche Störungen	~17 h/Woche Beeinträchtigung (s. Kap. 3)	Wir kontrollieren Verfügbarkeit und Wartung selbst
Verdeckte Kosten	Ausgelaufene Buildartefakte werden Berechnet und können nur aufwändig gelöscht werden	Keine (Open Source)
Kontakt	Github Mitarbeiter reagieren meist gar nicht	Open Source Code ermöglicht forks, Antworten aus dem Team bisher nach spät. 1 Tag
Leitung	Existiert seit Sommer 2025 nicht mehr.	Codeberg und mehrere direkte Teams, Antworten binnen Tagen auf Mails
Vertrauen	Hacks durch eigene Mitarbeiter, Leaks, etc.	CVEs klar kommuniziert. Keine kritischen Lücken in privaten Instanzen vorhanden

Ein sehr grosser Indikator für die Githubsche Dekadenz liegt in dem Fehlen eines Kopfes.
Github ist ein Schiff ohne Kapitän.
Das kann zB im Verge nachgelesen werden.
Der CEO Posten wurde wurde im Sommer 2025 von Thomas Dohmke auf und das Team wurde direkt dem CoreAI Team unterstellt.
Diesem fehlt die objektiv Betrachtet die Kompetenz, dieses Produkt zu führen.

3. Beleg: GitHub-Ausfälle Februar–April 2026 {#kap-3}

Die offizielle Statusseite (githubstatus.com) meldet reale Ausfälle seit geraumer Zeit nicht mehr verlässlich. Wir nutzen daher die ehrlichere, aus dem Atom-Feed rekonstruierte Historie (mrshu.github.io/github-statuses, Datenquelle: githubstatus.com/history.atom-Snapshots). Da Microsoft den Atom-Feed seit Mai 2026 nur noch unregelmässig aktualisiert, werten wir bewusst das saubere Fenster Februar bis April 2026 (89 Tage) aus.
Betrachtet man mit den Erkenntnissen aus Kap. 2 die Daten vor 2025,
so ergibt sich ein weit stabileres Bild von nur sehr wenigen, grösseren Ausfällen.
Generell herrscht hier im Schnitt eine Verfügbarkeit von >98%.
Hingegen im April 2026 erreichen wir einen gemessenen, zugegebenen Wert von 78,33%.
In meinen persönlichen Messungen - also eine Berechnung der Zeitfenster eines 8h Arbeitstages, in denen mindestens einer der vier verwendeten Dienste nicht Verfügbar ist - komme ich sogar lediglich auf 71%.

In den folgenden Abschnitten werden nur die offiziellen, von Microsoft herausgegebenen Ausfalldaten analysiert.
Dem sei jedoch vorangestellt, dass die Dunkelziffer hier weit höher ist.
Meine Datenerhebung ergibt sich aus der Analyse unsere Github Jobs für Actions,
Health Pings für unsere Pages und generelle Automatisierungen, die Aufgrund der Verfügbarkeit fehlschlagen und deshalb gelogged werden.
Gerade in den Git Operations komme ich im Monat Mai auf 84 Stunden, in denne git Operations so eingeschränkt nutzbar waren,
dass ein einfacher Branchwechsel über Github bis zu 12(!) Minuten dauert.

3.1 Unsere vier genutzten Dienste

Dienst	Vorfälle	davon major	davon critical	Ausfallzeit
Pull Requests	16	4	1	98,2 h
Actions	20	6	2	50,0 h
Git Operations	9	3	0	22,1 h
Pages	5	4	0	9,7 h

3.2 Kombinierte Sicht (das, was wir täglich spüren)

35 Vorfälle betrafen mindestens einen unserer vier Dienste.
140,9 h kombinierte Beeinträchtigung in 31 getrennten Zeitfenstern über 89 Tage.
⇒ Kombinierte Verfügbarkeit unserer Arbeitsfläche: 93,40 %.
⇒ Im Schnitt ~11,1 Stunden pro Woche mit mindestens einem gestörten Dienst.
Gesamtbild GitHub (alle Komponenten): 96 Vorfälle im Fenster (Feb 37 · Mär 32 · Apr 27).

93,4 % Verfügbarkeit entsprechen keinem marktüblichen SLA (üblich sind 99,9 %).

Methodik

Vorfälle nach started_at gefiltert
Wartungsfenster exkludiert
duration_minutes je Komponente aufsummiert;
Union über Zeitfenster mit Ausfällen, um Duplikate zu vermeiden

4. Was Forgejo konkret löst

Geschwindigkeit

Git-Operationen über das eigene LAN statt über den Atlantik.
Generell liefert Forgejo eine bessere Performance als Github.
Meine Private Instanz, die in etwas 350 Km Entfernung gehostet wird, und die Ich mit 20 anderen Entwicklern teile, liefert folgende Werte in der Statusleiste:

Powered by Forgejo
Version: 15.0.2
Page: 31ms
Template: 20ms

Die Actions haben im Schnitt eine Wartezeit von weniger als 2 Sekunden (Konfigurierbar!).
Im Vergleich hierzu warten Jobs in Github des Öfteren bis zu 30 Minuten,
bis diese Ausgeführt werden.

Hinzu kommen noch diverse, in Ops genutzte Automatisierungsskripte.
Diese haben mit der instabilen und langsamen github api zu kämpfen.

Dieses Skript benötigte hierbei 58 Sekunden für 336 parallelisierte(!) Abfragen.

~/coding/CMI 
at 13:10:55 ❯ /home/crashdummy/coding/CMI/cleanup-expired-artifacts.sh -y CMInformatik/cmi-metatool
Fetching artifacts for CMInformatik/cmi-metatool ...
Found 335 expired artifacts, 198.35 GB

Pruning 12 artifacts in parallel
  💣 300 ok, 0 fail 💣
✅: 335 deleted, 0 failed

~/coding/CMI took 58s 
at 13:11:53 ❯

Schattenkosten

Generell benötigt es stets enormen Aufwand, um herauszufinden, was hier tatsächlich die Kosten dieses SCM sind.
Auf die versteckten Kosten zB der Artefakte - auf das ich mit dem in Geschwindigkeit erwähnten Skript reagiere -
stösst man erst, wenn man versteht, wie github hier intern arbeitet.
Gemäss Dokumentation erzeugen diese Artefakte keine “weiteren” kosten.
Allerdings liegen diese - nicht mehr Nutzbaren - Artefakte auf Microsoft’s Cloud Speicher und verursachen Lagerkosten.
Es ist bezeichnend, dass Microsoft’s Scott Hanselman sogar einen Analyzer geschrieben hat,
um solche Kosten aufzudecken.

Ausfälle

Keine fremden Rate-Limits: API-Grenzen sind unsere eigene Konfiguration.
Kostenlose Stakeholder: Beliebig viele Lese-/Kommentar-Accounts fürs Produktmanagement.
Fast-Forward-Merge: Nativ unterstützt (FF-only, Rebase, Squash, Merge-Commit wählbar).
Datenhoheit: Code und Daten verlassen das Haus nicht – relevant für Schweizer Public-Sector-Software.
Verfügbarkeit in eigener Hand: Wartungsfenster und Updates planen wir selbst.
CI/CD: Forgejo Actions ist weitgehend GitHub-Actions-kompatibel (act_runner), Migration der Workflows mit überschaubarem Aufwand.

5. CI-Lastanalyse (Basis der Server-Dimensionierung)

5.1 Datengrundlage

Auswertung des CI-Abrechnungs-Logs ci-billing-2026-06-01.csv (2 207 Job-Läufe, Zeitraum 1.–31. Mai 2026, ~30 Tage). Das Log enthält pro Lauf Startzeitpunkt (timestamp), Laufzeit (execution_time) und Runner-Typ. Damit liessen sich die tatsächlich gleichzeitig laufenden Agents exakt per Timeline-Sweep messen – keine Schätzung.

Wichtige Erkenntnis: 100 % der gemessenen Last sind Windows-Runner (warp-windows-*). Der .NET-Framework-Stack erzwingt Windows. Linux-CI existiert, ist aber sehr klein (s. u.).

5.2 Runner-Typen (WarpBuild Cloud)

Runner-Label	vCPU	RAM	Läufe (Mai)
`warp-windows-latest-x64-2x`	2	7 GB	678
`warp-windows-latest-x64-8x`	8	32 GB	1 122
`warp-windows-latest-x64-16x`	16	64 GB	407

(„Nx” = Anzahl vCPU; 2x ist bei WarpBuild abgekündigt und fällt auf 4x/16 GB zurück.)

5.3 Maximal gleichzeitig laufende Agents (gemessen)

Kategorie	Läufe	Spitze gleichzeitig	Zeitpunkt
`…-8x` (8 vCPU)	1 122	13	19. Mai, 13:54
`…-2x` (2 vCPU)	678	4	21. Mai, 08:23
`…-16x` (16 vCPU)	407	3	19. Mai, 13:41
Gesamt (alle Typen)	2 207	13	19. Mai, 13:54

Nach Job-Art:

Job	Läufe	Peaks gleichzeitig
`ci-server / ci_build`	844	5
`Execute bdd tests / bdd-tests`	699	5
`integration-large-runner (CMIAXIOMARechte)`	332	4
`integration-large-runner (MEHRMANDANTEN_2)`	332	4

5.4 Ressourcen-Peaks (das, was der Server tragen muss)

Da ein 16x-Agent das Achtfache eines 2x-Agents an CPU braucht, zählt nicht die reine Anzahl, sondern die gewichtete Spitze:

Metrik	Gemessene Spitze	Zeitpunkt
Gleichzeitige Agents	13	19. Mai, 13:54
vCPU-Bedarf	104 vCPU	19. Mai, 13:54
RAM-Bedarf	416 GB	19. Mai, 13:54
Theoretisches Worst-Case (alle Kategorie-Spitzen gleichzeitig – nie beobachtet)	160 vCPU / 636 GB	–

Zur Spitze waren faktisch alle 13 gleichzeitigen Agents 8x-Runner (13 × 8 vCPU = 104, 13 × 32 GB = 416 GB).
Zudem ist der aktuell teilweise aktivierte 16x-Agent nur testweise aktiv und liefert einen marginalen Performanceboost.

Zweite Erkenntnis aus dem Job-Report: Die CPU-Auslastung war moderat (ci_build p75 67 %, Integration 18–45 %), der RAM lief jedoch heiss (92–96 %). ⇒ RAM ist die harte Grenze (nicht überbuchen), CPU hat Überbuchungs-Spielraum.

6. Server-Dimensionierung

6.1 Modell und Annahmen

Annahme	Wert	Begründung
Dimensionierungsziel	Reale Spitze + Reserve	Heutige Last soll nie in die Warteschlange laufen
CPU-Überbuchung	1,5 : 1 (vCPU : Kern)	Agents lasten selten alle Kerne gleichzeitig voll aus
RAM-Überbuchung	1 : 1 (keine)	RAM ist die harte Grenze (92–96 % gemessen)
Windows-Runner	KVM/QEMU, Warm-Pool + Burst	Firecracker kann kein Windows (s. Kap. 7)
Linux-Runner	Firecracker-microVMs	Sehr klein: ~6 vCPU / 40 GB Spitze

6.2 Ableitung des Grundbedarfs

Komponente	vCPU/Kerne	RAM
Windows-Runner (104 vCPU ÷ 1,5)	~70 Kerne	416 GB
Linux-Firecracker	~6 Kerne	40 GB
Zwischensumme Runner-Last	~76 Kerne	456 GB

6.3 Die drei Dimensionierungs-Stufen

Auf die Runner-Last kommt eine Reserve für Forgejo + Datenbank + einige Microservices + OS. Wir zeigen bewusst drei Stufen für die Argumentation:

Stufe	Zweck	+ Reserve	Total Kerne	Total RAM
A – „Was wir wirklich brauchen”	Heutiger Betrieb	8 C / 32 GB	~84 Kerne	~488 GB
B – „Für geplante Erweiterungen”	Mehr Microservices/Wachstum	12 C / 56 GB	~88 Kerne	~512 GB
C – „Sicherheitspuffer”	Grosszügig, sorgenfrei	24 C / 128 GB	~100 Kerne	~584 GB

Kernaussage fürs Management: Stufe A genügt heute. Stufe B deckt absehbare Erweiterungen, Stufe C ist reiner Komfortpuffer.

Hinweis zur Kernzahl: Die Tabelle ist ein bewusst konservatives 1,5:1-Modell (vCPU : Kern). Die gewählte Hardware (1× EPYC 9555P, 64 Kerne / 128 Threads) deckt die gemessene 104-vCPU-Spitze über SMT-Threads ab – bei der gemessenen, nur moderaten CPU-Auslastung genügen 64 schnelle Zen-5-Kerne. RAM (der eigentliche Engpass) ist mit 768 GB–1,15 TB grosszügig dimensioniert. Details s. Kap. 8.

7. Architektur {#kap-7}

┌──────────────────────────────────────────────────────────────┐
│  Bare-Metal-Server (Linux-Host, KVM)                          │
│                                                                │
│  ┌──────────────┐   ┌───────────────────────────────────┐    │
│  │ Forgejo +    │   │ Windows-Runner (KVM/QEMU)          │    │
│  │ DB +         │   │  • kleiner Warm-Pool (~8 VMs)       │    │
│  │ Microservices│   │  • Burst aus Golden-Snapshot        │    │
│  │              │   │  • Snapshot-Revert nach jedem Job   │    │
│  └──────────────┘   │  • Grössen 2x / 8x / 16x je Image   │    │
│                     └───────────────────────────────────┘    │
│  ┌───────────────────────────────────┐                       │
│  │ Linux-Runner (Firecracker microVM) │  ← klein, ephemer     │
│  └───────────────────────────────────┘                       │
└──────────────────────────────────────────────────────────────┘

7.1 Linux-Runner: Firecracker

Ephemere microVMs, sekundenschneller Start, saubere Umgebung pro Job. Bedarf heute minimal (~6 vCPU / 40 GB). Kapazität wird vorgehalten, aber nur klein reserviert.

7.2 Windows-Runner: KVM/QEMU – nicht Firecracker

Firecracker unterstützt kein Windows (minimaler VMM ohne ACPI/PCI-Gerätemodell, nur Linux-Gäste). Windows-Gäste laufen daher unter KVM/QEMU (oder Cloud Hypervisor) – das war die richtige Annahme.

Empfohlenes Betriebsmodell (Verfeinerung der ursprünglichen Idee):

Ursprüngliche Idee	Empfehlung	Warum
8–10 VMs dauerhaft an	Warm-Pool ~8 + Burst auf bis zu ~16	Spitze war 13 – 8–10 würde genau dann queuen
immer laufend, Zustand bleibt	Snapshot-Revert nach jedem Job	Sonst „dreckige” Builds (Cache/Registry-Reste) → nicht reproduzierbar
eine VM-Grösse	pro Grösse ein Golden-Image (2x/8x/16x)	Sonst RAM-Verschwendung oder zu kleine VMs für 64-GB-Integrationstests

So bleibt der Idle-Footprint klein (nur ~8 warme VMs), Bursts booten in ~30–60 s aus dem Golden-Snapshot, und jeder Build startet sauber – wie bei Cloud-Runnern. act_runner läuft dabei im ephemeral-Modus.

8. Server-Empfehlungen & Preise {#kap-8}

Beschafft wird gekaufte Hardware fürs eigene Haus (Capex), nicht gemietet. Firecracker und KVM brauchen ohnehin Bare-Metal (Zugriff auf /dev/kvm; geschachtelte Virtualisierung in normalen Cloud-VMs ist meist nicht verfügbar oder zu langsam). Nachfolgend sechs geprüfte Optionen (neu, refurbished, Eigenbau, vorkonfektioniert); gewählt ist Option 6 (vorkonfektionierter Silent-Tower) – primär wegen der Verfügbarkeit (s. Kap. 8.4).

Preise sind indikativ (Stand Juni 2026), aus Händlerangaben abgeleitet; CHF-Umrechnung (≈ GBP ×1,12, ≈ USD ×0,90, ≈ EUR ×0,96), ohne MwSt./Versand. Option 6 ist in € angegeben (reale Thomas-Krenn-Konfiguration). Für die Beschaffung sind Schweizer Offerten einzuholen.

Option 1 — Refurbished Dell PowerEdge R6525 (geprüfte Alternative, laut)

2× AMD EPYC 7763 (je 64 C / 2,45 GHz) = 128 Kerne / 256 Threads (Zen 3 „Milan”)
512 GB DDR4 (auf 768 GB aufrüstbar, DDR4 günstig)
Dual 1400 W Platinum PSU, PERC H755 RAID, 5-Jahre-Garantie (Manufacturer Refurbished)
Preis: ~£11 580 ≈ CHF 13 000 (Bytestock)
Deckt alle drei Stufen A/B/C ab. Mit RAM-Upgrade auf 768 GB (~+CHF 1 500–2 000) auch Stufe C komfortabel.

Option 2 — Neu: Supermicro Single-Socket EPYC 9654

1× AMD EPYC 9654 = 96 Kerne / 192 Threads (Zen 4 „Genoa”, DDR5)
512 GB DDR5 RDIMM, NVMe-Boot + NVMe-Scratch
Aktuelle Generation, volle Herstellergarantie
Preis: ~CHF 21 000 (Barebone-Basis Supermicro eStore + CPU ~USD 7 272 + RAM + Storage)
Deckt Stufe A und B ab; Stufe C (100 Kerne) nur über Threads, nicht über physische Kerne.

Option 3 — Neu: Supermicro Dual-Socket EPYC 9654 (Reserve)

2× EPYC 9654 = 192 Kerne / 384 Threads, 768 GB DDR5
Plattform z. B. Supermicro AS-2025HS-TNR (2U, Dual SP5)
Preis: ~CHF 28 000–30 000
Maximale Reserve, deutlich über Stufe C – nur falls starkes Wachstum erwartet wird.

Option 4 — Leiser Custom-Tower (Dual-EPYC 7763) ★ günstigste Alternative

2× AMD EPYC 7763 (Sockel SP3) = 128 Kerne / 256 Threads
512–768 GB DDR4-3200 ECC RDIMM
2× Noctua NH-U14S TR4-SP3 Luftkühler + 3–4× Noctua NF-A14 Gehäuselüfter
Tower-Gehäuse (Fractal Design Define 7 XL / Phanteks Enthoo Pro 2), leises ATX-Netzteil
Standard-PWM-Lüfteranschlüsse, BMC/IPMI auf dem Board – kein proprietärer Stecker, keine iDRAC-Lüfter-Sperre, kein lautes 1U-Netzteil
Preis: ~CHF 8 000–11 000 (Eigenbau; Komponenten-Garantien statt einer Hersteller-Garantie)
Deckt alle drei Stufen ab und läuft dabei leise (s. Kap. 8.2).
⚠️ Geringste Verfügbarkeit: nur Gebrauchtmarkt, gematchte Teile, PSB-Lock-Risiko (s. Kap. 8.4).

Option 5 — Neu von Digitec: Single-Socket Threadripper PRO 7995WX (Selbstbau)

Preise bei Digitec geprüft (Juni 2026):

Komponente	Digitec	~CHF
CPU: Threadripper PRO 7995WX (96 C/192 T, sTR5)	Link	~8 943
Board: ASUS Pro WS WRX90E-SAGE SE (8 DIMM)	Link	~1 174
768 GB DDR5 ECC RDIMM (8×96 GB)	Micron u. a. verfügbar	~7 000–9 000
Noctua NH-U14S TR5-SP6 + Tower + 1000-W-PSU + NVMe + Lüfter	div.	~2 000
Summe		~CHF 19 000–21 000

Alle Teile neu bei einem Schweizer Händler (Digitec); einmaliger Selbstbau.
96 Zen-4-Kerne ≈ Aggregat-Durchsatz des Dual-7763; deckt die 104-vCPU-Spitze.
⚠️ 1 TB bräuchte seltene/teure 8×128-GB-Module – 768 GB ist hier die praktikable Grösse.

Option 6 — Vorkonfektioniert: Silent-Tower-Server (Thomas-Krenn TA1506) ★★ GEWÄHLTE VARIANTE

Plattform: Thomas-Krenn TA1506 (AMD Single-CPU Silent-Tower)
1× AMD EPYC 9555P (64 C / 128 T, Zen 5, SP5, 360 W) – schnelle Kerne für kurze Build-Zeiten
Arbeitsspeicher: 768 GB oder 1,15 TB DDR5-4800 – zwei Varianten (RAM = grösster Kostentreiber), s. Tabelle unten
NVMe-RAID (Boot-Mirror + Daten-RAID + Scratch), 2× 10 GbE/IPMI
Fertig konfiguriert, gebaut, BIOS/OS installiert, lastgetestet, Business-Garantie
Silent-Tower < 30 dB(A) – für den Arbeitsplatz freigegeben; Hersteller löst die Kühlung
CH-Lieferung in wenigen Tagen (Thomas-Krenn Lieferung Schweiz)
Preis: ~€ 36 000 (768 GB) bzw. ~€ 45 000 (1,15 TB, empfohlen) – Richtwerte
Kein Bau-/Sourcing-Aufwand, kein SP5-Kühlerproblem (Hersteller-Kühlkonzept).

CPU-Begründung: Statt des angebotenen 128-Kern-9754 (Zen 4c, langsame 2,25/3,1 GHz) wurde der 9555P (Zen 5, 3,2/4,4 GHz) gewählt: Die Last ist nicht CPU-, sondern RAM-gebunden, und 64 schnelle Kerne/128 Threads decken die 104-vCPU-Spitze – schnelle Kerne verkürzen die langen Build-/Test-Jobs (BDD ~25 min), wo der 9754 sie verlangsamt hätte. Der 400-W-9575F wurde wegen des Silent-Ziels (< 30 dB schwer bei 400 W) nicht gewählt; nur sinnvoll, falls TK das Silent-Konzept für 400 W bestätigt.

RAM-Varianten (grösster Kostentreiber):

Variante	Bestückung	Kanäle	~Bandbreite	Kapazität	RAM-Preis	Total (Opt. 6)
Budget	768 GB (8×96) DDR5-4800	8 von 12	~307 GB/s	deckt alle Stufen	€ 18 201	~€ 36 000
★ Empfohlen	1152 GB (12×96) DDR5-4800	12 von 12	~460 GB/s	+ ~570 GB Reserve	€ 27 801	~€ 45 000

Für die GC-/bandbreitenlastige C#-Last (Roslyn/MSBuild + viele vstest-Hosts) ist die volle 12-Kanal-Bestückung empfohlen – Begründung und GC-Tuning s. Kap. 9. Das 768-GB-Sparpaket bleibt möglich (−€ 9 600), gibt aber ~⅓ Speicherbandbreite auf. (Volle 12 Kanäle gibt es bei TK nur als 12×96 = 1,15 TB; 768 GB at 12 Kanälen wäre das 12×64-Samsung-Modul für ~€ 34 000 – nicht sinnvoll.)

RAM-Marktnotiz (Juni 2026) – wichtig: DDR5-Serverspeicher ist derzeit teuer und volatil (KI-getriebene Preisspitze). Das treibt alle Optionen mit viel neuem RAM. Thomas-Krenn verlangt für RAM zudem ~2× Digitec-Retail (768 GB bei TK ≈ € 18 k; 96-GB-RDIMM bei Digitec ~CHF 0,9–1,1 k/Modul → 768 GB ≈ CHF 7–9 k). Grösster Sparhebel: bei TK nach kundeneigenem RAM bzw. günstigeren Modulen fragen – das kann den Preisunterschied zur Eigenbau-Option (5) weitgehend auflösen und mehrere Tausend CHF/€ sparen.

★ Variante „RAM selbst bestücken” (grösster Sparhebel): Den TA1506 mit minimaler RAM-Bestückung bei TK bestellen (CPU, Storage, Kühlung, Aufbau, Garantie, Silent-Konzept) und die RDIMMs bei Digitec kaufen und selbst einsetzen (RDIMM einstecken ist trivial). Ersparnis: bei 768 GB grob ~CHF 8–10 k, bei 1,15 TB ~€ 14–15 k → ein TA1506 mit selbst bestückten 1,15 TB landet bei ~CHF 25 000–30 000 statt € 45 000. Vorher mit TK klären:

Auslieferung mit minimalem RAM möglich?
Bleibt die System-Garantie bei kundeneigenem RAM erhalten?
QVL anfordern – nur gelistete, identische RDIMMs über alle 12 Kanäle kaufen (gleicher Hersteller/Rank/Speed; registriertes ECC, kein UDIMM), sonst Takt-/Boot-Probleme.

Eigenen Memtest/Burn-in vor Produktivbetrieb fahren (ersetzt TKs RAM-Validierung). Damit bleibt der Turnkey-Vorteil (gebaut, gekühlt, garantiert, leise) erhalten, nur der teuerste Posten wird zum Retail-Preis beschafft.

8.1 Vergleich Preis vs. Leistung {#kap-8-1}

	Refurb 2× 7763 (1U)	Leiser Tower 2× 7763	Neu 1× 9654	Neu 2× 9654
Physische Kerne	128	128	96	192
Pro-Kern-Leistung	Basis (Zen 3)	Basis (Zen 3)	+~30–40 % (Zen 4)	+~30–40 %
Speicher	DDR4-3200	DDR4-3200	DDR5	DDR5
Aggregat-Durchsatz CI	sehr hoch	sehr hoch	hoch (96 C)	sehr hoch
Leise kühlbar?	nein (1U)	ja (Noctua, SP3)	schwer (SP5: keine Noctua)	schwer (SP5)
Garantie	5 J. (refurb)	Komponenten	volle Neu-Garantie	volle Neu-Garantie
Preis	~CHF 13 000	~CHF 8–11 000	~CHF 21 000	~CHF 28–30 000

Fazit: Unsere CI-Last ist massiv parallel (viele unabhängige Runner) – hier zählt der Aggregat-Durchsatz mehr als die Pro-Kern-Leistung. 128 ältere Kerne schlagen 96 neuere im Durchsatz, zu einem Bruchteil des Preises. Die etwas höhere Pro-Kern-Leistung von Genoa (SP5) rechtfertigt den Aufpreis für diesen Workload nicht – und SP5 lässt sich nicht leise kühlen (Noctua bietet keinen SP5-Kühler an). Zudem liefert der Dual-7763 im Aggregat ~40 % mehr Durchsatz als ein einzelner 9654 (PassMark: 9654 +41 % gegenüber einem 7763, aber 2× 7763 = 2,0× vs. 1× 9654 = 1,41×). Diese Tabelle vergleicht nur Preis/Leistung der Hardware-Varianten – leistungsseitig sind alle stark genug. Die finale Wahl fiel auf Option 6 (vorkonfektioniert), nicht aus Leistungsgründen, sondern wegen Verfügbarkeit & Aufwand (s. Kap. 8.4). Option 4 bleibt die günstigste Eigenbau-Alternative.

8.2 Lärm & leise Kühlung (Noctua) {#kap-8-2}

Betrifft die selbst gebauten/refurbishten Optionen (1/4/5). Die gewählte Option 6 wird vom Hersteller leise gekühlt (< 30 dB) – dort entfällt dieses Thema.

Ein 1U/2U-Rackserver ist laut („Düsentriebwerk”). Der naheliegende Gedanke, einfach die Lüfter gegen leise Noctua-Lüfter zu tauschen, scheitert beim 1U-Refurb an mehreren Punkten:

Hürde beim 1U-Rack-Mod	Konsequenz
1U bietet nur Platz für 40-mm-Hochdrehzahl-Lüfter	Kein Platz für leise 80/120-mm-Lüfter
2× 280 W EPYC = ~560 W Abwärme	Hoher Luftdurchsatz zwingend nötig
iDRAC9 sperrt in neueren Firmware die manuelle Lüftersteuerung	Nur per Firmware-Downgrade umgehbar – schlecht für einen Produktivserver
Netzteillüfter sind nicht regelbar	Laufen immer auf Maximum
Proprietärer Dell-Lüfterstecker	Jeder Lüfter muss umgelötet werden; Garantie erlischt

Bekannte „Silent-Dell”-Umbauten gelingen – aber stets an grösseren, kühleren Geräten (z. B. 2U/4U mit Niedrig-TDP-CPU), nicht an einem 1U mit zwei 280-W-CPUs. Quellen: Silent Dell Server (Gavin Li), iDRAC9-Lüfterscript.

Leise ist also eine Frage der Bauform, nicht des Lüftertauschs. Zwei tragfähige Wege:

Weg A – Leiser Tower-Eigenbau (Option 4): Sockel SP3 (EPYC 7763) wird von Noctua direkt unterstützt – NH-U14S / NH-U12S TR4-SP3 (von Phoronix auf EPYC getestet). Standard-PWM, keine Firmware-Tricks, kein lautes 1U-Netzteil. Der ältere 7763 ist hier sogar im Vorteil: Für SP5 (9654) gibt es keinen Noctua-Kühler.
Weg B – Rack behalten, Lärm über den Standort lösen: Refurb-Rack unangetastet in einen separaten Technikraum oder ein schallgedämmtes Akustik-Rack stellen. Günstigste Hardware, kein Thermo-Risiko, Garantie bleibt.

8.3 Stückliste (Alternative Option 4: leiser Dual-7763-Eigenbau-Tower)

Nur relevant, falls statt des vorkonfektionierten Servers (Option 6) der günstige Eigenbau gewählt wird. Die gewählte Variante (Option 6) wird fertig konfiguriert von Thomas-Krenn geliefert und braucht keine Stückliste.

Komponente	Empfehlung	Menge	Preis (indikativ, CHF)
Mainboard	Supermicro H12DSi-N6 (Dual SP3, 16× DIMM, 2× 10 GbE, IPMI)	1	~600 (gebr.)
CPU	AMD EPYC 7763 (64 C, SP3) – ungelockt, kein Dell/Lenovo-PSB	2	~2 800 (gebr.)
RAM	64 GB DDR4-3200 ECC RDIMM (2Rx4) → 16 Module = 1 TB	16	~2 000–3 000 (gebr.)
CPU-Kühler	Noctua NH-U14S TR4-SP3	2	~220
Gehäuse	Phanteks Enthoo Pro 2 (Server Ed.) od. Fractal Define 7 XL	1	~220
Netzteil	Seasonic PRIME TX-1000 (Titanium, Hybrid-/Silent-Modus)	1	~300
Boot-SSD	1 TB NVMe (als Mirror)	2	~200
Daten-SSD (Forgejo/Repos)	4 TB Enterprise NVMe/SATA (Mirror/RAID)	2	~600
Scratch-SSD (Runner-I/O)	2 TB NVMe	1–2	~150–300
Gehäuselüfter	Noctua NF-A14 PWM	3	~75
Kleinteile	Wärmeleitpaste NT-H2, Kabel	–	~50
Summe Kernsystem			~ CHF 8 000–11 000

Hinweis: Gilt für den Gebrauchtmarkt (eBay/Refurbisher) – nicht bei Digitec erhältlich (Dual-SP3-Serverboards und EPYC 7763 führt Digitec nicht). Gebrauchtes DDR4 ist 2026 ebenfalls teurer geworden, bleibt aber die günstigste RAM-Quelle.

Speicher-Begründung: 16 DIMM-Slots (8 Kanäle/Sockel) → sauber balanciert nur als 512 GB (16×32) oder 1 TB (16×64); 768 GB wäre unbalanciert (NUMA/Bandbreite). Da RAM die harte Grenze ist (Spitze 416 GB + Reserve) und gebrauchte DDR4-RDIMM günstig sind, wird 1 TB bestückt – deckt auch Stufe C (584 GB) mit ~440 GB Reserve für Cache, warme VMs und Wachstum.

Leistungsbudget: ~560 W (2× CPU) + RAM/SSD/Lüfter ≈ 750–850 W Spitze → 1000-W-Netzteil mit grosszügiger Reserve, im Hybrid-Modus bei Teillast nahezu lautlos.

⚠️ Beschaffungs-Fallstricke (wichtig!)

CPU-Lock: Keine PSB-/vendor-gelockten EPYCs (Dell/Lenovo) kaufen – sie booten nicht auf dem Supermicro-Board. Auf ungelockte Retail-/Tray-7763 achten.
BIOS für „Milan”: H12DSi braucht eine aktuelle BIOS-Version für 7763 (Milan); vom Händler bestätigen lassen oder Flash-Pfad sicherstellen.
Gehäuse-/Kühler-Freiraum: SSI-EEB/E-ATX-Kompatibilität und Kühlerhöhe (NH-U14S ≈ 165 mm) prüfen.
Keine redundanten Netzteile im Tower → durch Cold-Spare + Backups abgesichert (Kap. 10).
Gebrauchtteile: nur Komponenten-Garantien; bei seriösen Refurbishern kaufen.
Cold-Spare (separat budgetieren): 1× Ersatz-7763, einige Ersatz-DIMMs, ggf. ein Ersatz-Mainboard – damit ein Defekt Stunden statt Tage kostet (~CHF 1 500–3 000).

8.4 Beschaffungswege & Verfügbarkeit (CPU-/RAM-Kombinationen) {#kap-8-4}

Da Verfügbarkeit das Hauptkriterium ist, hier die drei realistischen Beschaffungswege mit ihren CPU-/RAM-Kombinationen gegenübergestellt:

Weg	CPU	Kerne / Threads	Gen. (Sockel)	RAM balanciert (~768 GB–1 TB)	Kanäle / DIMMs	Verfügbarkeit	Bau-Aufwand	Kühlung leise?	Preis
Refurb-DIY (Opt. 4)	2× EPYC 7763	128 / 256	Zen 3 (SP3)	1 TB = 16×64 GB DDR4-3200	16 (8/Sockel)	gering (nur gebraucht, gematcht, PSB-Lock-Risiko)	hoch	ja (Noctua SP3)	~CHF 7–9k
Neu @ Digitec (Opt. 5)	1× TRPro 7995WX	96 / 192	Zen 4 (sTR5)	768 GB = 8×96 GB (1 TB nur mit raren 8×128)	8	hoch (alles neu, ein Händler)	mittel (1× Selbstbau)	ja (Noctua sTR5)	~CHF 19–21k
Vorkonfektioniert (Opt. 6)	1× EPYC 9555P	64 / 128	Zen 5 (SP5)	768 GB (8×96, 8-Kanal) · 1,15 TB (12×96, 12-Kanal ★)	8 od. 12	sehr hoch (ab Lager gebaut, CH-Lieferung in Tagen)	keiner	ja (Hersteller-Konzept)	~€ 36–45k
(Maximum, optional)	2× EPYC 9654	192 / 384	Zen 4 (SP5)	1,5 TB = 24×64	24	sehr hoch	keiner	ja	~CHF 28–35k

Kernaussagen:

Durchsatz: 128 Zen-3-Kerne ≈ 96 Zen-4-Kerne (beide ~1,9–2,0×). Alle Wege decken die gemessene 104-vCPU-Spitze und alle drei Dimensionierungs-Stufen ab.
RAM-Ziel 1 TB am saubersten beim 7763 (16×64) und beim EPYC 9555P (12×96 = 1,15 TB); beim TRPro braucht 1 TB seltene 128-GB-RDIMM → dort sind 768 GB praktikabler.
Verfügbarkeit (das Hauptkriterium): Refurb gering → Digitec hoch → Vorkonfektioniert am höchsten, dazu null Bau-Aufwand und Business-Garantie.
Kühlung: Bei SP5 (9654) gibt es zwar keinen Noctua-Kühler, aber der Vorkonfektionär löst das selbst (Silent-Tower < 30 dB). TRPro (sTR5) und 7763 (SP3) haben Noctua-Kühler.

Gewählt (Priorität „Verfügbarkeit”): Option 6 – vorkonfektionierter Silent-Tower (Thomas-Krenn TA1506, 1× EPYC 9555P, 1152 GB DDR5-4800). Sofort lieferbar, gebaut & getestet, leise, mit Garantie – ohne jeden Sourcing- oder Bau-Aufwand. Wer alles neu aus einer Hand bei Digitec will und einmal selbst baut, nimmt Option 5 (TRPro 7995WX); den günstigsten Preis bietet Option 4 (Eigenbau Dual-7763), allerdings mit dem höchsten Aufwand.

9. Performance-Tuning: .NET & Garbage Collector (Runner) {#kap-9}

Build (MSBuild/Roslyn) und Tests (vstest.console / testhost) laufen bei .NET Framework 4.8 auf der .NET-Framework-CLR. Deren GC wird über app.config/machine.config (<runtime>) bzw. COMPlus_*-Umgebungsvariablen konfiguriert – nicht über die DOTNET_*/runtimeconfig-Knobs von .NET 5+. Da die Last allokations- und GC-lastig ist (Roslyn erzeugt enorme Gen0-Churn, dazu viele parallele Testhosts), beeinflusst die GC-Konfiguration Build-/Testzeiten und den Speicherbandbreitenbedarf direkt. Pro Windows-Runner-VM empfohlen:

Server GC aktivieren – <runtime><gcServer enabled="true"/></runtime> (bzw. COMPlus_gcServer=1). Sammelt parallel über mehrere Heaps → höherer Durchsatz unter Last.
GCHeapCount = vCPUs der VM – <runtime><GCHeapCount>N</GCHeapCount> (oder COMPlus_GCHeapCount=0xN, Hex). Server GC legt sonst ein Heap + GC-Thread pro logischem Kern an; in der VM auf die vCPU-Zahl fixieren, damit die GC-Parallelität der VM-Größe entspricht und nicht „über-threadet” – spart Bandbreite und Kontextwechsel.
Concurrent/Background GC bewusst wählen – <gcConcurrent enabled="false"/> (COMPlus_gcConcurrent=0) erhöht bei reinen Batch-Läufen oft den Gesamtdurchsatz (keine Hintergrund-GC-Threads, die Bandbreite kosten); für latenz-/interaktiv eher an lassen. Pro Job-Typ messen.
Heap-Obergrenze: Ein hartes GCHeapHardLimit gibt es nur in .NET 5+/Core, nicht in .NET Framework. Für die Framework-Hosts ist daher die pro-VM zugeteilte RAM-Menge die effektive Obergrenze – Runner-VMs streng nach Größe (2x/8x/16x) dimensionieren, damit ein „Ausreißer”-Testlauf nicht den Host gefährdet. (Künftige .NET-5+/Linux-Runner: DOTNET_GCHeapHardLimit.)
Test-Parallelität dosieren – vstest.console … /Parallel startet je Test-Assembly einen testhost-Prozess (jeder mit eigener GC). Parallelität bzw. RunSettings→MaxCpuCount so wählen, dass Hosts × Threads die VM-vCPUs nicht massiv überbuchen.
MSBuild-Parallelität – msbuild /m:<n> an die VM-vCPUs koppeln; den Roslyn-Compilerserver (VBCSCompiler.exe) je VM wiederverwenden, bei Snapshot-Revert aber sauber beenden.

Warum das hier zählt: Diese Stellschrauben begrenzen und glätten den Speicherverkehr je VM. Zusammen mit der vollen 12-Kanal-RAM-Bestückung (Kap. 8) sind sie der entscheidende Hebel gegen GC-bedingte Bandbreiten-Engpässe, wenn ~13 C#-Build-/Test-VMs gleichzeitig sammeln.

10. On-Prem-Readiness-Checkliste {#kap-10}

Der Standort im Haus ist noch offen. Vor der Inbetriebnahme zu klären:

11. Risiken & offene Punkte

Thema	Risiko	Massnahme
Windows-Lizenzierung (geklärt)	Windows Server wird pro Kern lizenziert; viele Windows-VMs könnten sonst teuer werden.	Bereits abgedeckt: Unsere vorhandenen Visual-Studio-/MSDN-Subscriptions schliessen Windows-Server-Rechte für Dev/Test (CI zählt dazu) ein → kein zusätzlicher Lizenzkostenblock.
Einzelner Server	Hardware-Defekt = Ausfall der Dev-Plattform	Redundante PSU (konfigurierbar), RAID, ECC; off-box-Backups; Cold-Spare; späteres HA-Upgrade möglich
Migrationsaufwand	GitHub Actions → Forgejo Actions, Repos/PRs/Issues importieren	Forgejo-Migrationstools nutzen; Workflows sind weitgehend kompatibel; Pilot mit einem Repo
.NET-Framework-Bindung	Erzwingt Windows-Runner dauerhaft	Bewusst eingeplant (KVM-Pool); Linux/Firecracker für Neues vorbereitet
Betriebsverantwortung	Wir betreiben jetzt selbst (Updates, Verfügbarkeit)	Monitoring, Wartungsfenster, dokumentierte Runbooks

12. Empfehlung

Forgejo selbst hosten – auf eigener Hardware im Haus. Löst Geschwindigkeit, Rate-Limits, Datenhoheit, fehlende Funktionen und die kostenpflichtigen Stakeholder-Accounts in einem Zug.
Hardware: vorkonfektionierter Silent-Tower – Thomas-Krenn TA1506, 1× EPYC 9555P (64 C / 128 T, Zen 5), 1152 GB DDR5-4800 (12×96, volle 12-Kanal-Bestückung) (~€ 45 000; Sparvariante 768 GB / 8-Kanal ~€ 36 000 – s. Kap. 8 & GC-Tuning Kap. 9). Gewählt wegen Verfügbarkeit: fertig gebaut/getestet, < 30 dB leise, Business-Garantie, keine Sourcing-/Bau-Arbeit. Deckt die 104-vCPU-Spitze und alle Dimensionierungs-Stufen ab; RAM (der eigentliche Engpass) grosszügig dimensioniert. Günstigere Alternativen (Eigenbau, Refurb) s. Kap. 8.
Architektur: Linux-Host mit KVM; Windows-Runner als Warm-Pool + Burst mit Snapshot-Revert (sauber & reproduzierbar); Linux-Runner via Firecracker; Forgejo + Microservices auf demselben Host. Pages direkt mit ausliefern.
Absicherung: redundante PSU (konfigurierbar)/RAID/ECC, off-box-Backups, Cold-Spare – damit wir GitHubs Ausfall-Problem nicht im eigenen Haus neu erschaffen.
Vor Beschaffung klären: Standort-Readiness (Strom, Kühlung, USV, Netzwerk). Windows-Lizenzierung ist über die vorhandenen Visual-Studio-/MSDN-Dev/Test-Rechte bereits abgedeckt.

Anhang – Datenquellen: CI-Logs ci-billing-2026-06-01.csv, jobs-report-2026-06-01.csv, queue-timings-2026-06-01.csv (Mai 2026). GitHub-Ausfälle: mrshu.github.io/github-statuses (Atom-Feed-Rekonstruktion, Feb–Apr 2026). WarpBuild-Runner-Specs: warpbuild.com/docs/ci/cloud-runners.

Quartz 5

Explorer

Migration Github -> Forgejo (selfhosted)

Von GitHub zu selbst­gehostetem Forgejo