Rufen Sie zuerst Ihre Zugangsdaten ab und richten Sie dann die Anmeldung per Schlüssel und Ihren ersten Build ein. Die Schritte folgen der Reihenfolge bei der Inbetriebnahme und helfen Ihnen, einen Cloud-Mac in den Arbeitsalltag Ihres Teams zu integrieren.
Sie erhalten einen dedizierten physischen Server, keine virtuelle Maschine. Die grafische macOS-Oberfläche und die Kommandozeile stehen vollständig zur Verfügung.
Von der Bestellung zur ersten Verbindung
Prüfen Sie zuerst, ob der Server bereit ist
Heute bestellt, heute bereitgestellt. Der übliche Ablauf dauert etwa 4 Minuten. Maßgeblich sind die Zahlungsbestätigung und der aktuelle Serverstatus in der Konsole. Erstellen Sie nach der Zahlung nicht erneut dieselbe Bestellung.
1
Bestellen: Standort und Laufzeit wählen
Wählen Sie einen von vier Standorten: Singapur, Tokio, Seoul oder Hongkong. Legen Sie anschließend die Abrechnung pro Tag, Woche, Monat oder Quartal fest. Prüfen Sie Modell, Zusatzoptionen und Ablaufdatum gemeinsam.
ca. 1 Min.
2
Bezahlen: Bestelldaten aufbewahren
Akzeptiert werden ausschließlich USDT-TRC20 sowie Visa, Mastercard und Amex (über Stripe). Alle Beträge werden in US-Dollar abgerechnet. Welche Zahlungsgateways tatsächlich verfügbar sind, zeigt die Rückmeldung der Backend-Schnittstelle.
ca. 1 Min.
3
Server wird bereitgestellt: Systemstart abwarten
Stellen Sie erst dann eine Verbindung her, wenn der physische Server zugewiesen und das System vorbereitet wurde. Ist die Bestellung bezahlt, der Server aber noch in Vorbereitung, prüfen Sie zunächst den Status. Ein noch nicht bereiter Server ist kein Netzwerkfehler.
ca. 2 Min.
4
Zugangsdaten abrufen: Details des passenden Servers öffnen
Melden Sie sich in der Konsole an, öffnen Sie die Instanzliste und wählen Sie die Details des Servers aus, der zu Ihrer Bestellung gehört. Dort finden Sie Hostadresse, SSH-Port und Benutzernamen. Maßgeblich sind die Angaben auf der Detailseite. Prüfen Sie vor dem Verbinden die Servernummer.
Nach der Bereitstellung
Insgesamt ca. 4 Min. Wenn Sie trotz Zahlung keine Zugangsdaten abrufen können, erstellen Sie in der Konsole ein Support-Ticket und geben Sie Bestellnummer und aktuellen Status an. Veröffentlichen Sie niemals vollständige Zugangsdaten, private Schlüssel oder Zahlungskartendaten.
Erste Verbindung
Erst die Verbindung, dann die Toolchain prüfen
Das Beispiel zeigt einen Server in Tokio und ausgewählte Befehle für SSH-Login, SDK-Prüfung, Archivierung und Upload. Ersetzen Sie den Hostnamen durch eine Variable und Arbeitsbereich, Scheme sowie den Namen des fastlane-Ablaufs durch die Werte Ihres Projekts. Dies ist weder ein Leistungstest noch ein echtes Bestellprotokoll.
Server in Tokio · Hostname YOUR_NODE_HOST · Beispiel mit Befehlen und Ausgaben
$ ssh -v -i ~/.ssh/minissh_ed25519 -p "$NODE_SSH_PORT" "$NODE_USER@$NODE_HOST"
debug1: Server host key: ssh-ed25519 SHA256:…
debug1: Authentication succeeded (publickey).
Authenticated using publickey.
Welcome to your Mac mini.
$ xcodebuild -showsdks
iOS SDKs:
iOS -sdk iphoneos
$ xcodebuild -workspace App.xcworkspace -scheme App -archivePath build/App.xcarchive archive
** ARCHIVE SUCCEEDED **
$ fastlane upload
Uploading build to App Store Connect
Upload complete
Erste SSH-Verbindung: Setzen Sie zuerst NODE_HOST, NODE_USER und NODE_SSH_PORT auf die Werte aus den Serverdetails. Prüfen Sie beim ersten Verbindungsaufbau den Host-Fingerabdruck. Können Sie ihn nicht verifizieren, lassen Sie ihn zunächst über ein Support-Ticket bestätigen. Ignorieren Sie die Prüfung der Serveridentität nicht einfach.
Ersten Build starten: Führen Sie zuerst xcodebuild -version und xcodebuild -showsdks aus und notieren Sie die aktuelle Toolchain. Archivieren Sie erst, wenn Projektabhängigkeiten, Signaturmaterial und Build-Konfiguration bereitstehen. fastlane upload können Sie nur verwenden, wenn der entsprechende Ablauf im Projekt definiert und die Upload-Berechtigung eingerichtet ist.
Ergebnis richtig einordnen: Eine erfolgreiche SSH-Verbindung bedeutet nicht, dass sich das Projekt bereits bauen lässt. Auch ein erfolgreiches Archiv bedeutet nicht, dass der Upload abgeschlossen ist. Speichern Sie die Ergebnisse für Verbindung, Archivierung und Upload getrennt. So können Sie bei der Fehlersuche genau angeben, an welchem Schritt das Problem auftritt.
Verbindung absichern
Zuerst Schlüssel prüfen, dann Passwortzugriff deaktivieren
Weisen Sie jeder Person einen eigenen öffentlichen Schlüssel zu. Teilen Sie nicht denselben privaten Schlüssel mit dem ganzen Team. Lassen Sie beim Ändern der Authentifizierungseinstellungen die aktuelle Sitzung geöffnet und prüfen Sie mit einem zweiten Terminal, ob eine neue Verbindung funktioniert, bevor Sie die ursprüngliche Sitzung beenden.
01
Schlüssel lokal erstellen
Führen Sie den folgenden Befehl auf Ihrem eigenen Computer aus und schützen Sie den privaten Schlüssel mit einer Passphrase. Hochgeladen oder weitergegeben werden darf nur die Datei mit dem öffentlichen Schlüssel .pub . Der private Schlüssel ohne Dateiendung bleibt immer lokal auf Ihrem Computer.
ssh-keygen -t ed25519 -f ~/.ssh/minissh_ed25519
02
Öffentlichen Schlüssel hochladen und testen
Fügen Sie den öffentlichen Schlüssel in die Datei ~/.ssh/authorized_keys des Zielbenutzers auf dem Server ein, jeden Schlüssel in einer eigenen Zeile. Übertragen Sie ihn über eine bestehende, verifizierte Verbindung und prüfen Sie anschließend die Berechtigungen von Verzeichnis und Datei.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Öffnen Sie ein weiteres Terminal und testen Sie die Anmeldung mit explizit angegebenem privaten Schlüssel. Prüfen Sie, ob Sie beim erwarteten Benutzer auf dem richtigen Server landen, bevor Sie die Authentifizierungseinstellungen ändern.
03
Passwortauthentifizierung deaktivieren
Eine Person mit Administratorrechten sollte die wirksame SSH-Serverkonfiguration prüfen und PasswordAuthentication sowie KbdInteractiveAuthentication auf no setzen. Prüfen Sie nach der Änderung die Syntax und die tatsächlich wirksamen Werte. Stellen Sie sicher, dass keine andere Konfiguration die Einstellungen überschreibt.
Wenden Sie die Konfiguration entsprechend der Dienstverwaltung des aktuellen Systems an und testen Sie die neue Verbindung erneut. Sind Sie sich bei der Konfiguration unsicher, erstellen Sie zuerst ein Support-Ticket. Starten Sie den Dienst nicht neu und deaktivieren Sie den Fernzugriff nicht in Ihrer einzigen funktionierenden Sitzung.
04
Desktopverbindung per Tunnel
Vergewissern Sie sich, dass die Bildschirmfreigabe auf dem Server und die Berechtigungen des betreffenden Benutzers eingerichtet sind. Richten Sie dann lokal einen SSH-Tunnel ein. Im Beispiel wird der lokale Port 15900 auf den Loopback-Port 5900 des Servers weitergeleitet. Der Tunnel lauscht nicht im lokalen Netzwerk.
Verbinden Sie sich anschließend mit Ihrem lokalen Desktop-Client mit 127.0.0.1:15900. Wenn Sie das Terminal mit dem Tunnel schließen, wird auch die Verbindung getrennt. Funktioniert SSH, aber die Desktopverbindung nicht, prüfen Sie zuerst den Freigabedienst auf dem Server, statt den Desktop-Port direkt freizugeben.
Zusammenarbeit über Zeitzonen hinweg
Ein Server gemeinsam, aber keine gemeinsamen Konten
Dediziert bedeutet, dass der physische Server Ihnen zur Verfügung steht. Es bedeutet nicht, dass Aufgaben mehrerer Personen automatisch voneinander isoliert sind. Wenn Teammitglieder in Nordamerika und im asiatisch-pazifischen Raum denselben Mac mini Server nutzen, richten Sie zuerst getrennte Konten ein, vereinbaren Sie dann Build-Zeiten und dokumentieren Sie schließlich die Übergabe.
Eigenes Konto für jedes Teammitglied
Legen Sie für jedes Teammitglied einen eigenen macOS-Benutzer an und fügen Sie nur dessen öffentlichen Schlüssel hinzu. Für die tägliche Entwicklung reichen normale Benutzerrechte. Änderungen auf Systemebene sollte eine festgelegte Administrationsperson vornehmen.
Entfernen Sie nach dem Ausscheiden eines Teammitglieds die zugehörigen Berechtigungen und prüfen Sie gespeicherte Zugriffstoken in Build-Tools. Ändern Sie nicht einfach nur ein gemeinsam verwendetes Passwort.
Legen Sie zuerst fest, in welcher Zeitzone die Build-Zeiten angegeben werden. Bevor Teammitglieder im asiatisch-pazifischen Raum ein Archiv erstellen, prüfen Sie, ob Kolleginnen oder Kollegen in Nordamerika noch Aufgaben ausführen. Vermeiden Sie möglichst gleichzeitig laufende große Archivierungen, Abhängigkeitsinstallationen und Systemupdates.
Trennen Sie Projekt- und Ausgabeverzeichnisse nach Benutzer oder Branch, damit nicht zwei Personen dieselben Build-Artefakte löschen.
Übergabe: verantwortliche Person, Start- und Endzeit, Ausgabepfad.
Umgebung und Aufgabenergebnis dokumentieren
Notieren Sie vor der Übergabe den Code- und Xcode-Stand, den ausgeführten Befehl und das Ergebnis. Informieren Sie das Team der nächsten Zeitzone, bevor Sie die Toolchain ändern, damit es nach der Übernahme nicht von einer veränderten Umgebung überrascht wird.
Desktopverbindungen über Regionen hinweg hängen von der jeweiligen Netzwerkverbindung ab. Führen Sie lange Aufgaben vorzugsweise per SSH aus und bewahren Sie Build-Protokolle auf, die später erneut eingesehen werden können.
In Spitzenzeiten einen weiteren Server mieten – Daten vorher sichern
Dauerhafte und temporäre Aufgaben lassen sich getrennt planen. Ein zusätzlicher Server ist ein eigenständiges Mietobjekt und übernimmt weder Code noch Abhängigkeiten, Schlüssel oder Build-Artefakte des vorhandenen Servers automatisch. Richten Sie zuerst die Umgebung ein und verlagern Sie dann Aufgaben auf den neuen Server.
01
Zusätzlichen Server für dasselbe Projekt mieten
Buchen Sie über den Bestellzugang einen weiteren Server und wählen Sie eine Laufzeit passend zur Dauer der Aufgabe: Tag, Woche, Monat oder Quartal. Zur Auswahl stehen die Modelle MiniSSH M4 Core (M4 / 16 GB RAM / 256 GB SSD) und MiniSSH M4 Plus (M4 / 24 GB RAM / 512 GB SSD). Die vollständigen Preise und Zusatzoptionen finden Sie auf der Tarifseite.
02
Temporäre Workloads verschieben
Übertragen Sie Code und Abhängigkeiten für das Projekt und richten Sie die Zugriffsrechte auf dem neuen Server separat ein. Führen Sie zunächst einen reproduzierbaren Build aus und prüfen Sie, ob sich die Artefakte abrufen lassen. Planen Sie erst danach weitere Branches oder Batch-Aufgaben ein. Bewahren Sie das einzige Backup nicht auf einem temporären Server auf.
03
Ablauf ohne Verlängerung sicherstellen
Prüfen Sie das Ablaufdatum des temporären Servers in der Konsole und verlängern Sie ihn nicht. Falls die Oberfläche eine Einstellung für automatische Verlängerung anbietet, stellen Sie sicher, dass sie deaktiviert ist. Ohne Verlängerung endet der Mietzeitraum automatisch; eine Deaktivierungsgebühr fällt nicht an. Exportieren Sie Artefakte und Protokolle vor dem Ablauf und widerrufen Sie Zugriffstoken, damit Sie nach der Rückgabe nicht nach Dateien suchen müssen.
Der Server ist 365 Tage im Jahr rund um die Uhr in Betrieb. Erstellen Sie bei Problemen ein Support-Ticket in der Konsole und ergänzen Sie den Verlauf im selben Ticket. Installieren Sie das System nicht wiederholt neu, ändern Sie nicht ständig die Konfiguration und zahlen Sie nicht erneut – dadurch wird die Rekonstruktion des Problems erschwert.
Problem
Zuerst prüfen
Im Support-Ticket angeben
SSH-Verbindung nicht möglich
Ist der Server bereit? Stimmen Adresse, Port und Benutzername mit den Serverdetails überein? Handelt es sich um eine Zeitüberschreitung, eine abgelehnte Verbindung oder einen Authentifizierungsfehler? Notieren Sie den vollständigen Fehlertyp.
Servernummer, Standort, Beginn des Problems mit Zeitzone, verwendetes Netzwerk und SSH-Fehlerausgabe ohne vertrauliche Angaben.
Build hängt oder schlägt fehl
Prüfen Sie zuerst den verfügbaren Speicherplatz, andere laufende Aufgaben auf demselben Server und kürzliche Änderungen an Toolchain oder Abhängigkeiten. Unterscheiden Sie zwischen ausbleibenden neuen Protokolleinträgen und einem tatsächlich beendeten Prozess.
Ausgeführter Befehl, Xcode-Version, Startzeit, letzte Protokollzeilen, Exit-Code und Angabe, ob sich der Fehler zuverlässig reproduzieren lässt.
System neu installieren
Sichern Sie zuerst Code, Build-Artefakte und erforderliche Konfigurationen. Notieren Sie, welche Umgebung erhalten oder neu eingerichtet werden soll. Eine Neuinstallation wirkt sich auf vorhandene Daten auf dem Server aus.
Servernummer, Grund für die Neuinstallation, Status der Datensicherung und möglicher Zeitraum für die Durchführung. Vereinbaren Sie den Umfang der Arbeiten zuerst im Support-Ticket.
Fragen zu Zahlung oder Verlängerung
Prüfen Sie zuerst den Status der betreffenden Bestellung und Rechnung. Vergewissern Sie sich, für welchen Server der Vorgang bestimmt ist, damit Sie nicht versehentlich eine andere Bestellung erneut bezahlen.
Bestellnummer; bei USDT-TRC20-Zahlungen den Transaktions-Hash, bei Kartenzahlungen über Stripe die Bestellnummer und die Fehlermeldung aus der Oberfläche. Senden Sie niemals die vollständige Kartennummer.
Zeitzone immer angeben: „Ortszeit 14:30 Uhr, UTC+8“ lässt sich leichter nachvollziehen als „nachmittags keine Verbindung“. Geben Sie bei Teams in Nordamerika und im asiatisch-pazifischen Raum auch an, zu welchen Zeiten Sie gut erreichbar sind.
Status im ursprünglichen Support-Ticket prüfen: Melden Sie sich in der Konsole an, öffnen Sie die Ticketliste und rufen Sie den passenden Vorgang auf, um Antworten zu lesen und weitere Angaben hinzuzufügen. Wenn Sie sich nicht anmelden können, schreiben Sie an support@minissh.com. Geben Sie die E-Mail-Adresse Ihres Kontos und die betreffenden Bestellnummern an, aber senden Sie weder Passwörter noch private Schlüssel.
Wenn Sie einzelne Themen ausführlicher behandeln möchten, finden Sie in der Liste der technischen Artikel Beiträge zu den folgenden drei Bereichen. Die Befehle auf dieser Seite zeigen die Reihenfolge der Schritte. Verzeichnisse, Berechtigungen und Toolversionen müssen Sie weiterhin für Ihre Umgebung prüfen.
Remote-Entwicklungsumgebung einrichten
Im Mittelpunkt stehen Benutzerkonten, Projektverzeichnisse, die Vorbereitung von Abhängigkeiten und die Übergabe über Zeitzonen hinweg. Richten Sie zuerst eine reproduzierbare Entwicklungsumgebung ein und binden Sie dann weitere Teammitglieder ein.
SSH-Tunnel und Zugriffsschutz
Hier geht es um die Anmeldung per öffentlichem Schlüssel, die Anpassung der Passwortauthentifizierung und lokale Portweiterleitung. Lassen Sie vor Änderungen an Sicherheitseinstellungen immer eine bereits verifizierte Verbindung bestehen.
Xcode-Builds in der Cloud
Im Mittelpunkt stehen die SDK-Prüfung, Archivierungsparameter und fastlane-Abläufe. Prüfen Sie Archivierung und Upload getrennt. Ein einzelner erfolgreicher Durchlauf bedeutet nicht, dass der gesamte Ablauf stabil ist.
Mieten Sie tageweise ab $20.8 pro Tag. Haben Sie bereits einen Server, prüfen Sie Ihre Zugangsdaten in der Konsole. Wenn Sie noch nicht bestellt haben, wählen Sie die Laufzeit passend zum Projekt.