Support-Center

Probleme mit Ihrem Cloud Mac? Erst selbst nachschlagen, dann erst Hilfe rufen

Die meisten Probleme – keine Verbindung, Neuinstallation, fehlgeschlagene CI-Builds – lassen sich mit den folgenden Schritten in fünf Minuten selbst lösen. Brauchen Sie doch persönliche Hilfe, stehen Ticket- und E-Mail-Support das ganze Jahr bereit, bei kritischen Störungen reagieren wir 24/7.

Ticket einreichen, bei Notfällen priorisiert Erst mal die FAQ durchstöbern
Vier Kanäle

Je nach Dringlichkeit den schnellsten Weg wählen

Die Selbsthilfe-Dokumentation ist am schnellsten, das Ticketsystem am umfassendsten, E-Mail eignet sich für die Dokumentation, und die Statusseite hilft Ihnen vorab zu klären, ob es an der Plattform liegt.

Dokumentations-Center

Diese Seite bündelt Anleitungen zum Einstieg, zur Neuinstallation, zu CI/CD und zur Fehlerbehebung – Befehle einfach kopieren und einfügen.

Direkt weiter unten nachlesen →

Ticketsystem

Im Portal anmelden und ein Ticket erstellen – Ihre Maschinendaten werden automatisch verknüpft, bei kritischen Störungen können Sie priorisierte Bearbeitung wählen.

Zum Portal, Ticket erstellen →

E-Mail-Support

support@hirevps.com – geeignet für Anfragen mit Screenshots, Logs oder anderem Dokumentationsbedarf.

E-Mail an uns schreiben →

Statusseite

Die Echtzeit-Verfügbarkeit aller Standorte auf einen Blick – vor der Meldung kurz nachsehen und sich einen Umweg sparen.

Live-Status ansehen →
Erste Schritte

Die ersten zehn Minuten nach Erhalt der Zugangsdaten

Innerhalb von 2 Minuten nach der Bereitstellung erhalten Sie im Portal und per E-Mail Ihre SSH-/VNC-Zugangsdaten. Mit den folgenden drei Schritten sind Sie in zehn Minuten auf dem Desktop und können losarbeiten.

1. Erste SSH-Anmeldung

Der Hostname in Ihren Zugangsdaten sieht etwa so aus: jp1-1024.hirevps.com. Verbinden Sie sich einfach über das im System integrierte Terminal:

# replace host and user with your credentials
ssh omac@jp1-1024.hirevps.com
# first login: change your password
passwd

Wir empfehlen, das Passwort direkt nach der Anmeldung zu ändern, Ihren SSH-Public-Key im Portal zu hinterlegen und die Passwortanmeldung zu deaktivieren – das ist sicherer und spart Ihnen künftig Zeit.

2. VNC / Bildschirmfreigabe aktivieren

Bei der Bereitstellung ist die Bildschirmfreigabe standardmäßig aktiviert. Falls Sie sie manuell deaktiviert haben, reicht ein Befehl per SSH, um sie wieder einzuschalten:

# enable macOS remote management (screen sharing)
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
  -activate -configure -access -on -restart -agent

Auf dem Mac nutzen Sie die App „Bildschirmfreigabe“, unter Windows/Linux einen beliebigen VNC-Client – als Adresse den Hostnamen und Port 5900 eingeben.

3. Checkliste für die Entwicklungsumgebung

  • Im ausgelieferten Image sind Homebrew, Git und die Xcode Command Line Tools bereits vorinstalliert. Prüfen Sie die Versionen im Terminal mit xcodebuild -version und brew --version.
  • Führen Sie bei CI/CD-Szenarien zunächst einen vollständigen Build als Baseline aus: Notieren Sie Kaltstart- und inkrementelle Build-Zeiten, um später Performance-Probleme vergleichen zu können.
  • Legen Sie Zertifikate und Schlüssel am besten in eine eigene Keychain und entsperren Sie diese explizit im Build-Skript – so vermeiden Sie Signierfehler durch eine gesperrte grafische Sitzung.
  • Synchronisieren Sie Code und Build-Ergebnisse vor der Vertragskündigung in Ihr eigenes Repository oder Object Storage – nach dem Löschen sind die Daten nicht wiederherstellbar (siehe Datenabgrenzung in den Nutzungsbedingungen).
Häufige Vorgänge

Neuinstallation, Versionswechsel, Datenmigration – alles mit wenigen Klicks im Portal

Diese drei Aufgaben erledigen Sie komplett selbst, ohne Ticket – Neuinstallation und Versionswechsel sind kostenlos und ohne Mengenbegrenzung.

macOS neu installieren

Portal → Ihre Instanz → „System neu installieren“, Version auswählen und bestätigen. Der gesamte Vorgang dauert etwa 15–25 Minuten (abhängig vom tatsächlichen Ergebnis).

Bei der Neuinstallation wird die gesamte SSD gelöscht. Pushen Sie Ihren Code vorher in ein Remote-Repository, kopieren Sie Build-Ergebnisse heraus und bestätigen Sie erst danach.

Systemversion wechseln

Wählbar sind die aktuelle stabile Version sowie die vorherige Hauptversion (z. B. Sequoia / Sonoma); an manchen Standorten stehen Beta-Images zur Verfügung – maßgeblich ist die Liste im Portal.

Der Versionswechsel läuft ebenfalls über die Neuinstallation und löscht dabei die Festplatte. Für Kompatibilitätstests über mehrere Versionen empfehlen wir eher, tageweise eine zusätzliche Instanz zu starten und nach dem Test wieder zu kündigen.

Snapshots und Datenmigration

Vor riskanten Änderungen können Sie sich mit einem lokalen APFS-Snapshot absichern; für die Migration zwischen Maschinen empfehlen wir rsync:

# create a local snapshot before risky changes
tmutil localsnapshot
# sync your workspace to the new machine
rsync -avz ~/work/ omac@new-host:~/work/

Wir lesen und sichern die Daten auf Ihrer Maschine nicht (siehe Datenschutzerklärung) – wichtige Daten sollten Sie daher selbst regelmäßig in ein Remote-Repository oder Object Storage synchronisieren. Auch lokale Snapshots werden bei einer Neuinstallation gelöscht.

CI/CD-Integration

Diesen Mac als Ihren Build-Knoten einsetzen

Dedizierte Dedicated hardware-Hardware mit Root-Zugriff – die Anbindung an gängige CI-Systeme folgt dem offiziellen Standardprozess, ganz ohne proprietäre Anpassungen. Wählen Sie Ihr System:

Self-hosted Runner einrichten

Wählen Sie in den Actions-Einstellungen Ihres Repositorys oder Ihrer Organisation „Neuer self-hosted Runner (macOS / ARM64)“ und fügen Sie die dort angezeigten Download- und Konfigurationsbefehle in das Terminal Ihres Cloud Mac ein:

# run these on your cloud Mac (values come from your Actions settings page)
./config.sh --url <your-repo-url> --token <runner-token> \
  --labels macos,arm64,hirevps
# install as a service so it survives reboots
./svc.sh install && ./svc.sh start

Ändern Sie im Workflow einfach runs-on auf [self-hosted, macos, arm64]. Auf dedizierter M4-Hardware läuft xcodebuild in der Regel deutlich schneller als auf gehosteten Runnern – der genaue Unterschied hängt von Ihrem Projekt ab.

Fehlerbehebung

Drei häufige Probleme – erst die Checkliste durchgehen

Nehmen Sie sich vor dem Ticket zwei Minuten Zeit für die passende Checkliste – über die Hälfte aller Meldungen ist bereits bei Schritt 2 gelöst.

Keine Verbindung zur Maschine (SSH-Timeout / VNC bleibt schwarz)
  1. Öffnen Sie die Statusseite und prüfen Sie, ob Ihr Standort normal läuft – ist das der Fall, liegt das Problem höchstwahrscheinlich auf Ihrer Seite.
  2. Pingen Sie den Hostnamen lokal an, um die Erreichbarkeit zu prüfen; versuchen Sie es auch über den mobilen Hotspot Ihres Smartphones, um eine Sperre der Ports 22/5900 durch Firmennetzwerk oder Provider auszuschließen.
  3. Prüfen Sie im Portal den Instanzstatus: Steht sie auf „läuft“, nutzen Sie zunächst „Remote-Neustart“ im Portal; hängt sie beim Start, warten Sie 3 Minuten und aktualisieren Sie dann erneut.
  4. Prüfen Sie, ob Sie den SSH-Port oder Firewall-Regeln (pfctl) geändert haben – das ist die häufigste Ursache dafür, sich selbst auszusperren. Das „Rettungsterminal“ im Portal umgeht das Netzwerk und ermöglicht direkten Zugriff auf das System, um die Änderung zurückzunehmen.
  5. Haben Sie alle Punkte geprüft und die Verbindung funktioniert weiterhin nicht, öffnen Sie ein Ticket und wählen Sie „Keine Verbindung möglich“ – wir bearbeiten es als P1.
Build wird langsamer (xcodebuild-Laufzeit steigt deutlich)
  1. Prüfen Sie zunächst, ob sich die Aufgabe selbst verändert hat: Nach Dependency-Updates oder einem großen Xcode-Versionswechsel muss beim ersten Build der Index und Cache neu aufgebaut werden – einmalig langsamer ist normal.
  2. Prüfen Sie mit top -o cpu, ob ein Prozess außer Kontrolle geraten ist; die erste Spotlight-Indexierung kann die CPU voll auslasten und lässt sich mit mdutil -a -i off deaktivieren.
  3. Prüfen Sie, ob DerivedData bei jedem CI-Lauf gelöscht wird – das Beibehalten des Cache-Verzeichnisses reduziert inkrementelle Build-Zeiten in der Regel erheblich.
  4. Prüfen Sie mit df -h den freien Speicherplatz: Ist die SSD zu über 90 % belegt, sinkt die Schreibleistung – erst Speicherplatz freigeben, dann erneut vergleichen.
  5. Ihre Maschine ist dediziert – es gibt keine „Nachbarn“, die sich Ressourcen teilen. Bleibt die Verlangsamung trotz aller Prüfungen bestehen, öffnen Sie ein Ticket mit den Build-Logs von vorher und nachher – wir prüfen dann die Hardware-Ebene.
Festplatte ist voll (No space left on device)
  1. Finden Sie zunächst die größten Verursacher: du -sh ~/Library/Developer/* – meist belegen Xcodes DerivedData, alte Simulator-Runtimes und Archives den meisten Platz.
  2. Sicheres Aufräumen: rm -rf ~/Library/Developer/Xcode/DerivedData; ungenutzte Simulator-Runtimes entfernen Sie mit xcrun simctl runtime delete.
  3. Auch lokale APFS-Snapshots belegen Speicherplatz: mit tmutil listlocalsnapshots / anzeigen, mit tmutil deletelocalsnapshots alte Snapshots löschen.
  4. Für CI-Maschinen empfehlen wir, regelmäßige Aufräumschritte in die Pipeline einzubauen, statt erst zu reagieren, wenn die Platte voll ist.
  5. Immer noch knapp nach dem Aufräumen? Dann ist ein Upgrade sinnvoll – bei einem SSD-Upgrade zahlen Sie nur die Differenz, zur Datenmigration siehe das Handbuch oben, oder wählen Sie direkt auf der Tarifseite eine größere Stufe.
SLA & Reaktionszeiten

Schriftlich fixierte Reaktionszusagen

Tickets werden nach Auswirkung in drei Stufen eingeteilt – die Einstufung wählen Sie beim Erstellen, wir prüfen sie anschließend gegen. Wir versprechen nur, was wir auch einhalten können.

Übersicht der Ticket-Stufen und Reaktionszeiten
Stufe Typisches Szenario Erste Reaktion Servicezeiten
P1 Kritisch Maschine nicht erreichbar, Hardwareausfall, Standort nicht verfügbar ≤ 30 Minuten 24/7, ganzjährig
P2 Eingeschränkt Performance-Probleme, hängende Neuinstallation, sporadische Netzwerkstörungen ≤ 4 Stunden 24/7, ganzjährig
P3 Allgemein Nutzungsfragen, Rechnungsfragen, Konfigurationsempfehlungen ≤ 12 Stunden Werktags

Verfügbarkeit & Ausgleichsregelung

  • Für einzelne Instanzen garantieren wir eine monatliche Verfügbarkeit von 99,9 % – alle Standorte laufen 365 Tage im Jahr durchgehend, ohne geplante Ausfallzeiten.
  • Liegt die tatsächliche Verfügbarkeit um 0,1 % unter der Zusage, erhalten Sie ein Gutschrift-Guthaben in Höhe von 5 % der monatlichen Gebühr; die Obergrenze pro Monat liegt bei 100 % der monatlichen Instanzgebühr.
  • Reichen Sie den Ausgleichsanspruch im Portal mit dem betroffenen Zeitraum ein – wir gleichen ihn mit unseren Monitoring-Daten ab und zahlen innerhalb von 7 Werktagen.
  • Ausfälle durch höhere Gewalt oder eigenes Verschulden (z. B. versehentlich gelöschte Systemdateien, fehlerhafte Netzwerkkonfiguration) fallen nicht unter den Ausgleich – wir helfen Ihnen aber trotzdem bei der Behebung.

So bearbeiten wir Ihr Ticket am schnellsten

  • Melden Sie sich im Portal an und erstellen Sie das Ticket dort – Maschinen-ID und Standortdaten werden automatisch übernommen, das erspart eine Rückfrage im Vergleich zur E-Mail.
  • Beschreiben Sie klar „wann, was gemacht, welcher Fehler aufgetreten ist“ und fügen Sie die vollständige Fehlermeldung als Text ein statt als Screenshot – das verkürzt die Diagnosezeit deutlich.
  • Bei P1-Problemen wählen Sie im Ticket direkt „Kritisch“ – nutzen Sie dafür nicht die E-Mail, diese wird nach P3-Zeiten bearbeitet.
  • Die vollständigen Ausgleichsregelungen finden Sie in den Nutzungsbedingungen – maßgeblich ist der dort festgelegte Wortlaut.
365 Tage im Jahr in Betrieb · keine geplanten Ausfälle

Servicestatus & Ankündigungen auf einen Blick

Die Echtzeit-Verfügbarkeit, historischen Daten und Vorfallmeldungen der fünf Standorte Tokio, Singapur und der US-Westküste sind öffentlich auf der Statusseite einsehbar. Bei jedem Vorfall mit Auswirkung auf den Service wird der Fortschritt fortlaufend auf derselben Seite aktualisiert. Ein Blick vor der Meldung hilft Ihnen sofort einzuschätzen, ob es an der Plattform oder an Ihrer Umgebung liegt.

Live-Statusseite öffnen Ereignisbenachrichtigungen im Portal abonnieren
  • JP TokioEchtzeit-Verfügbarkeit und Verlauf siehe Statusseite
  • SG SingapurEchtzeit-Verfügbarkeit und Verlauf siehe Statusseite
  • US-W Westküste USAEchtzeit-Verfügbarkeit und Verlauf siehe Statusseite

Ihr Fall steht nicht im Handbuch?

Melden Sie sich im Portal an, reichen Sie ein Ticket ein und fügen Sie die Fehlermeldung im Originaltext bei – den Rest übernehmen wir.

Zum Portal, Ticket erstellen