Hier finden Sie Antworten zu Modellen, Regionen, Abrechnung, Zugriff, Berechtigungen und Mietende. Jede Bestellung entspricht einem dedizierten physischen Apple-Silicon-Knoten; Rechenressourcen werden nicht mit anderen Mietern geteilt.
Klären wir zuerst die Ressourcen: OrbVPS stellt dedizierte physische Apple-Silicon-Knoten bereit, keine nach Anteilen aufgeteilten virtuellen Maschinen.
Eine gültige Bestellung entspricht einem physischen Mac mit festgelegter Konfiguration. Prozessor, Arbeitsspeicher und Systemlaufwerk werden während der Mietdauer keinem anderen Mieter zugewiesen und ein Gerät wird nicht in mehrere virtuelle Instanzen aufgeteilt. Die angezeigten Hardwaredaten, Systemauslastung und Temperaturwerte stammen vom Knoten selbst.
Die Knoten stehen in einer entfernten Infrastruktur und stellen per Netzwerk eine SSH-Kommandozeile sowie eine grafische VNC-Oberfläche bereit. So kann Ihr Team Xcode, Build-Skripte, self-hosted runner, automatisierte Tests und für die Konfiguration geeignete lokale Modellaufgaben ausführen, ohne Geräte im Büro zu betreiben.
Nein. Der Service stellt einen dedizierten physischen Rechner bereit. Das System läuft auf echter Apple-Silicon-Hardware und nicht als virtuelle Instanz auf einem gemeinsam genutzten Host. Für Tests mit mehreren Systemen sollten Sie Datenträger, Toolchain und Wiederherstellungsstandards innerhalb des Knotens planen, statt von jederzeit kopierbaren VM-Snapshots auszugehen.
Typische Einsatzbereiche sind kontinuierliche Xcode-Builds, automatisierte iOS- und macOS-Tests, React-Native-Builds, self-hosted runner, Remote-Videobearbeitung und kleine KI-Experimente. Der Knoten eignet sich für Aufgaben mit dauerhaft benötigten Abhängigkeiten, Caches, Zertifikaten und Build-Logs, nicht für ungeprüfte Hochrisiko-Skripte mit direkter Internetfreigabe.
Das verfügbare Verzeichnis umfasst ausschließlich die folgenden drei Tarife. Arbeitsspeicher und interner Speicher sind festgelegt; zusätzlichen Speicher wählen Sie separat bei der Bestellung.
Geeignet für Xcode-Builds einzelner Repositories, leichte iOS-CI/CD, Kommandozeilenaufgaben und Tests mit geringer Parallelität. Schätzen Sie vorab den benötigten Speicher für DerivedData, Abhängigkeits-Caches und Build-Artefakte.
Orb M4 16 auswählenGeeignet für Projekte mit vielen Abhängigkeiten, React-Native-Builds mittlerer Größe, parallele Tests und kontinuierliche Builds mit umfangreicheren Caches. Für die meisten stabil betriebenen Team-Pipelines bietet diese Konfiguration ein ausgewogenes Verhältnis.
Orb M4 24 auswählenGeeignet für große Projekte, parallele Builds, anspruchsvollere macOS-Tests, Video-Workflows und kontrollierte kleine Modell-Experimente. Prüfen Sie vor der Bereitstellung weiterhin Softwareversionen, Parallelisierung und Speicherwachstum.
Orb M4 Pro auswählenSingapur, Japan (Tokio), Südkorea (Seoul) und Hongkong bieten alle drei Modelle. Kombinationen im Verzeichnis sind einheitlich als verfügbar gekennzeichnet.
Geeignet für Builds und Remote-Zugriff in Zusammenarbeit mit Teams in Südostasien. Diese Region kann direkt bei der Bestellung ausgewählt werden.
Knoten in Singapur auswählenGeeignet für Xcode-Builds, Tests und Remote-Workflows japanischer und ostasiatischer Teams.
Knoten in Japan auswählenGeeignet für kontinuierliche Builds und automatisierte Tests von Teams in Südkorea und Nordostasien.
Knoten in Südkorea auswählenGeeignet für regionsübergreifende Entwicklungszusammenarbeit und Remote-Zugriff zwischen Südchina und Südostasien.
Knoten in Hongkong auswählenWählen Sie bevorzugt die Region, die Ihrem Code-Repository, CI-Service, Artefaktspeicher und den Netzwerkrouten der wichtigsten Nutzer am nächsten liegt. Testen Sie vor der Migration SSH-Roundtrips, Repository-Abrufe und Artefakt-Uploads; beurteilen Sie den gesamten Workflow nicht allein nach der geografischen Entfernung.
„Verfügbar“ bedeutet, dass die Kombination aus Modell und Region regulär bestellt werden kann. Für die tatsächliche Verfügbarkeit beim Absenden ist die Echtzeitanzeige der Konsole maßgeblich. OrbVPS verwendet keine Vorbestellungs- oder Nachlieferungsabonnements.
Eine Regionsänderung verändert nicht den Standort des bestehenden physischen Geräts. Üblicherweise wird in der Zielregion eine neue Bestellung erstellt; Repository, Toolchain, Cache-Strategie und Geschäftsdaten werden migriert. Nach erfolgreicher Prüfung beenden Sie die Miete des ursprünglichen Knotens. Halten Sie während der Migration ein Wiederherstellungs-Backup bereit.
Alle Preise sind in US-Dollar (USD) angegeben. Vor der Bestellbestätigung werden Modell, Region, Zeitraum und Zusatzoptionen eindeutig ausgewiesen.
Geeignet für kurzfristige Validierung, einmalige Builds und Tests vor einer Migration. Ein kurzer Zeitraum ersetzt weder Datensicherung noch den Widerruf von Zugangsdaten.
Geeignet für Sprints, Release-Wochen und Kompatibilitätstests über mehrere Tage; die tägliche Bestätigung entfällt weitgehend.
Geeignet für stabil laufende CI/CD, feste Build-Knoten und Team-Workflows mit dauerhaft benötigten Abhängigkeits-Caches.
Geeignet für langfristige Aufgaben mit bereits validiertem Modell, Standort und Toolchain. Bestätigen Sie vor der Bestellung die Kapazitätsplanung und die intern verantwortliche Person für Verlängerungen.
Die Konsole zeigt den aktuellen Mietzeitraum und den Ablaufstatus an. Wenn Sie den Knoten weiter nutzen möchten, schließen Sie die Verlängerung vor Ablauf des Zeitraums ab und prüfen Sie das Bestellungsergebnis. Planen Sie wichtige Builds nicht erst nach dem Zeitraumwechsel ein, bevor Sie den Verlängerungsstatus geprüft haben.
Verfügbare Zeiträume und Konfigurationen richten sich nach der aktuellen Anzeige der Konsole. Prüfen Sie vor der Änderung neuen Zeitraum, Modell, Region und Zusatzoptionen. Bereits erstellte Bestellungen werden durch spätere Auswahl nicht geändert.
Der Grundbetrag richtet sich nach Modell und Mietzeitraum. Bei zusätzlicher SSD oder Thunderbolt 5 Parallelbetrieb werden die entsprechenden Optionen je Zeitraum addiert. Vor der Abrechnung werden die Konfigurationsdetails angezeigt; alle Beträge sind in US-Dollar (USD).
OrbVPS akzeptiert USDT-TRC20 sowie Visa / Mastercard / Amex, verarbeitet über Stripe. Alle Bestellungen werden in US-Dollar (USD) abgerechnet.
Führen Sie die Zahlung anhand der Angaben auf der Abrechnungsseite durch und prüfen Sie Netzwerk und Bestellbetrag.
Kartenzahlungen werden über Stripe verarbeitet; welches Gateway tatsächlich verfügbar ist, zeigt die Konsole an.
Nein. Öffentlich vorgesehen sind ausschließlich USDT-TRC20 sowie Visa / Mastercard / Amex über Stripe. Zahlen Sie nicht an Adressen oder Konten außerhalb der Bestellseite.
Modell, Zeitraum, Zusatzoptionen und Bestellsumme werden in US-Dollar (USD) erfasst und abgerechnet. Die Seite rechnet Beträge nicht automatisch in andere Währungen um.
Sichern Sie zunächst Bestellnummer, Zahlungszeitpunkt, Betrag und überprüfbare Transaktionsdaten. Melden Sie sich anschließend in der Konsole an und erstellen Sie ein Ticket. Senden Sie niemals vollständige Kartendaten oder ungeschützte vertrauliche Zugangsdaten.
Prüfen Sie nach der Aktivierung zunächst Knotenadresse, Hostschlüssel-Fingerabdruck und Zugangsdaten, bevor Sie Repository, Build-Tools und CI-Aufgaben anbinden.
Stellen Sie die Verbindung mit Adresse und Port aus der Konsole her. Prüfen Sie beim ersten Login den Hostschlüssel-Fingerabdruck; die Dateiberechtigungen des privaten Schlüssels sollten üblicherweise nur das Lesen durch den aktuellen Benutzer erlauben.
Die grafische Sitzung eignet sich für die Xcode-Oberfläche, Anzeigeeinstellungen und Tools mit Desktop-Bedienung. Nach einer Trennung verbinden Sie sich mit der bestehenden Sitzung, statt unnötige grafische Prozesse erneut zu starten.
Der Knoten unterstützt administrative Vorgänge für die Installation von Entwicklungstools, die Konfiguration von Diensten und kontrollierte Systemänderungen. Dokumentieren Sie vor Änderungen den Ausgangszustand und deaktivieren Sie keine erforderlichen Zugriffsdienste.
Verwenden Sie für den Runner ein eigenes Arbeitsverzeichnis, eindeutige Labels und die geringstmöglichen Berechtigungen. Führen Sie nach der Anbindung zunächst kontrollierte Testaufgaben aus und migrieren Sie die produktive Pipeline schrittweise.
Fügen Sie zuerst den neuen öffentlichen Schlüssel zur Autorisierungsliste hinzu. Öffnen Sie bei bestehender Sitzung ein zweites Terminal und prüfen Sie die Anmeldung mit dem neuen Schlüssel. Entfernen Sie den alten Schlüssel erst nach erfolgreicher Prüfung und dokumentieren Sie den Zeitpunkt. Löschen Sie den alten Schlüssel nicht vor dem Test, damit der Remote-Zugriff nicht gleichzeitig verloren geht.
Stoppen Sie zunächst laufende Builds, Datenbank- oder Artefaktaufgaben und stellen Sie sicher, dass Caches und Logs gespeichert sind. Starten Sie anschließend über die Konsole neu. Prüfen Sie danach nacheinander SSH, VNC, Datenträgereinbindungen, Runner-Status und Versionen wichtiger Build-Tools.
Prüfen Sie nacheinander Netzwerk, Runner-Prozess, Dienststart, Berechtigungen des Arbeitsverzeichnisses, Registrierungsstatus und Aufgabenparallelität. Bleibt der Runner nach einem Dienstneustart offline, sammeln Sie Knotennummer, Fehlerzeitraum, Dienststatus und relevante Logs und erstellen Sie ein Konsolen-Ticket.
Diese Begriffe beeinflussen Auswahl, Zugriff und Build-Fehleranalyse. Ein gemeinsames Verständnis reduziert Rückfragen in Support-Tickets.
Kopieren Sie Code-Repositories, Build-Artefakte, Signaturmaterial, Logs, Konfigurationsdateien und weiterhin benötigte Cache-Indizes.
Entpacken oder checken Sie wichtige Inhalte stichprobenartig in einer anderen Umgebung aus. Prüfen Sie Dateivollständigkeit, korrekte Berechtigungen und den Zugriff auf erforderliche Schlüssel.
Entfernen Sie öffentliche SSH-Schlüssel, Runner-Registrierungstoken, Deployment-Schlüssel der Repositorys und temporäre Zugangsdaten automatisierter Aufgaben.
Entfernen Sie den Knoten aus CI-Warteschlangen, Monitoring, Artefakt-Uploads und geplanten Aufgaben, damit nach Mietende keine Jobs mehr gesendet werden.
Ein dedizierter Knoten ist kein automatisches Backup. Die Backup-Strategie für Code, Schlüssel, Build-Artefakte und Geschäftsdaten sollte bereits bei der Aktivierung eingerichtet werden.
Nein. Die Inhalte des Knotens gelten nicht als automatisch gesichert. Kopieren Sie Repositorys, Konfigurationen, Schlüssel, Datenbanken, Build-Artefakte und erforderliche Logs entsprechend Ihren Wiederherstellungszielen an einen kontrollierten Speicherort und prüfen Sie die Wiederherstellung regelmäßig.
Dazu gehören mindestens nicht gepushter Code, Signatur- und Build-Konfigurationen, erforderliche Artefakte aus CI-Arbeitsverzeichnissen, Projektabhängigkeitslisten, Umgebungs- und Versionsaufzeichnungen sowie Fehleranalyse-Logs. Führen Sie nach dem Export eine Wiederherstellungsprüfung durch, statt nur das Kopieren der Dateien zu bestätigen.
Repository-Schlüssel, Runner-Token und auf dem Knoten verwendete Dienstzugangsdaten können weiterhin Zugriffsrechte besitzen. Widerrufen oder rotieren Sie diese Zugangsdaten nach dem Export beim jeweiligen Dienst und entfernen Sie Automatisierungsaufgaben, die noch auf den Knoten verweisen.
Nach Ende des Services durchläuft der Knoten einen Prozess zur Zugriffsentziehung und Datenverarbeitung. Sie müssen Export und Prüfung vor Ablauf des Mietzeitraums abschließen und dürfen den anschließenden Verarbeitungsprozess nicht als Datenwiederherstellung einplanen. Für den konkreten Bestellstatus melden Sie sich in der Konsole an und erstellen Sie ein Ticket.
Wählen Sie Modell, Region und Mietzeitraum und schließen Sie die Bestellung ab. Bei Fragen zu bestehenden Bestellungen melden Sie sich in der Konsole an und erstellen Sie ein Ticket mit Knotennummer und Fehlerzeitraum.