- Hardwareidentität
- Chip, Arbeitsspeicher und lokaler Speicher entsprechen einzeln der bestellten Konfiguration Bestanden
- Systembasis
- Start, Netzwerk, Laufwerk und Remote-Verbindung wurden geprüft Bestanden
- Zugriffsgrenzen
- Zugangsdaten werden pro Node bereitgestellt; Berechtigungsänderungen werden protokolliert Bestanden
- Betriebsdaten
- Status, Spezifikationen und Störungsdaten werden in überprüfbaren Aufzeichnungen dargestellt Bestanden
Remote-Builds auf einen klar zugeordneten Mac verlagern
OrbVPS konzentriert sich auf dedizierte physische Apple-Silicon-Nodes. Jede Bestellung entspricht einem remote nutzbaren Cloud-Mac, statt kritische Build-Aufgaben in einen nicht transparenten Ressourcenpool zu verlagern.
Wir unterstützen Entwicklungsteams, die Toolchains, Caches, Runner-Status und Zugriffsrichtlinien langfristig erhalten müssen. Nach Auswahl von Modell, Region und Laufzeit bleibt die Node-Konfiguration eindeutig, sodass sich Betriebsprobleme anhand derselben Hardware und Protokolle weiter analysieren lassen.
- 3 Tarife
- Festes Angebot
- 4
- Node-Regionen in Asien
- 1:1
- Jede Bestellung entspricht einem physischen Node
Wir liefern physische Nodes, keine vagen Rechenkontingente
„Cloud“ beschreibt die Art der Verbindung und Verwaltung, „physischer Node“ die tatsächliche Hardware. Beides muss klar benannt werden.
Eine Bestellung, ein dauerhaft kontrollierbarer Cloud-Mac
Alle drei OrbVPS-Konfigurationen nutzen Apple Silicon: Orb M4 16, Orb M4 24 und Orb M4 Pro. Jede Variante hat feste Spezifikationen mit eindeutigem Chip, Arbeitsspeicher und lokalem Speicher. Echte Hardwaredaten werden nicht durch den Begriff „elastische Ressourcen“ ersetzt.
Die Nodes lassen sich per SSH über die Befehlszeile nutzen oder über die grafische Oberfläche bedienen. Build-Verzeichnisse, Dependency-Caches, Arbeitsbereiche von self-hosted runnern und Toolchain-Versionen bleiben auf demselben physischen Node erhalten. So muss die Umgebung nicht für jede Aufgabe neu erstellt werden.
Ablauf von der Bestellung bis zum ersten Build- Cloud-Mac
- Ein über das Netzwerk remote genutztes und verwaltetes macOS-Gerät für kontinuierliche Builds, Tests und kontrolliertes Arbeiten aus der Ferne.
- Physischer Node
- Die Bestellung wird einem eindeutig identifizierbaren Apple-Silicon-Gerät zugeordnet; Spezifikation und Region werden bei der Bestellung festgelegt.
- Dedizierter physischer Rechner
- Die Node-Ressourcen werden nicht parallel mit anderen Mietern geteilt. Toolchain, Cache und Laufzeitstatus bleiben unter der Kontrolle des aktuell mietenden Teams.
- Keine virtuelle Maschine
- Die Bereitstellung wird nicht mit virtuellen CPUs, dynamischen Speicheranteilen oder temporären Instanzen beschrieben.
Entwicklungsteams, die eine konstante Umgebung brauchen
Für unterschiedliche Workloads gilt derselbe Maßstab: Lässt sich die Umgebung festlegen, reproduzieren und überwachen und nach einem Problem weiter untersuchen?
Entwickler: feste Xcode- und Dependency-Basis
Geeignet für Einzelpersonen und kleine Teams, die Xcode-Versionen, CocoaPods- oder Swift-Package-Caches, DerivedData und Build-Skripte dauerhaft behalten möchten.
- Eine reproduzierbare xcodebuild-Basis einrichten
- Repository, Dependencies und Build-Artefakte erhalten
- Unterschiedliche Aufgaben per SSH und über die grafische Oberfläche erledigen
Plattformteams: Runner eindeutig zuordnen
Geeignet für Engineering-Teams, die macOS-Builds in bestehende Pipelines integrieren und Parallelität, Caches, Arbeitsverzeichnisse, Zugangsdaten sowie die Reihenfolge der Fehlerbehebung klar verwalten möchten.
- self-hosted runner und Job-Tags bereitstellen
- Freien Speicher, Prozesse und Netzwerkstatus überwachen
- Fehler anhand der Protokolle des festen Nodes weiter untersuchen
Experimentiernutzer: Prozessstatus auf demselben Node bewahren
Geeignet für Nutzer, die kleine Modelle, Datenverarbeitung oder Automatisierungsexperimente ausführen und Unified Memory, Temperatur, Speicher sowie Aufgabenausgaben direkt prüfen müssen.
- Modelle, Umgebung und Datenverarbeitungsskripte erhalten
- Ressourcenstatus und Ausgaben jeder Experimentrunde protokollieren
- Grafische und Befehlszeilenergebnisse in der Remote-Sitzung prüfen
Über vier asiatische Nodes auf denselben Bereitstellungsprozess zugreifen
Das Angebot umfasst Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Alle drei Modelle sind in jeder der vier Regionen buchbar; die tatsächliche Verfügbarkeit liefert die Konsole in Echtzeit.
Singapur
Regionaler Zugang für Teams in Südostasien, die Repositorys, Build-Aufgaben und Zusammenarbeit innerhalb ähnlicher asiatischer Arbeitszeiten koordinieren möchten.
- Regionale Funktion
- Zusammenarbeit in Südostasien
- Modelle im Angebot
- 3 Varianten
Japan (Tokio)
Für Entwicklungsteams in Japan und der Umgebung, die tägliche Xcode-Builds, Testaufgaben und lokale Entwicklungsumgebungen kontinuierlich zusammenführen möchten.
- Regionale Funktion
- Zusammenarbeit in Japan und Ostasien
- Modelle im Angebot
- 3 Varianten
Südkorea (Seoul)
Für Entwicklungszusammenarbeit in Südkorea und Nordostasien – mit klarer regionaler Auswahl für kontinuierliche Integration, Testumgebungen und den Remote-Betrieb durch Teams.
- Regionale Funktion
- Zusammenarbeit in Nordostasien
- Modelle im Angebot
- 3 Varianten
Hongkong
Für grenzüberschreitende Entwicklungsarbeit zwischen Südchina und Südostasien, wenn Teams Repositorys, Build-Nodes und Remote-Sitzungen zentral verwalten möchten.
- Regionale Funktion
- Zusammenarbeit in Südchina und Südostasien
- Modelle im Angebot
- 3 Varianten
Von der Abnahme bis zum Mietende: klare, umsetzbare Grenzen
Die Nodes laufen 365 Tage im Jahr kontinuierlich. Wenn eine dringende Maßnahme Ihre Mitwirkung erfordert, erläutern wir Auswirkungen, Schritte und Prüfergebnisse in der Konsole und im Support-Ticket.
-
01
Node-Abnahme
Chip, Arbeitsspeicher, lokaler Speicher, Netzwerkschnittstellen und Startstatus werden geprüft. Erst nach erfolgreicher Remote-Verbindung und grundlegender Laufwerksprüfung geht der Node in die Bereitstellung.
-
02
Zustandsüberwachung
Wir überwachen Erreichbarkeit, Laufwerksstatus, Temperatur und wichtige Betriebskennzahlen. Die Überwachung dient dem Erkennen von Hardware- oder Netzwerkproblemen und liest keine Inhalte von Benutzer-Repositorys oder Geschäftsdaten.
-
03
Benachrichtigung bei Störungen
Bei dringenden Fällen, die einen Neustart, eine Datenmigration oder eine Wiederherstellungsprüfung erfordern, nennt das Konsolen-Ticket den betroffenen Umfang und die anschließenden Prüfschritte.
-
04
Zugriffskontrolle
Zugangsdaten werden pro Node verwaltet. Nach der ersten Verbindung sollten Sie eigene SSH-Schlüssel einrichten, autorisierte Mitglieder beschränken und Zugangsdaten bei Änderungen an Personal oder Automatisierungsaufgaben zeitnah rotieren.
-
05
Verarbeitung nach Mietende
Migrieren Sie zunächst Code, Schlüssel, Build-Artefakte und Geschäftsdaten und prüfen Sie die Sicherung. Nach Ende der Mietdauer wird der Node-Zugriff entzogen und die Daten gemäß dem Prozess zum Mietende verarbeitet.
Node-ID, Zeitraum des Auftretens, Reproduktionsschritte sowie anonymisierte Befehlsausgaben oder Screenshots.
Weniger Versprechen, mehr überprüfbare Belege
Wir ersetzen Produktfakten nicht durch vage Aussagen über Ressourcenpools. Seite, Konsole und Supportantworten sollen dieselben Modelle, Regionen, Statusangaben und Vorgangsprotokolle zeigen.
Die Leistung hängt von Projektumfang, Dependencies, Toolchain und Netzwerkweg ab. Deshalb zeigen wir bevorzugt Betriebsbedingungen und Prüfmethoden statt eines pauschalen Ergebnisses ohne Kontext. Bei Störungen beginnt der Support ebenfalls mit Node-ID, Zeitraum und Originalausgabe.
Echte Spezifikationen
Modellname, Chip, Arbeitsspeicher und Speicher sind eindeutig zugeordnet; Preise werden klar nach Tag, Woche, Monat und Quartal angegeben.
Statusprotokolle
Bereitstellung, Verbindung, Bestellung und Supportfortschritt lassen sich in der Konsole verfolgen, damit Statusangaben und tatsächlicher Node übereinstimmen.
Terminalausgaben
Build- und Diagnosehinweise bewahren nach Möglichkeit Befehle, Rückgabewerte und Entscheidungskriterien, damit Teams sie reproduzieren können.
Screenshots der Oberfläche
Bei grafischen Aufgaben erklären wir Probleme anhand der tatsächlichen Oberfläche und der Schrittfolge, statt Funktionsnachweise durch dekorative Bilder zu ersetzen.
Spezifikationen vor Adjektiven
Zuerst nennen wir M4 oder M4 Pro, Arbeitsspeicher, Speicher und Region; anschließend besprechen wir passende Workloads.
Status vor Vermutungen
Konfigurationen im Angebot sind buchbar; die tatsächliche Verfügbarkeit liefert die Konsole in Echtzeit. Temporäre Statusangaben werden nicht auf Marketingseiten erfunden.
Aufzeichnungen vor Schlussfolgerungen
Mit Zeitraum, Befehlsausgaben, Protokollen und Reproduktionsschritten entsteht eine nachvollziehbare Untersuchungskette statt einer nicht überprüfbaren Einschätzung.
Modell, Region und Nutzung klar benennen
Team-Bestellungen, regionale Partnerschaften und Medienanfragen werden über die Kontaktseite oder support@orbvps.com eingereicht. Bei technischen Fragen zu bestehenden Bestellungen melden Sie sich in der Konsole an, erstellen ein Ticket und geben die Node-ID an.
Planung mehrerer Nodes und kontinuierlicher Builds
Nennen Sie voraussichtliche Node-Anzahl, Zielmodell, Einsatzregion, Mietdauer, parallele Aufgaben und Toolchain-Anforderungen. Wir prüfen die umsetzbare Lösung anhand der drei verfügbaren Konfigurationen.
Auf Basis der vier bestehenden Regionen besprechen
Der Partnerschaftsrahmen umfasst Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong. Teilen Sie Zielgruppe, geplante Zusammenarbeit und zu prüfende Betriebsbedingungen mit.
Überprüfbare Produktinformationen anfordern
Geben Sie Medium, Themenschwerpunkt, Frist und benötigte Fakten an. Produktspezifikationen, Zahlungsarten und Regionsangaben entsprechen dem aktuell öffentlichen Angebot.
Den nächsten Build auf einem klar zugeordneten physischen Node ausführen
Wählen Sie Orb M4 16, Orb M4 24 oder Orb M4 Pro und anschließend einen Node in Singapur, Japan (Tokio), Südkorea (Seoul) oder Hongkong.