Der Mac mini steht im Rechenzentrum; für Code und Signaturmaterial ist Ihr Team zuständig. Die gesamte Maschine wird exklusiv an einen Kunden vermietet – keine virtuelle Maschine.
Verlagern Sie nächtliche Xcode-Cloud-Builds auf physische Rechner, die ganzjährig verfügbar sind, und regeln Sie SSH-Schlüssel, Build-Zugangsdaten und Datenexport bei Mietende in Ihren Teamabläufen. Exklusive Hardware sorgt für Ressourcentrennung; Zugriffsrechte müssen im Alltag weiterhin klar zugewiesen sein.
Ab einem Tag, ab $19.2/Tag. Legen Sie vor der Bereitstellung fest, wer für das Gerät zuständig ist, wer Zugriff erhält und wie Daten exportiert werden.
Mit einem exklusiv genutzten physischen Rechner gilt die Trennung auf Geräteebene. Sie teilen weder die Laufzeitressourcen eines Hosts noch den Speicher der Maschine mit anderen Kunden.
Sie erhalten einen physischen Mac mini und keine virtuelle Maschine, die von einem Host abgeteilt wurde. Chip, gemeinsamer Arbeitsspeicher und lokaler Speicher stehen den Workloads des aktuellen Mieters zur Verfügung.
Abgrenzung: Keine gemeinsam genutzte Maschine zwischen Kunden.
Repositories, DerivedData, Dependency-Caches und Build-Artefakte können während der Mietzeit auf der Maschine bleiben. Wie Verzeichnisse aufgeteilt werden und wer Lese- und Schreibzugriff erhält, legt Ihr Team fest.
Abgrenzung: Dateirechte innerhalb des Teams müssen weiterhin geregelt werden.
Exklusive Hardware bedeutet nicht, dass jede Aufgabe eigene Ressourcen erhält. Mehrere Runner, Simulatoren und Archive beanspruchen gleichzeitig Arbeitsspeicher, CPU und Festplatte derselben Maschine.
Empfehlung: Build-Parallelität und Warteschlangen festlegen.
Richten Sie nach Erhalt der SSH- und VNC-Zugangsdaten zuerst Ihre Zugriffsregeln ein. Importieren Sie anschließend Quellcode und Signaturmaterial. Wenn Teammitglieder aus dem asiatisch-pazifischen Raum und Nordamerika im Wechsel arbeiten, sollte ein dauerhaftes Passwort keinesfalls als Übergabeprozess dienen.
Hinterlegen Sie für jedes Teammitglied, das sich anmelden muss, einen eigenen öffentlichen Schlüssel. Verteilen Sie keine privaten Schlüssel über Chatverläufe. Entfernen Sie beim Ausscheiden eines Mitglieds die zugehörige Berechtigung. CI-Schlüssel sollten getrennt von persönlichen SSH-Schlüsseln verwaltet werden.
Bevor Sie die Passwortanmeldung deaktivieren, lassen Sie die aktuelle Sitzung geöffnet und testen Sie die Anmeldung mit dem Schlüssel in einer zweiten Sitzung. So vermeiden Sie, dass Ihr Team den Zugriff auf die Maschine verliert.
Richten Sie nach der ersten Verbindung ein eigenes VNC-Passwort für Ihr Team ein. Verwenden Sie nicht dasselbe Passwort wie für das Portal oder Ihr Repository. Ändern Sie es bei einem Teamwechsel oder wenn Zugangsdaten möglicherweise offengelegt wurden.
Nutzen Sie die grafische Oberfläche für Vorgänge, die eine manuelle Bestätigung erfordern. Automatisierte Builds sollten nach Möglichkeit SSH und Runner verwenden. Beenden Sie nach der Desktop-Nutzung vertrauliche Anwendungen und lassen Sie keine exportierten Passwörter sichtbar auf dem Bildschirm stehen.
Prüfen Sie die Freigabeeinstellungen von macOS. Deaktivieren Sie Dateifreigabe, Remote Apple Events und andere Freigabedienste, die Ihr Projekt nicht benötigt. Lassen Sie nur tatsächlich verwendete Zugänge für die Remote-Anmeldung oder Bildschirmfreigabe aktiv.
Prüfen Sie zuerst, wovon andere Dienste abhängen. Dokumentieren Sie die bisherige Konfiguration, bevor Sie Firewall- oder Remote-Zugriffseinstellungen ändern, und stellen Sie sicher, dass Ihrem Team weiterhin ein funktionierender Verwaltungszugang zur Verfügung steht.
Bei einer Übergabe reicht es nicht, nur das Gerätepasswort zu ändern. Repository-Tokens, Runner-Registrierungen, Zugangsdaten für Artefakt-Repositories und Passwörter für Signatur-Exporte haben jeweils eigene Berechtigungen. Prüfen Sie beim Ausscheiden eines Teammitglieds jeden Zugang einzeln, statt nur das VNC-Passwort zu ändern.
Zertifikatsdateien lassen sich kopieren. Das heißt nicht, dass jeder Build darauf zugreifen können sollte. Behandeln Sie Signaturmaterial als eigenes Asset: Legen Sie fest, wer es importiert, in welchem Schlüsselbund es verwendet wird und wann es widerrufen oder erneuert werden muss.
Speichern Sie Zertifikate, die zugehörigen privaten Schlüssel und Profile je Projekt. Prüfen Sie vor dem Import Zweck, Gültigkeitsdauer und geeignetes Target. Exportdateien mit privaten Schlüsseln gehören nicht ins Code-Repository.
Erstellen Sie bei Bedarf passwortgeschützte Exportdateien und übermitteln Sie das Passwort über einen separaten Kanal. Bewahren Sie Backups an einem vom Team verwalteten Ort auf – nicht ausschließlich auf dem Build-Rechner.
Erfassen: Projekt, Zweck, zuständige Person, Gültigkeit.
Hinterlegen Sie CI-Signaturidentitäten am besten in einem eigenen Schlüsselbund, getrennt von der interaktiven Nutzung. Richten Sie Entsperrung und Zugriffsrechte nach dem tatsächlichen Build-Bedarf ein. Gewähren Sie nicht aus Bequemlichkeit allen Prozessen Zugriff auf private Schlüssel.
Wenn ein automatisierter Vorgang den Schlüsselbund entsperren muss, lesen Sie das Passwort aus einer geschützten CI-Variable aus. Prüfen Sie die Signatur zunächst mit einem kontrollierten Build, bevor Sie den Aufgabenbereich des Runners erweitern.
Erfassen: Schlüsselbund, aufrufende Aufgabe, Entsperrung.
Geben Sie Passwörter, Tokens und Passwörter für Signatur-Exporte nicht in Skripten aus. Deaktivieren Sie bei der Fehlersuche die Ausgabe expandierter Befehle für vertrauliche Schritte und prüfen Sie Logs vor dem Hochladen auf Zugangsdaten.
Legen Sie Speicherorte und Aufbewahrungsregeln für Archive, Exportpakete und Debug-Symbole getrennt fest. Ein abgeschlossener Build ist kein Backup. Prüfen Sie mindestens einmal, ob sich benötigte Artefakte aus dem Teamspeicher wiederherstellen lassen.
Erfassen: Speicherort, zugriffsberechtigte Personen, Aufbewahrung.
Führen Sie unter dem vorgesehenen Build-Benutzer die folgende Abfrage aus, um zu prüfen, ob die erwartete Codesignaturidentität im Schlüsselbund vorhanden ist. Die Ausgabe dient der lokalen Kontrolle. Veröffentlichen Sie keine vollständigen Umgebungsinformationen.
security find-identity -v -p codesigningDer Befehl listet nur Identitäten auf. Er importiert keine Zertifikate und konfiguriert keine Zugriffsrechte für den Schlüsselbund.
Alle Rechner laufen an 365 Tagen im Jahr durchgehend. Das Rechenzentrum kümmert sich um Stromversorgung, Netzwerk und Kühlung. So hängt Ihre nächtliche Pipeline nicht mehr davon ab, ob der Mac im Büro eingeschaltet ist.
| Bereich | Aufgabe des Rechenzentrums und der Plattform | Aufgabe Ihres Teams |
|---|---|---|
| Physischer Betrieb | Die gesamte Maschine bereitstellen und Stromversorgung, Netzwerk und Kühlung sicherstellen. | Instanzen den jeweiligen Projekten zuordnen und eine verantwortliche Person festlegen. |
| Systemzugriff | Anmeldedaten für die gesamte Maschine im Portal bereitstellen. | SSH-Schlüssel, VNC-Passwort und Teamzugriffe einrichten. |
| Build-Umgebung | Einen exklusiv genutzten physischen Mac für den Remote-Zugriff bereitstellen. | Xcode-Toolchain, Runner, Abhängigkeiten und parallele Aufgaben verwalten. |
| Projekt-Assets | Die gesamte Maschine nach Mietende löschen und neu bereitstellen. | Code und Signaturmaterial sichern, Artefakte exportieren und externe Berechtigungen widerrufen. |
Der durchgehende Betrieb beschreibt die Verfügbarkeit des Rechners, nicht den Erfolg jedes Builds. Fehler in Skripten, abgelaufene Zertifikate, volle Festplatten oder Änderungen an der Systemkonfiguration durch Ihr Team müssen weiterhin im Projektablauf überwacht und behoben werden.
Nach Mietende wird die gesamte Maschine gelöscht und für den nächsten Kunden bereitgestellt. Dabei werden Daten auf dem Gerät entfernt, aber keine Berechtigungen in Repositories, CI-Systemen oder anderen Diensten widerrufen. Diese Schritte müssen getrennt erfolgen.
Sichern Sie noch nicht übermittelten Code, Build-Skripte, Archive, Exportpakete, Debug-Symbole und benötigtes Signaturmaterial. Prüfen Sie, ob die Dateien vollständig sind und Ihr Team sie an einem anderen Ort öffnen kann – nicht nur, ob der Kopiervorgang abgeschlossen ist.
Entfernen Sie den zugehörigen Runner aus der CI-Plattform und widerrufen Sie nicht mehr benötigte Deployment-Schlüssel und Zugriffstokens. Ändern Sie gemeinsam genutzte Geheimnisse gemäß den Teamregeln. Das Löschen lokaler Dateien beendet nicht das Vertrauen externer Systeme in alte Zugangsdaten.
Prüfen Sie im Portal die Mietdauer und Instanzdaten. Wenn Sie den Ablauf des Datenexports abstimmen oder Fragen zur Datenverarbeitung klären müssen, erstellen Sie rechtzeitig ein Ticket. Nutzen Sie den Rechner nach Ablauf nicht als Backup und warten Sie nicht bis zum Mietende, um nach der einzigen Datenkopie zu suchen.
Alle Preise werden in US-Dollar (USD) abgerechnet. Unterstützt werden ausschließlich USDT-TRC20 und Visa / Mastercard / Amex (über Stripe). Welche Zahlungsoptionen tatsächlich verfügbar sind, richtet sich nach der Rückmeldung des Backends beim Checkout.
Stripe verarbeitet die Zahlungsdaten Ihrer Karte; diese Website speichert keine Kartennummern. Wenn Sie ein Zahlungsproblem prüfen lassen möchten, genügen Bestellnummer und Zahlungsergebnis. Senden Sie niemals vollständige Kartennummern, Sicherheitscodes oder Fotos Ihrer Bankkarte per Ticket oder E-Mail.
Dem Support die Bestelldaten mitteilen, nicht die Kartengeheimnisse.
Prüfen Sie vor der Zahlung das angezeigte Netzwerk, die Empfängeradresse und den Betrag. Für den Abgleich gelten die Einträge auf der Blockchain. Bei Rückfragen zur Bestätigung genügen Bestellnummer und Transaktions-Hash. Senden Sie niemals private Wallet-Schlüssel oder Wiederherstellungsdaten.
Transaktions-Hash aufbewahren und Zahlungsstatus der Bestellung zuordnen.
Sicherheitsmeldungen, Fragen zum Zahlungsabgleich und zur Datenverarbeitung können Sie an support@pushmac.com senden oder als Ticket im Portal einreichen. Geben Sie bei der ersten Nachricht die Instanznummer, den verwendeten Standort, die betreffenden Schritte und den Zeitpunkt des Problems mit Zeitzone an. Entfernen Sie vertrauliche Daten aus Logs, bevor Sie sie weitergeben.
Exklusive Maschine, 365 Tage im Jahr online. Legen Sie zuerst fest, wer für die Zugriffsrechte zuständig ist, und integrieren Sie dann Xcode-Builds in Ihre Team-Pipeline.