This guide is for developers planning to run Xcode or macOS CI on a dedicated physical Mac. Choose a model and location, get your connection details, check the toolchain, then run a reproducible build.
Commands and responses on this page are examples; they don't mean your project has been configured. Check the console for actual connection details, device status, and delivery progress.
Check these four things before sending your project to a remote node.
Example checklist · Your order and console show the actual configuration
Five starting points, ordered by workflow. If you already have an order, jump straight to connecting or troubleshooting.
Check the model, location, rental term, and order status to find out how to get your connection details.
See setup steps → 02Check your SSH settings and choose between command-line tasks and work that needs a graphical desktop.
See connection examples → 03Check out your project, verify Xcode and its dependencies, then confirm the artifacts are where you expect.
See build steps → 04Check the runner identity, job tags, and signing permissions before starting automated builds.
See setup checks → 05Review your rental term and add-ons. Manage existing orders and support tickets in the console.
See how to manage →The times shown are for an example workflow, not a delivery estimate. Check your order and device status in the console for delivery progress and connection details.
About 4 minutesExample task time; excludes device delivery
Choose an available configuration based on your project's memory and storage needs, then select a location that suits your team's time zones and location. Check the available options before ordering.
Review the rental term and any optional add-ons, then place your order. Availability and supported payment gateways are shown in real time in the console.
Wait for the device to show as ready. In the console, find the address, account, and connection instructions for your instance. Don't copy credentials from public examples.
Connect, then verify the current account, available disk space, and Xcode toolchain version. If anything doesn't match, stop automated jobs and record the output.
Use SSH to check out code, run builds, and inspect logs. To use the Xcode graphical interface, follow the remote desktop instructions for your instance.
$ ssh developer@192.0.2.10
Last login: example session
$ xcodebuild -version
Xcode
Build version: example
$ xcodebuild -workspace App.xcworkspace \
-scheme App -configuration Release \
-destination 'generic/platform=iOS' build
** BUILD SUCCEEDED **
$ fastlane build
[example] Build completed
[example] Artifact: ./build/App.ipaLocal Mac → Cloud Mac: make sure your source code and dependencies are available, verify the toolchain, then point CI jobs to the new runner.
Start by checking out code from version control. Identify any configuration files and build assets that aren't tracked. Review sensitive materials before transferring them, and never put credentials in your repository or logs.
Done when: The expected project files are in the cloud directory, and access to sensitive files has been checked.
Note the versions of Xcode, command-line tools, and package dependencies used locally. Resolve dependencies again in the cloud, then check the project's minimum OS and architecture requirements.
Done when: The same Scheme starts a command-line build, and any version differences are documented.
Give the new node its own runner identity and job tags. Start with a validation job that needs no publishing credentials, then check the permissions required for packaging.
Done when: Test jobs run on the intended node, and logs and artifacts can be traced.
Run a complete manual build first and save the versions, command, and error output. Then decide whether to hand it off to automation. Configure signing and dependencies for each project.
Get the repository using a method approved by your team. Verify the target commit, submodules, and lockfiles; run git status first so you don't assess a build against unknown changes.
Decide who manages and can access certificates, provisioning profiles, and any required keys. Never put private keys in a public repository or paste full credentials into a support ticket.
First, check xcodebuild -version and the project's Scheme, then run the build command your project actually uses. Record the exit code and first actionable error, not just the end of the log.
Check the artifact files, their size, and output path, then archive or transfer them using your team's process. A success message doesn't replace checking the actual files and signing results.
To set up a GitLab CI macOS Runner, install and register it on the node, link it to a project with the required permissions, and use job tags to control where jobs run. Follow your team's CI policies for registration, access scope, and concurrency.
Your first validation job can simply print the system and Xcode versions. This confirms that the job reached the intended Apple Silicon node, but doesn't verify that signing, dependency downloads, or publishing are ready.
fastlane can be part of your existing packaging workflow, but it doesn't replace project-specific checks for permissions, signing, and versions.
Before ordering, confirm the model, location, and rental term—daily, weekly, monthly, or quarterly—and whether you need SSD expansion or Thunderbolt 5 clustering. Add-ons are priced separately; your order confirmation shows your final selections and total.
Pay with USDT-TRC20 or Visa, Mastercard, or Amex via Stripe. All charges are in USD. Available payment gateways are shown in the console.
Check the order ID, rental term, location, add-ons, and device status in the console. For billing questions about an existing order, sign in and submit a support ticket with the order ID and details to check. Don't share payment credentials in public messages.
Open consoleBefore contacting the team, note when the issue occurred, the instance's order ID, what you did, and any redacted error details. Never send passwords, private keys, signing certificates, or unredacted project files.
Check the device status, address, and account in the console, then check your local network and connection method. Record the command, error type, and time. Redact any credentials.
Record the commit, Xcode version, Scheme, full command, and first actionable error. Identify whether the failure occurred during dependency retrieval, compilation, signing, or export—don't just share the final “build failed” line.
Check space used by the project directory, build caches, and artifacts. Confirm which files your team can safely remove. Include redacted disk usage and error paths, and avoid deleting artifacts that still need to be archived.
Check the current execution account, file ownership, and access to the repository or signing materials. Record the affected path and error; don't work around the issue by broadening permissions on all files.
Compare the three model tiers and rental terms, then check current availability in the console. Once connected, start with a reproducible validation build.