Dedicated build lanes for teams

Move your queued builds
to a dedicated Mac

An Apple Silicon M4 Mac mini, dedicated to a single customer. Run PR checks, nightly archives and remote Xcode sessions on the same controlled toolchain, without sharing CPU resources with other tenants.

Rent a macOS build node See the 3-step migration

2 M4 configurations · From $20/day · Dedicated physical machine, not a VM

Your team’s build lane
  1. PRChecks
  2. TestBuild & unit tests
  3. ArchiveArchive & distribute

The entire machine is dedicated to you. Your runner configuration controls concurrency and priority within your team.

Match workloads to resources

Make room for four types of work

Start by defining the machine’s main role, then choose memory and storage. Interactive development, release archives and model experiments can use the same type of node, but should not compete for resources without limits.

1 · PR checks

Build and test every commit

Ideal for single-project CI, smaller SwiftUI apps and teams moving builds off an office machine. Each PR can trigger a checkout, restore dependencies, run unit tests and report results back to your existing CI platform.

Start with Merge M4 S: Apple Silicon M4, 16GB RAM / 256GB SSD. The machine is dedicated to one customer, so other tenants cannot take up its CPU cores during builds. Set a concurrency limit for your own jobs to prevent multiple builds from competing for memory.

Start with three steps

  • Pin the repository commit, dependency lockfile and Xcode version.
  • Build and run unit tests for one scheme.
  • Track queue, build and test times separately to find bottlenecks.

When to scale up: consider the 24GB configuration if multiple targets or parallel simulator tests significantly increase memory use. Don’t estimate the number of machines from team size alone.

Rent Merge M4 S
2 · Daily releases

Run nightly archives on a release node

For teams that build test packages daily, schedule archives and use Fastlane to automate releases. Keep your existing lane and combine archiving, export and TestFlight upload into a single release job.

We recommend Merge M4 L: Apple Silicon M4, 24GB RAM / 512GB SSD. Compared with the entry configuration, it provides more memory and local storage for dependencies across multiple projects and the simulator runtimes you need. Actual build performance depends on your project and cache state.

Keep release jobs separate

  • Use a dedicated runner label so routine PRs don’t take up archive capacity.
  • Inject certificates, provisioning profiles and distribution credentials through CI secrets.
  • Save logs and build artifacts after a successful archive, then clean up local files according to your policy.

The node runs 365 days a year. Configure failure notifications and retries in your CI platform to handle scheduled jobs and uploads that don’t complete successfully.

Rent Merge M4 L
3 · Remote development

Use Xcode without a local Mac

Use VNC screen sharing to work with the macOS desktop, inspect projects in Xcode, debug build errors and run simulators. Use SSH for command-line builds, file transfers and runner management.

If you need Xcode, simulators and dependency tools open at the same time, consider Merge M4 L. The desktop and CI jobs share resources on the same physical machine, so schedule interactive debugging and automated archives at different times or use separate nodes.

Test the connection first

  • Get the instance connection details from the console and check SSH and VNC access.
  • Lower the remote display resolution and check that input and window interactions respond well.
  • Test Xcode and the simulator with a small project before syncing your main project.

What to expect: cloud-based development works well for builds, code signing and simulator tests, but it can’t directly access an iPhone connected to your desk. Keep any steps that require a locally connected device on a local machine.

SSH & VNC setup guide
4 · AI experiments

Set a resource budget for MLX

Run local MLX inference on Apple Silicon to test quantised models and small-model fine-tuning workflows. Start with a smaller model to establish a working baseline, then increase context length, batch size and training data gradually.

We recommend Merge M4 L with the +2TB SSD add-on for model weights, datasets and checkpoints. The 24GB RAM is your memory budget; the additional SSD provides file storage. One cannot replace the other.

Measure peak memory, not just model size

  • Record peak memory during model loading, inference and fine-tuning.
  • Leave extra disk space for downloads, unpacked files and checkpoints.
  • Pause concurrent CI jobs on the same machine to avoid resource contention affecting your experiments.

Whether a model fits in memory depends on quantisation, context length and how you run it. The +2TB SSD add-on does not increase memory or guarantee that every model will run.

Configure Merge M4 L + storage

One dedicated machine doesn’t mean unlimited concurrency. Set a per-machine concurrency limit, then monitor peak memory, free disk space and queue times. If release jobs need a predictable time slot, split runner responsibilities rather than putting everything in the same queue.

Migrate in dependency order

Reproduce the environment before switching CI

Don’t retire your existing build machine straight away. Move data, align the toolchain and connect CI in that order. Run the same commit in both environments and compare artifacts and logs before switching production jobs.

  1. 01 · Data

    Move the project, signing assets and caches separately

    Check out the project and submodules from your repository, and keep the dependency lockfile. Don’t copy the entire local working directory and assume it will provide a reproducible environment.

    • Transfer certificates and provisioning profiles through a controlled channel; store passwords in CI secrets.
    • Key caches by Xcode version, dependency lockfile and architecture.
    • Move only caches you’ve confirmed are reusable; don’t rely on old DerivedData.

    Check: The specified commit checks out, signing files are available, and sensitive assets are not in the repository.

  2. 02 · Toolchain

    Record versions instead of relying on memory

    Align Xcode, Homebrew, Ruby and CocoaPods. Use the version files already in your project where possible. Avoid upgrading dependencies during the migration so you can isolate the source of any issues.

    xcodebuild -version
xcode-select -p
uname -m
ruby --version
bundle exec pod --version

    Check: Confirm the arm64 environment, selected Xcode path and dependency versions, then build one scheme from the command line.

  3. 03 · CI integration

    Connect test jobs before production releases

    Register a self-hosted runner or agent with your existing platform and assign clear labels to the node. GitHub Actions can use the labels below; for other platforms, use their equivalent scheduling configuration.

    runs-on:
  - self-hosted
  - macOS
  - ARM64
  - macos-m4

    Check: Register the same labels, confirm a test branch runs on the new node, and verify that logs and artifacts are available. Keep the original runner configuration as a fallback until production jobs switch over.

Never include registration tokens or signing assets in example commands or public logs. After changing nodes, check that the CI platform shows the runner as online and that its job labels and triggers are correct. Once all three checks pass, make it available to your team.

Runner setup & troubleshooting

Make migration results easy to verify

Compare the same commit in your stand-up

Compare build times using identical inputs. Separate cache-hit and cache-miss results so a download, retry or change in test coverage isn’t mistaken for a hardware difference.

Developer working on a laptop, reviewing build logs and migration notes with the team
Illustrative image of a collaborative development workflow. Use your team’s CI logs for build comparisons; this image is not a customer case study or performance claim.

Keep inputs constant

Record the commit hash, Xcode version, scheme, test device and dependency lockfile. Confirm test coverage hasn’t changed before comparing results.

Break down timings

Compare queue, dependency download, build, test, archive and artifact transfer times separately. A dedicated machine removes resource contention from other tenants, but not network transfers.

Keep a fallback

Save your original runner labels and pipeline configuration. Stop production jobs on the old node only after the new environment runs reliably.

Choose a configuration for your workload

Start PR checks with 16GB; consider 24GB for multiple targets, simulators and release archives. Compare configurations, all four billing periods and storage add-ons on the plans page, then set up a dedicated build lane for your team.

Compare configurations Rent a cloud Mac