Choose your region, model, and billing term first, then harden credentials, verify SSH, initialize the desktop, and run your first Xcode build. Keep an auditable status record at every step.
Choosing a node is about more than the chip. Region, access method, toolchain versions, and team ownership all shape the first hour after provisioning.
Choose between Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong based on proximity to key developers or artifact storage. Consider repository and dependency-source network paths—not just where you are located.
SG · JP · KR · HKStart with Orb M4 16 for lightweight builds; consider Orb M4 24 for larger dependency graphs and parallel jobs; choose Orb M4 Pro for memory-intensive builds or local AI experiments.
3 configurationsChoose daily or weekly billing for short validation runs, or monthly or quarterly billing for stable pipelines. Record your internal acceptance date before renewing, so production releases never depend on an unattended temporary order.
Daily · Weekly · Monthly · QuarterlyPrepare an Ed25519 public key dedicated to this node. Keep the private key only on authorized devices or in a controlled key system. Never reuse a personal everyday key as a shared team credential.
Ed25519 recommendedAssign a node owner, CI administrator, and incident contact. Each person should use a separate key, with join, change, and revocation records—never one credential for the whole team.
One credential per personPin macOS, Xcode, Command Line Tools, Ruby, Node, CocoaPods, and dependency-manager versions in advance. Record the requirements in the repository and verify each one during node initialization.
Reproducible versions requiredThe console shows available regions for each model. Regular catalog combinations can be ordered; actual availability is determined by the console in real time.
Orb M4 16 includes M4, 16GB RAM, and 256GB storage; Orb M4 24 includes M4, 24GB RAM, and 512GB storage; Orb M4 Pro includes M4 Pro, 64GB RAM, and 2TB storage.
Choose Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong; terms are daily, weekly, monthly, or quarterly. Record the region code and renewal date in your internal asset register.
Confirm the model, region, term, and add-ons before placing the order. The console provides the node address, initial access details, and service status; do not forward them through unauthorized channels.
Initial access details are only for establishing the first controlled connection. Do not import production repositories or signing materials until key verification, access changes, and recovery records are complete.
Use developer keys for interactive troubleshooting and runner keys only for pipeline-required permissions. Revoke a departing member’s public key instead of replacing a credential shared by everyone.
Before changing network, SSH, or desktop-session settings, keep the current working session open and have a second owner review the recovery information in the console.
Never skip host-fingerprint verification. Get the address and port from the console, then compare the trusted fingerprint with the team-approved delivery record.
# Set variables only after obtaining the console address
export NODE_HOST="NODE_ADDRESS"
export NODE_PORT="22"
# Correct permissions for the dedicated private key
chmod 600 ~/.ssh/orbvps_node
# Read and display the host fingerprint, then compare it with the delivery record
ssh-keyscan -p "$NODE_PORT" "$NODE_HOST" \
| ssh-keygen -lf -
# Initiate the first connection
ssh -p "$NODE_PORT" \
-i ~/.ssh/orbvps_node \
nodeadmin@"$NODE_HOST"
# Confirm hardware, system, and disk status after login
$ uname -m
arm64
$ sw_vers
$ sysctl -n machdep.cpu.brand_string
$ df -h /
$ uptimeUse the desktop to configure display settings, system preferences, and Xcode’s first-run interactions. Connection credentials are not published; view the address and access details after provisioning.
After completing each setting, disconnect and reconnect once to confirm it remains effective in a new session.
Choose a resolution suited to your network and screen. If text is too small or latency is noticeable, lower the resolution first, then assess the network path.
Standardize the system language, regional format, and time zone across the team so build logs, date output, and automation scripts remain consistent.
Confirm that locking the screen will not interrupt tasks that must keep running, while still restricting unauthorized access. Validate interactive sessions and CI jobs separately.
Intentionally disconnect a desktop session, reconnect, and confirm that the desktop state, resolution, and running processes are as expected.
Migrate in three stages: move verifiable data, pin the toolchain, then connect CI. Do not copy repositories, dependencies, and automation settings all at once without checks.
Move only the required repositories, dependency lockfiles, build scripts, and test data. Exclude temporary caches, old artifacts, and orphaned files; then verify repository status and key-file hashes.
Install Xcode, Command Line Tools, and dependency managers as required by the repository. Save the actual version output in the baseline record; never substitute “latest” for a specific version.
After registering the self-hosted runner, run a controlled test job first. Confirm that failure logs, cache cleanup, and recovery steps work before gradually enabling production branches.
Migration acceptance standard:The same commit must build on both the local and cloud Macs with the recorded toolchain, produce matching key test results, and be redeployable from the documentation.
The first build is not about the shortest runtime. It proves that the toolchain, dependencies, permissions, and output paths are reproducible.
Confirm that the selected developer directory, Xcode version, and available SDK match the project requirements.
After accepting the Xcode license, install Ruby, Node, CocoaPods, and other project dependencies strictly from the lockfiles.
Explicitly set the workspace, scheme, and configuration, and save the complete standard output to a separate log file.
Record the commit ID, toolchain versions, start and end times, exit code, and artifact location for comparison with future changes.
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
Xcode <PROJECT_VERSION>
$ sudo xcodebuild -license accept
$ bundle install
$ bundle exec pod install
$ mkdir -p build-logs
$ set -o pipefail
$ xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
clean build \
| tee build-logs/first-success.log
** BUILD SUCCEEDED **After adding the self-hosted runner, use dedicated labels and a test branch to limit its scope, then gradually enable production builds.
The job should only report the environment, restore dependencies, run unit tests, and perform one build without publishing. Confirm correct label routing, complete logs, cleanable caches, and stoppability on failure before enabling production branches.
Add the results below to the team runbook. The node can run year-round, but builds still require clear data, monitoring, and response ownership.
Keep copies of repositories, build configuration, key-recovery information, and required artifacts outside the node, and complete one recovery test.
Recovery verifiedAt minimum, record free disk space, build exit codes, job wait time, and runner online status, with thresholds for anomalies.
Metrics have an ownerBoth the primary and backup contacts can access node records, build logs, and console support tickets, with the handoff path documented.
Primary and backup contacts assignedRecord the order term and internal confirmation date; do not rely on one person’s memory. Assess active job windows before changing the configuration.
Term recordedList user and runner keys with their permissions so each can be revoked independently without affecting other members.
One record per itemKeep the node ID, incident time, reproduction steps, and sanitized logs ready to submit; authorized members must be able to file a console support ticket.
Materials ready to submitChoose a model, region, and term, then complete secure access, the first build, and CI acceptance using this guide after provisioning.