SSH and VNC access details are provided with your deployment. Build from the command line and verify signing over remote desktop. Your dedicated physical Mac is yours alone—not a virtual machine.
Already have a node? Note its address, SSH port, username, and desktop access method before following the steps below.
Generate a key on your local machine, authorize its public key for your cloud user, and give the node a fixed alias. Use the same connection for rsync, Fastlane, and your runner.
The following 192.0.2.10 is a documentation example address, macbuild is an example username, and 22 is an example SSH port. Replace all three with the values provided in your console. Never paste your private key, password, or complete access credentials into a support ticket.
Run this locally. A separate filename makes it easy to revoke access and avoids overwriting your default key. Set a passphrase when prompted. In automation, grant access through a managed secrets solution—never store the private key in your repository.
ssh-keygen -t ed25519 -f ~/.ssh/xcr_build -C "xcr-build"
ssh-add ~/.ssh/xcr_build
ls -l ~/.ssh/xcr_build.pubFiles ending in .pub contain the public key, which you can install on the node. Files without that suffix contain the private key; keep them local or in a controlled CI secrets store.
If ssh-copy-id is installed locally, use the provided username and port to install your public key. On first connection, check the displayed host fingerprint against your deployment details. If you don't have a trusted fingerprint, confirm it through a console support ticket—don't skip verification.
ssh-copy-id -i ~/.ssh/xcr_build.pub -p 22 macbuild@192.0.2.10
ssh -i ~/.ssh/xcr_build -p 22 macbuild@192.0.2.10Your local macOS environment may not include ssh-copy-id. If password login is allowed for your deployment, use the standard SSH command below. If only key-based authentication is allowed, authorize your public key through the deployment process—don't keep retrying with a password.
cat ~/.ssh/xcr_build.pub | ssh -p 22 macbuild@192.0.2.10 \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'If the host key changes after a node rebuild, first confirm the rebuild record and new fingerprint, then update your local record. Don't hide the issue by disabling host verification.
Add the following to your local ~/.ssh/config. The alias saves you from having to remember the node address. If the address changes, update it here; your scripts can keep using xcr-build.
Host xcr-build
HostName 192.0.2.10
User macbuild
Port 22
IdentityFile ~/.ssh/xcr_build
IdentitiesOnly yes
ServerAliveInterval 30
ServerAliveCountMax 3Run these read-only checks to verify the actual OS version, selected Xcode version, and available disk space. Confirm the environment before installing dependencies or registering a runner, so the wrong versions don't make it into your pipeline.
ssh xcr-build
sw_vers
xcode-select -p
xcodebuild -version
df -h "$HOME"Remote desktop is the easiest way to set up signing certificates for the first time, check Keychain permissions, or review Xcode settings. Once everything is verified, move routine steps back to the command line.
On your local Mac, open Screen Sharing and enter the desktop address and port from your deployment details. Alternatively, in Finder, choose Go → Connect to Server and enter the VNC address provided.
Your desktop and SSH credentials may differ. Use the corresponding details from your console, and never use your SSH key file as a VNC password.
On other operating systems, use a VNC client that supports the authentication method provided. Enter the host, port, and authentication details. Don't expose the desktop service directly to the public internet.
If your deployment details allow SSH access to the node's local VNC service, you can create a tunnel. The example below works only when the remote service listens on 127.0.0.1:5900 ; use the port specified in your deployment details.
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:5901:127.0.0.1:5900 xcr-buildKeep this terminal session open, then connect your local VNC client to 127.0.0.1:5901. The local port is bound to the loopback address only. When you're done with the desktop session, press Control-C to close the tunnel.
Verify that Xcode launches and the expected version is selected; that the build user can access the signing certificate and its private key; and that the provisioning profile matches the project's Bundle Identifier, Team, and export method. Don't include certificate passwords in screenshots.
Migrate in this order: data, toolchain, then CI integration. First, create one manual archive from the same source commit, then let the runner take over. Don't change Xcode, dependency versions, and signing settings all at once.
Keep your source code and lockfiles in a dedicated working directory. Run rsync in dry-run mode first and verify the destination path. Don't sync your entire home directory or upload certificates, private keys, and local environment files by default.
DerivedData is a rebuildable cache. Reuse it only when the Xcode version, dependencies, and source environment are compatible. If paths or module caches cause issues, clear it and do a clean build first.
Use xcode-select -p and xcodebuild -version to check the versions. To switch Xcode, use a path that exists on the node, then verify the SDK required by your project.
Keep Podfile.lock, Package.resolved, and Gemfile.lock. Run CocoaPods, SPM, and Fastlane in the versions pinned by your project. Import certificates and provisioning profiles separately, then verify private-key access.
Create a self-hosted runner registration in your GitHub or GitLab project, then install it using the platform's macOS instructions. Use the registration token only during controlled setup; never put it in your repository or build logs.
Add labels for the runner's purpose and toolchain, such as macos, ios-build. Initially, allow signing jobs only from trusted branches and limit concurrency. Then adjust based on memory, disk usage, and job logs.
rsync -avzn --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/
rsync -avz --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/The first command includes -n and shows the planned changes without transferring files. Review the output, then run the second command. The example omits --delete to avoid accidentally removing remote files during the initial migration. If your project has other directories containing secrets, add exclusion rules for them first.
Record the source commit, Xcode version, dependency lockfiles, scheme, export settings, runner labels, and artifact path. Test clean and incremental builds separately before deciding whether to copy caches. The example commands on this page aren't performance tests and don't guarantee a fixed build time.
When troubleshooting, distinguish the connection protocol, execution environment, and build cache. Pinpointing the layer where a failure occurs is more helpful than simply saying, “I can't connect to the machine.”
Three machine tiers cover all six nodes. For interactive remote desktop work, start with a location near the main users, then check the paths for source control, dependency downloads, and artifact uploads. Team time zones can help narrow the options, but can't replace real network testing.
SG · UTC+8
A good fit for teams whose main collaboration hours fall on Southeast Asian workdays. Test desktop responsiveness from your location first, then check dependency downloads and artifact uploads.
JP · UTC+9
A good fit for teams working primarily on Japan time. Have anyone who needs to debug the GUI test the connection first, then schedule automated jobs.
KR · UTC+9
A good fit for teams working primarily on Korea time. Check that your corporate network can reach the provided ports, and test the stability of long-running SSH sessions.
HK · UTC+8
A good fit for teams working mainly with colleagues in southern China and nearby time zones. Test desktop responsiveness, source-code pulls, and cache transfers separately; a single ping isn't enough to draw conclusions.
US-E · UTC−5 / UTC−4
A good fit for North American Eastern Time and a candidate for cross-time-zone collaboration. Daylight saving time applies; specify the time zone in handovers instead of giving a time alone.
US-W · UTC−8 / UTC−7
A good fit for North American Pacific Time. For teams across time zones, overnight archives can follow daytime commits from colleagues elsewhere—but signing-job concurrency still needs to be controlled.
Nodes run continuously 365 days a year. Check the console for current availability. When troubleshooting a connection, include the node, machine tier, protocol, exact error text, and reproduction steps in a console support ticket. Redact credentials, but keep the error details that help identify the issue.
Aim to get connected in five minutes: verify the host, test SSH, and open the desktop. Once the network and authentication are confirmed, migrate your build environment. Schedule full pipeline validation separately for your project.
Rent from $21.7/day. Payment is available only via USDT-TRC20 or Visa, Mastercard, or Amex through Stripe. Charges are in USD; available payment gateways are confirmed by the backend.