Build environments your team controls

We do one thing:
keep build machines out of the queue

We provide dedicated physical Mac minis so iOS and macOS teams can choose their own toolchain, signing environment, and job order. No virtual machines, and your builds never share a queue with other tenants.

Rent a Dedicated Cloud Mac Compare Models & Pricing

Choose daily, weekly, monthly, or quarterly billing. Check real-time availability in the console.

Resource allocation
One tenant per dedicated node
Available models
3 Apple silicon configurations
Locations
6 regions available
Fix the queue first. Automate next.

A merge shouldn’t wait for someone else’s job to finish

We built this service to address two recurring problems with shared CI: teams don’t control their execution resources, and keeping signing environments isolated can be difficult.

Separate waiting from building

After code is submitted, a pipeline may wait for a runner before compilation even begins. Streamlining scripts can reduce build steps, but it can’t make a shared queue serve only your project. It’s hard to tell whether the build is slow or the job simply hasn’t got a runner yet.

We assign an entire physical node to one tenant. Configure your runner to accept jobs from specific projects, and set your own labels, triggers, and job order. Other tenants never enter your build queue.

A dedicated node prevents resource contention between tenants; you still need to manage concurrency across projects on the same node.

Keep signing environments with your team

Certificates, provisioning profiles, Keychain, Xcode paths, and dependency caches all shape your build environment. A cleanup or version change in a shared environment can turn a repeatable archive into a failure that needs manual investigation.

With a dedicated node, your team can define its own directory structure, permissions, and toolchain conventions. Pin Xcode versions, separate test and release jobs, document signing settings, and put those conventions in your pipeline. Your environment is an inspectable, rebuildable engineering asset—not a black box you use once.

A dedicated node is no substitute for backups. Your team should keep copies of source code, signing materials, and release artifacts.

“No more queues” means you don’t have to wait for another tenant to occupy your node. It doesn’t guarantee that any number of jobs will finish simultaneously. Build speed still depends on project size, dependency downloads, memory pressure, and concurrency settings. Test with your own project before choosing a configuration and rental term.

Service principles you can verify

Clear boundaries matter more than big claims

Our service is defined by resource allocation, published pricing, and hardware specifications. These three principles apply to both short-term trials and long-running build nodes.

Dedicated. Never oversold.

Each physical node is assigned to one tenant. CPU, unified memory, and local storage aren’t shared with other tenants or split across virtual machines for resale.

You can run multiple projects, but you control job concurrency. Start with one job as a baseline, then increase runner concurrency while monitoring memory, disk space, and artifact output.

How to assess it: confirm the whole machine is dedicated, then evaluate your concurrency needs.

Published pricing for every tier

All three configurations list daily, weekly, monthly, and quarterly rates. XR Build 16 starts at $21.7/day. For longer rentals, check the listed rate for that term instead of adding up daily prices.

Storage upgrades and Thunderbolt 5 daisy chaining are priced separately. Compare the node rental and any add-ons separately, then review the configuration details before paying.

View Full Pricing

Accurate specs, no hype

The catalog offers three configurations: M4 / 16GB / 256GB, M4 / 24GB / 512GB, and M4 Pro / 64GB / 2TB. A model name alone doesn’t tell you the chip, memory, or storage capacity.

Illustrative task times aren’t performance guarantees for your project. When testing, record clean builds, incremental builds, and archives under consistent code, Xcode, and cache conditions.

How to assess it: compare results using the same project and test conditions.

Choose a tier for your day-to-day workload

Four workflows. The same dedicated boundaries.

These workflow examples reflect common user roles. They aren’t customer case studies or benchmark results. Each starts with the work to be done, then suggests a configuration to test.

Independent developers: build a feature, then ship it

Write SwiftUI locally and test interactions during the day. After you push your code, have a cloud node check out the specified branch, resolve dependencies, run tests, and xcodebuild archiveThen export the signed artifact and upload it to TestFlight using your team’s process.

Start with a single app and low concurrency, and test XR Build 16. Keep your release scripts and failure logs so you can troubleshoot the next day without guessing at the environment.

XR Build 16 · M4 / 16GB / 256GB

Rent XR Build 16

CI teams: connect pull requests to a runner

Check the previous run’s failure logs in the morning, then trigger a GitHub or GitLab self-hosted runner automatically when code is merged in the afternoon. Use labels to separate unit tests from release jobs, manage build steps with Fastlane gym, and keep signing settings consistent across your app, widget, and extension.

If you’re running multiple targets, tests, and caches, start by testing XR Build 24. Increase concurrency gradually to avoid multiple archives writing to the same output directory or competing for signing state.

XR Build 24 · M4 / 24GB / 512GB

Rent XR Build 24

AI experiments: schedule model work around builds

Use MLX in the morning to test small-model inference, noting the model, quantization method, and memory use. Try fine-tuning in the afternoon and save checkpoints, then test Core ML export if your project needs it. Before scheduling builds overnight, stop experiment processes or limit concurrency.

Start testing these workloads with XR Build Pro 64. Its 64GB of unified memory is a specific configuration, not a guarantee that every model will run. First estimate the combined memory use of the model, runtime, and other jobs.

XR Build Pro 64 · M4 Pro / 64GB / 2TB

Rent XR Build Pro 64

Audio and video workflows: queue the work, not your only copy

During the day, use the macOS GUI to check project and media paths, and confirm the software licenses, plugins, and fonts required by Logic or Final Cut. Schedule renders or batch transcodes overnight. When they’re done, export the results, verify the files, and clear temporary caches.

For larger projects, test XR Build Pro 64, but keep external copies of both source media and finished files. Remote access depends on your local network and distance to the node, so test with your actual media and connection before migrating.

XR Build Pro 64 · M4 Pro / 64GB / 2TB

Rent XR Build Pro 64
One catalog. Six regions.

Choose a region, then check your toolchain and delivery details

Every configuration uses an Apple silicon Mac mini, with three tiers available in all six regions. Choose based on your team’s working hours and network conditions, then test remote access with a real connection. A nearby time zone doesn’t guarantee lower network latency.

Singapore

SG · UTC+8

A good fit for Southeast Asian teams coordinating during the day and running jobs overnight. Before migrating, check access to your code repository and dependency sources.

Available

Tokyo, Japan

JP · UTC+9

A good fit for teams working primarily on Japan time. Set the time zone for release jobs in your CI configuration to avoid scheduled tasks using the local default.

Available

Seoul, South Korea

KR · UTC+9

A good fit for teams in South Korea and Northeast Asia reviewing build logs and artifacts. When testing remote desktop, check both text input and file transfers.

Available

Hong Kong

HK · UTC+8

A good fit for teams working across South China and Southeast Asia. When accessing a repository across regions, test connection stability and dependency downloads separately.

Available

US East

US-E · UTC−5 / UTC−4

A good fit for teams on the US East Coast, with convenient overlap with Western Europe. Daylight saving time changes the local offset, so specify the time zone for scheduled jobs.

Available

US West

US-W · UTC−8 / UTC−7

A good fit for teams on the US West Coast coordinating troubleshooting and releases. For cross-time-zone work, keep the UTC offset in your logs to avoid misreading job order.

Available

These statuses reflect the regions currently listed. Check the console for real-time availability when ordering. Nodes run 365 days a year; hardware issues are handled through our fault-response process.

Operations built around delivery, checks, and issue resolution

Hardware issues shouldn’t be buried in build logs. We verify the environment at delivery, distinguish application failures from node faults during use, and clarify data and recovery boundaries before hardware work begins.

  1. Provisioning and delivery checks

    We verify the chip, memory, storage, and region, then prepare macOS and Xcode. After assignment, get SSH and remote desktop connection details in the console. Your team should also check admin permissions, the Xcode path, and project dependencies, then run a small validation job before migrating a production pipeline.

  2. Monitoring and troubleshooting

    We check node connectivity and hardware health. Your team monitors disk space, cache growth, and failed job logs. If something goes wrong, open a support ticket in the console with the node region, model, time of incident, and error details. First distinguish network, toolchain, signing, and hardware issues—don’t assume every failure is a build performance problem.

  3. Hardware response and recovery checks

    Once a hardware issue is confirmed, we coordinate node repair or replacement through a support ticket and explain whether connection details will change and what needs to be redeployed. Your team restores source code, dependencies, and signing setup from backups, then checks toolchain versions and runs a validation build. Hardware replacement isn’t a data backup, and an artifact that hasn’t been verified shouldn’t count as a successful recovery.

Sign in to the console to open a ticket

Find the right tier for your workload

Compare the chip, memory, storage, and billing term, then test with your own project. Start moving your build queue with an archive you can reproduce.

Payment is available only via USDT-TRC20 or Visa / Mastercard / Amex (through Stripe), with billing in USD. Available payment gateways are determined by the response from the backend.

Compare Three Rental Plans Rent a Cloud Mac