ArmMini besteht aus iOS-Entwicklern und SREs. Wir haben nicht zuerst ein Projekt gestartet und dann nach Kunden gesucht – die 4 Mac mini, die wir 2021 ins Rack gestellt haben, liefen ursprünglich einfach als CI-Server für unsere eigenen Apps. Diese Seite erklärt, wer wir sind, warum wir konsequent auf dedizierte Hardware setzen und wie unsere Maschinen tatsächlich betrieben werden.
Unser Team besteht derzeit aus 7 Personen: 3 iOS-Entwicklern, 2 SREs und 2 Support-Mitarbeitern, verteilt über die Zeitzonen UTC+8 und UTC-8. Jeder von uns hat eigene Apps oder CI-Pipelines, die auf unseren eigenen Knoten laufen. Wenn eine Maschine Probleme macht, erfahren wir es meist vor unseren Kunden – weil unser eigener Build zuerst rot wird.
Das bestimmt unsere Prioritäten: Zuerst müssen die Maschinen stabil laufen, Zugangsdaten schnell ausgeliefert werden und sich Probleme selbst per Neustart beheben lassen – alles andere kommt danach. Jeder Troubleshooting-Schritt und jede Latenzangabe auf dieser Website haben wir selbst an diesen Maschinen gemessen, nicht aus einer Dokumentation abgeschrieben.
Wir halten das Team bewusst klein. Dass 7 Leute über hundert Maschinen betreuen, liegt nicht an Überstunden, sondern daran, dass wir Out-of-Band-Stromsteuerung, automatisierte Checks und Self-Service-Neuinstallation von Anfang an richtig aufgesetzt haben. Unsere Erstreaktionszeit bei Tickets liegt unter zwei Stunden, weil 80 % der Probleme die Nutzer im Portal selbst lösen können – nur der Rest braucht einen Menschen.
Wenn Sie auch täglich mit Xcode, Runnern und Simulatoren zu tun haben, verstehen wir uns wahrscheinlich gut. Bei konkreten Fragen schauen Sie einfach ins Troubleshooting-Handbuch oder sprechen Sie uns an.
$ system_profiler SPHardwareDataType | grep Chip
Chip: Apple M4 Pro
$ uptime
14:32 up 217 days, load averages: 3.42 2.98 2.71
$ ops team --list
ios-dev x3 sre x2 support x2
coverage: UTC+8 / UTC-8
eating our own dogfood since 2021
all nodes healthyMit geteilter Virtualisierung – einen Host in acht Teile aufgeteilt – lässt sich deutlich mehr Marge herausholen. Wir haben diesen Weg nicht gewählt, aus drei Gründen, bei denen wir keine Kompromisse machen.
Die Lizenzbedingungen von macOS verlangen, dass das System auf Hardware mit Apple-Markenzeichen läuft. Ein eigener, physischer Mac mini pro Kunde ist der sauberste und rechtlich unbedenklichste Weg. Geteilte Virtualisierungsmodelle bewegen sich lizenzrechtlich immer in einer Grauzone – und wir wollen nicht, dass Ihr Build-Prozess auf einer solchen Grauzone aufbaut.
Das größte Problem bei CI ist nicht Langsamkeit, sondern Schwankung. Auf dedizierter Hardware konkurriert kein Nachbar um CPU- oder Festplatten-I/O. Bei aufeinanderfolgenden vollständigen Builds desselben Projekts liegt die Zeitschwankung in der Regel unter 3 % (gemessen an unseren eigenen Projekten). Nur wenn Build-Zeiten vorhersehbar sind, lassen sich Warteschlangen und Timeout-Schwellenwerte sinnvoll festlegen.
Virtualisierungsschichten bieten bis heute keinen vollständigen Zugriff auf Metal und die Neural Engine: MLX-Inferenz, GPU-Rendering im Simulator oder Hardware-Encoding in Final Cut laufen in virtuellen Maschinen entweder gar nicht oder nur mit halber Leistung. Bei dedizierter Hardware gibt es keine Zwischenschicht – Sie nutzen den Chip genau so, wie er ist.
Drei Hardware-Standorte, deren Racks wir selbst geplant und deren Schrauben wir selbst angezogen haben. Hier die Details zu jedem Standort.
Unser Gründungsstandort seit 2021 und die Standardwahl für Nutzer in Ostasien. Alle drei Konfigurationen sind jederzeit bestellbar, und auch unsere eigene CI läuft komplett hier.
Seit 2024 online, ausgelegt auf Remote-Entwicklungsszenarien in Nordostasien. Der Standort Seoul bietet die Konfigurationen Basic und Standard; für Pro/Max wählen Sie Tokio oder Silicon Valley.
Seit 2023 online, ideal für CI-Runner nordamerikanischer Teams und Szenarien mit hohem Bandbreitenbedarf, etwa den Upload großer Build-Artefakte zu TestFlight.
Der Mac mini ist nicht für Rack-Montage konzipiert, deshalb haben wir eigene CNC-gefräste Aluminiumträger entwickelt: 4 Geräte nebeneinander pro 1U, Kabelführung an der Front, jede Maschine lässt sich einzeln herausziehen, ohne die Nachbarn zu berühren. Klingt nach einem Detail, entscheidet aber, ob ein Hardware-Austausch 5 oder 50 Minuten dauert.
Alle drei Rechenzentren verfügen über zwei unabhängige Stromnetze plus USV und Dieselgeneratoren; jedes Rack ist über zwei PDUs an beide Netze angeschlossen. Fällt eine Versorgung aus, laufen die Maschinen unterbrechungsfrei weiter. In den letzten 12 Monaten gab es keinen einzigen Ausfall durch Stromprobleme.
Jede Maschine hängt an einem eigenen Kanal einer intelligenten PDU. Wenn ein System komplett hängt, muss niemand ins Rechenzentrum laufen – Sie klicken im Portal auf „Erzwungener Neustart“, die PDU trennt und stellt die Stromversorgung wieder her, im Schnitt in 40 Sekunden, auch um drei Uhr morgens.
Dedizierte Hardware bedeutet Vertrauen, das sich nicht mit Marketingsprüchen erkaufen lässt. Diese vier Punkte stehen auf der ersten Seite unseres internen Runbooks – und hier zur öffentlichen Kontrolle.
Bei der Übergabe fordern wir Sie sofort auf, alle Zugangsdaten zu ändern; wir installieren keine Monitoring-Agents und behalten keine Admin-Zugänge auf der Maschine. Unser Health-Monitoring erfasst ausschließlich Netzwerk- und Stromwerte – ob die Maschine erreichbar ist, ob das Netzwerk funktioniert. Was auf der Maschine läuft, wissen wir nicht und wollen es auch nicht wissen.
Unser Tagesbetrieb endet an der Out-of-Band-Ebene (Strom, Netzwerk, Inventar). Muss ein Techniker zur Fehlerbehebung auf Ihr System zugreifen, braucht es Ihre ausdrückliche Freigabe im Ticket; die Aktion wird von einem einzigen diensthabenden Ingenieur durchgeführt und im Ticket protokolliert. Ohne Freigabe fasst niemand die Maschine eines Kunden an.
Bei Vorfällen, die Nutzer betreffen, veröffentlichen wir innerhalb von 72 Stunden eine vollständige Analyse: Ursache, Auswirkung, Zeitverlauf und Maßnahmen – ohne Auslassungen. Verfasst wird sie von dem Ingenieur, der den Vorfall tatsächlich bearbeitet hat, ohne Beschönigung durch Marketing-Sprache. Wir sind selbst Kunden solcher Dienste und wissen, wie schlecht sich beschönigte Post-Mortems lesen.
Innerhalb von 7 Tagen nach Außerbetriebnahme oder Kündigung wird der gesamte Datenträger gelöscht und ein Protokoll erstellt; SSDs werden zunächst vollständig verschlüsselt gelöscht und anschließend physisch vernichtet, das Vernichtungszertifikat wird archiviert. Ihre Code-Signing-Zertifikate und Zugangsdaten zu privaten Repositories verlassen das Rechenzentrum unter keinen Umständen.
Behauptungen allein reichen nicht – hier sind überprüfbare Zahlen. Die Berechnungsmethodik steht darunter, und Sie können jede Angabe per Ticket hinterfragen.
Methodik: Rollierende 12 Monate bis 07/2026; Verfügbarkeit minutengenau pro Einzelmaschine erfasst; Lieferzeit gemessen vom erfolgreichen Zahlungseingang bis zur Zustellung der Zugangsdaten per E-Mail; Erstreaktionszeit von Ticketerstellung bis zur ersten menschlichen Antwort.
Keine Investoren-Geschichte, nur ein kontinuierlicher Weg des Wachstums.
Zum Betrieb von CI für unsere eigenen zwei Apps. Der erste Rack-Träger war 3D-gedruckt – ein Exemplar heben wir heute noch als Erinnerungsstück auf.
Ein befreundetes Team mietete die Hälfte unserer Maschinen für GitHub-Actions-Runner – drei Monate ohne eine einzige Beschwerde. Da wurde uns klar: Das kann ein echtes Geschäft werden, also haben wir es ernst genommen.
Self-Service-Bestellung, automatische Zustellung der Zugangsdaten, Neustart und Neuinstallation per Klick – alles funktionsfähig. Die Lieferzeit sank von einem halben Tag manueller Arbeit auf unter 10 Minuten.
Erste 32 Geräte, ausgerichtet auf den CI-Bedarf nordamerikanischer Teams. Gleichzeitig wurde der CNC-Aluminiumträger als einheitlicher Standard für alle fünf Standorte festgelegt.
Die Latenzabdeckung für Nordostasien ist damit komplett; alle Maschinen erhalten eigene Kanäle an intelligenten PDUs, und der „erzwungene Neustart“ wird von einer Ticket-Anfrage zur Self-Service-Funktion für Nutzer.
Alle vier Konfigurationsstufen laufen jetzt einheitlich auf der M4-Generation, die Zahl aktiver Maschinen übersteigt 120. Ältere Modelle werden schrittweise ausgemustert, Datenträger nach dem Vernichtungsprozess entsorgt.
Wir suchen Verstärkung: remote, asynchron, wenig Meetings, klar dokumentiert, bevor gehandelt wird.
Betreuung der automatisierten Checks, Out-of-Band-Steuerung und Lieferkette unserer Hardware-Knoten an fünf Standorten. Sie sollten sich sowohl mit macOS als auch mit Netzwerktechnik auskennen, nächtliche Alarme selbstständig bearbeiten können und verständliche Post-Mortems schreiben.
Bewerbung per E-Mail an support@armmini.com, Betreff „Bewerbung SRE“. Statt eines klassischen Lebenslaufs interessiert uns vor allem, wie Sie den schwierigsten Vorfall Ihrer Karriere gelöst haben.
Bearbeitung von Tickets rund um Verbindungs-, Build- und Netzwerkprobleme sowie die Pflege des Troubleshooting-Handbuchs mit wiederkehrenden Problemen. Idealerweise haben Sie selbst schon Apps veröffentlicht, einen self-hosted Runner konfiguriert und sind mit der Kommandozeile vertraut.
Bewerbung per E-Mail an support@armmini.com, Betreff „Bewerbung Support“, mit einem Beispiel einer von Ihnen dokumentierten Fehleranalyse.
Miete ab einem Tag, Zustellung der Zugangsdaten bei Sofortverfügbarkeit innerhalb von 10 Minuten, Rückerstattung ungenutzter Tage innerhalb von 7 Tagen. Ihr Risiko beschränkt sich maximal auf die Miete eines einzigen Tages.