Praxisbeispiele

Bewährte Cloud-Mac-Workflows anderer – einfach übernehmen

Vier echte Workflows: Regression vor dem App-Store-Release, schnellere CI/CD-Builds, Experimente mit lokalen LLMs, Remote-Mixing im Tonstudio. Finde heraus, welcher zu dir passt, und richte dir direkt die passende Maschine ein.

Alle Beispiele

Vier reale Szenarien – findest du dich wieder?

Jedes Beispiel nennt genau das verwendete Modell, den Standort, die Kosten und das Ergebnis. Alle Zahlen sind real, und die nachvollziehbaren Schritte findest du weiter unten.

Klicke auf einen Filter, um nur die relevante Kategorie zu sehen

Beispiel 01 · Entwicklung

Solo-Entwickler: M4 tageweise gemietet für die letzte Meile vor dem Release

Ein Solo-Entwickler, der hauptsächlich unter Linux mit Flutter arbeitet, braucht einen Mac eigentlich nur zur Einreichungszeit: zum Signieren und Archivieren, zum Durchgehen der App-Store-Checkliste und für die Regression in einer echten macOS-Umgebung. Dafür einen Mac mini zu kaufen würde bedeuten, dass die Maschine 360 Tage im Jahr ungenutzt herumsteht.

Seine Lösung: Kurz vor der Einreichung bucht er bei HireVPS einen Zest M4 am Standort Tokio – von der Zahlung bis zu den SSH- und VNC-Zugangsdaten dauert es etwa 2 Minuten. Am ersten Tag installiert er Xcode und die Zertifikate und archiviert den Code, am zweiten Tag geht er die Checkliste durch und behebt zwei Layout-Probleme, die nur unter macOS auftreten, am dritten Tag reicht er bei App Store Connect ein und kündigt die Maschine, sobald die Regression bestanden ist.

  • Dedizierte Dedicated hardware-Hardware ohne Virtualisierung – Xcode archiviert genauso schnell wie auf einem lokalen Gerät
  • Referenzlatenz vom Standort Tokio zum Nutzer von rund 60 ms – VNC läuft flüssig ohne Nachziehen (abhängig von der tatsächlichen Verbindung)
  • Nach der Kündigung wird die Festplatte vollständig gelöscht – Zertifikate und Quellcode bleiben nicht auf der Maschine zurück

„Früher musste ich mir für jede Einreichung ein MacBook von einem Freund leihen. Jetzt erledige ich das für $21,6, kündige nach der Regression und muss mir keine Gedanken mehr machen.“

— Originalzitat des Entwicklers aus diesem Beispiel

Konfiguration im Überblick

  • ModellZest M4 · 16GB · 256GB SSD
  • StandortTokio (JP)
  • Abrechnung$21,6/Tag, insgesamt 3 Tage für $21,6
  • EinsatzzweckXcode-Archivierung + Regression vor der Einreichung
  • BereitstellungZugangsdaten etwa 2 Minuten nach Zahlung
Beispiel 02 · CI/CD

Internationales Team: Runner an die US-Westküste verlegt, keine Warteschlangen mehr bei Builds

Ein 12-köpfiges internationales App-Team hat seine iOS-Builds bisher auf einem 2018er Intel Mac mini in der Ecke des Büros laufen lassen: langsame Builds, Warteschlangen am Tag, und nachts konnte niemand die Maschine neu starten. Da das Team über zwei Zeitzonen verteilt ist, mussten Builds, die die US-Kollegen einreichten, oft warten, bis die asiatischen Kollegen zur Arbeit kamen und hängende Jobs neu starteten.

Die Migration hat nur einen Nachmittag gedauert: Sie buchen bei HireVPS einen Citrus M4 im Monatsabo am Standort US-Westküste, registrieren ihn als selbstgehosteten GitHub-Actions-Runner und ändern im Workflow runs-on auf ein benutzerdefiniertes Label. Die Build-Artefakte werden per fastlane direkt an TestFlight übergeben. Alle Standorte sind 365 Tage im Jahr durchgängig online – auch mitten in der Nacht eingereichte Builds werden pünktlich fertig.

~40%
Kürzere durchschnittliche Build-Zeit (21 Min. → 12,5 Min.)
0
Fehlgeschlagene Builds durch Runner-Ausfälle nach der Migration (im ersten Monat gemessen)
$198,2/Monat
Monatliche Kosten für den Citrus M4 – deutlich entspannter als die Wartung der alten Maschine

Konfiguration im Überblick

  • ModellCitrus M4 · 24GB · 512GB SSD
  • StandortUS-Westküste (US-W)
  • AbrechnungMonatsabo $198,2
  • EinsatzzweckSelbstgehosteter GitHub-Actions-Runner
  • PipelineXcode + fastlane → TestFlight

„Die deutlichste Veränderung: Niemand fragt mehr im Chat, wer gerade die Build-Maschine belegt.“

— iOS-Verantwortlicher des Teams
Beispiel 03 · KI

KI-Enthusiast: 64 GB Unified Memory – jedes Modell läuft, das er will

Ein KI-Enthusiast wollte systematisch vergleichen, wie sich die Ausgabequalität großer Sprachmodelle bei unterschiedlichen Quantisierungsstufen verändert – wollte dafür aber nicht extra ein High-End-Gerät für ein paar Wochenend-Experimente kaufen. Die Unified-Memory-Architektur von Apple Silicon kommt lokaler Inferenz sehr entgegen: 64 GB Arbeitsspeicher bedeuten, dass ein 32B-Modell in 4-Bit-Quantisierung vollständig im Speicher gehalten werden kann, ohne beim VRAM Kompromisse eingehen zu müssen.

Er mietet tageweise einen Blaze M4 Pro an der US-Westküste und testet abwechselnd mit llama.cpp und MLX: Die Inferenz des 32B-4-Bit-Modells läuft mit etwa 11–14 Token/s, ein LoRA-Fine-Tuning-Experiment mit einem 7B-Modell ist über Nacht abgeschlossen (Richtwerte, abhängig von Modell, Kontextlänge und Parametern – maßgeblich sind die tatsächlichen Messwerte). Auf der 2-TB-SSD ist Platz für ein Dutzend Modellgewichte gleichzeitig; nach Abschluss der Experimente exportiert er die Ergebnisse und kündigt die Maschine.

  • Dedizierte Dedicated hardware-Hardware – niemand teilt sich die Rechenleistung während der Inferenz, weil es schlicht keine Mitnutzer gibt
  • Root-Zugriff für freie Framework-Installation und Kernel-Extension-Abhängigkeiten
  • Tagesabrechnung: Ein Wochenend-Experiment kostet $43,2 statt eine Maschine für über $3000

Konfiguration im Überblick

  • ModellBlaze M4 Pro · 64GB · 2TB SSD
  • StandortUS-Westküste (US-W)
  • Abrechnung$21,6/Tag
  • EinsatzzweckLokale LLM-Inferenz + LoRA-Fine-Tuning
  • Durchsatz-Richtwert32B 4-Bit ca. 11–14 Token/s
Beispiel 04 · Kreativ

Tonstudio: Logic-Pro-Projekt in die Cloud verlegt, Musiker an fünf Standorten wechseln sich im „Studio“ ab

Ein kleines Tonstudio übernimmt ein internationales Projekt: Der Produzent sitzt in Los Angeles, das Arrangement entsteht in Taipeh, das Mixing in Tokio. Bisher wurden Projektdateien hin- und hergeschickt, Versionskonflikte waren an der Tagesordnung, und allein das Warten auf Dateien kostete pro Song zwei bis drei Tage.

Jetzt mieten sie wochenweise einen Blaze M4 Pro an der US-Westküste: Das Logic-Pro-Projekt, die Plug-ins und die Sample-Bibliothek liegen nur einmal in der Cloud, die 1-TB-SSD bietet genug Platz für das gesamte Sample-Material des Projekts. Alle drei wechseln sich zeitlich ab und greifen per Bildschirmfreigabe auf dieselbe Maschine zu – Änderungen wirken sofort, Streit darüber, welche Version die aktuelle ist, gibt es nicht mehr. Die Plug-in-Lizenzen werden gemäß den jeweiligen Herstellerbedingungen auf diese Maschine übertragen und aktiviert; vor Projektende werden alle Projektdateien exportiert und die Maschine anschließend gekündigt.

  • Der Standort US-Westküste bietet für den Musiker in Los Angeles nahezu lokale Latenz; Tokio und Taipeh arbeiten per Bildschirmfreigabe, was für Schnitt und Mixing gut funktioniert (Echtzeitaufnahmen sollten weiterhin lokal erfolgen und anschließend hochgeladen werden)
  • Die wochenweise Abrechnung passt zum projektbasierten Rhythmus – zwischen Projekten fallen keine Kosten an
  • Kostenlose Neuinstallation: Nach Projektende macOS mit einem Klick zurücksetzen, das nächste Projekt startet mit einer sauberen Umgebung

„Gespart haben wir nicht in erster Linie Geld, sondern die Nächte, in denen wir zu dritt ein 80-GB-Projektpaket hin- und herschicken mussten.“

— Mixing-Ingenieur des Studios

Konfiguration im Überblick

  • ModellBlaze M4 Pro · 64GB · 2TB SSD
  • StandortUS-Westküste (US-W)
  • AbrechnungWochenmiete (Tagespreis $21,6, Wochenpreis siehe Preisseite)
  • EinsatzzweckRemote-Zusammenarbeit und Mixing in Logic Pro
  • ZugriffVNC / macOS-Bildschirmfreigabe
Konfigurationsvorlagen

Zum Nachbauen: Zwei zentrale Konfigurationen aus den Beispielen

Die wichtigsten Schritte aus Beispiel 2 und Beispiel 1 sind in diesen beiden Konfigurationen zusammengefasst. Öffne auf deinem Cloud Mac das Terminal, ersetze die Platzhalter in den spitzen Klammern – fertig. Eine ausführlichere Anleitung findest du im Support-Center.

GitHub-Actions-Runner registrieren

# 1. On your cloud Mac, create a runner directory
mkdir ~/actions-runner && cd ~/actions-runner

# 2. Download the macOS arm64 runner package —
#    copy the exact command from your repo:
#    Settings -> Actions -> Runners -> New self-hosted runner

# 3. Register the runner against your repository
./config.sh --url <your-repo-url> \
  --token <runner-token> \
  --labels macos,arm64,hirevps --unattended

# 4. Install as a service so it survives reboots
./svc.sh install && ./svc.sh start

Setze im Workflow runs-on auf [self-hosted, macos, hirevps], damit der Job auf dieser Maschine landet.

Build mit fastlane und direkter Übergabe an TestFlight

# fastlane/Fastfile — archive & upload from your cloud Mac
default_platform(:ios)

lane :release do
  setup_ci                # temporary keychain on the runner
  match(type: "appstore", readonly: true)
  build_app(
    scheme: "<YourScheme>",
    export_method: "app-store"
  )
  upload_to_testflight(
    skip_waiting_for_build_processing: true
  )
end

Zertifikate werden zentral über match verwaltet – nach Kündigung und Neustart der Maschine reicht ein einmaliger Abruf, um die Build-Fähigkeit wiederherzustellen.

Einreichung mit Prämie

Erzähl uns von deinem Workflow und erhalte einen Gutschein über $20

Hast du auf einem Cloud Mac einen Workflow umgesetzt, der hier noch nicht vorkommt? Schreib uns: welches Modell und welchen Standort du genutzt hast, welches Problem du damit gelöst hast und worauf man achten sollte. Wird dein Beitrag veröffentlicht, erhält dein Konto einen Gutschein über $20, einlösbar für jeden Abrechnungszeitraum.

  • Jede Form ist willkommen: ein paar hundert Wörter, eine bebilderte Anleitung oder eine Sammlung von Terminal-Befehlen
  • Namensnennung nach Wunsch: mit Pseudonym oder komplett anonym
  • Zahlen sollen stimmen: Angaben zu Zeit und Kosten bitte auf Basis realer Messwerte – wir sprechen sie vor der Veröffentlichung mit dir ab

Kurzanleitung für deinen Beitrag

Ein guter Beitrag enthält in der Regel vier Elemente:

  1. Ausgangslage: Wer du bist und welches Problem du hattest
  2. Lösung: Modell, Standort, Abrechnungszeitraum und die Gründe für diese Wahl
  3. Ergebnis: Die entscheidenden Zahlen im Vorher-Nachher-Vergleich
  4. Stolperfallen: Ein oder zwei Dinge, die du gern früher gewusst hättest

Bitte gib im Betreff „Praxisbeitrag“ an, damit wir ihn vorrangig bearbeiten können.