Team und Betriebsrahmen

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
NODE ACCEPTANCE RECORD Abnahmeprotokoll des physischen Nodes
READY
ORB / M4 / PHYSICAL Dedizierte Zuweisung
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
Kalibrierstand-ID ORB-CAL-04
Leistungsdefinition

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.
Für wen wir bauen

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?

iOS / macOS

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
CI/CD

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
KI-Experimente

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
Betrieb in vier Regionen

Ü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.

Bereitstellungszugang 4 REGIONEN / 3 KONFIGURATIONEN
SG Im Angebot buchbar

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
JP Im Angebot buchbar

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
KR Im Angebot buchbar

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
HK Im Angebot buchbar

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
Grundsätze für den Hardwarebetrieb

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Für technische Fragen benötigen wir vier Angaben

Node-ID, Zeitraum des Auftretens, Reproduktionsschritte sowie anonymisierte Befehlsausgaben oder Screenshots.

Supportweg ansehen
Design- und Engineering-Grundsätze

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.

A

Echte Spezifikationen

Modellname, Chip, Arbeitsspeicher und Speicher sind eindeutig zugeordnet; Preise werden klar nach Tag, Woche, Monat und Quartal angegeben.

B

Statusprotokolle

Bereitstellung, Verbindung, Bestellung und Supportfortschritt lassen sich in der Konsole verfolgen, damit Statusangaben und tatsächlicher Node übereinstimmen.

C

Terminalausgaben

Build- und Diagnosehinweise bewahren nach Möglichkeit Befehle, Rückgabewerte und Entscheidungskriterien, damit Teams sie reproduzieren können.

D

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.

SPEC

Spezifikationen vor Adjektiven

Zuerst nennen wir M4 oder M4 Pro, Arbeitsspeicher, Speicher und Region; anschließend besprechen wir passende Workloads.

STATE

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.

TRACE

Aufzeichnungen vor Schlussfolgerungen

Mit Zeitraum, Befehlsausgaben, Protokollen und Reproduktionsschritten entsteht eine nachvollziehbare Untersuchungskette statt einer nicht überprüfbaren Einschätzung.

Zusammenarbeit und Kontakt

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.

Teambedarf

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.

Regionale Partnerschaft

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.

Medienanfrage

Ü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.