Plan build capacity for your team

Choose a Mac Build Node for Your Pipeline

Two configurations cover everything from daily CI for a single app to Unity builds.

First, decide whether your jobs run every day or cluster around releases. Then consider memory, caching, and concurrency. VMFly provides dedicated Apple Silicon Mac mini hardware—not a virtual machine. Each node is assigned to one customer, so you won’t compete with other tenants for build resources on the same host.

Rent a Dedicated Build Node Compare Rental Plans

Starting price: $20.1/day
Chip options: Apple Silicon M4 / M4 Pro
Billing options: day / week / month / quarter

Daily builds · Long-term node

Replace shared queues with your team’s own runner

For a single-app pipeline that runs every day, start with a monthly Glide M4 node: Apple Silicon M4, 16 GB memory, 256 GB SSD, for $100.7/month. Point your GitHub Actions macOS jobs to your own runner instead of waiting for other tenants’ jobs on a shared host.

Migrate one reproducible workflow first

Choose a build pipeline with stable results and record the commit, Xcode version, dependency lockfile, and signing method. Run a clean build before enabling caching; otherwise, stale cache entries can hide differences in the environment.

Install and register your team’s self-hosted runner on the node.
Assign the runner a project-specific label, such as vmfly-ios; then restrict which repositories can use it.
Run the old pipeline and the new node against the same commit, then compare test results, archive settings, and artifacts.

Ideal for checks on fixed branches, nightly builds, and recurring regression tests.

Dedicated resources don’t mean unlimited concurrency

A dedicated machine removes competition from other tenants, but your team still needs to manage its own job queue. Don’t send every job to one machine on day one of the migration.

Start with one job and monitor peak build memory, free disk space, and cache growth.
Use separate labels for archive jobs and UI tests to prevent concurrent writes to the same working directory.
Test your actual project to see whether 16 GB of memory is sufficient before adding a node or choosing another configuration.

Rent Glide M4

A green status is only one part of acceptance. Confirm that your team can download artifacts, logs are retained, and the runner resumes after a restart. Monthly billing suits ongoing use, but not every project needs a node running all month.

Release scaling · Rent by the day

Run archives and UI tests on separate nodes

Release-week bottlenecks often last just a few workdays. Add a Cruise M4 Pro by the day for $61.5/day, with Apple Silicon M4 Pro, 64 GB memory, and a 2 TB SSD for UI tests or archiving. Keep routine checks on your existing node without buying hardware for a short-lived peak.

Define task boundaries before scaling up

Clear resource allocation means one machine handles archives and another runs tests. Adding runners alone won’t speed up a release pipeline if every job still waits at the same serial stage.

Use the same commit for separate archive and test jobs.
Set artifact names and upload locations to prevent different branches from overwriting each other.
Document environment setup so temporary nodes can be rebuilt from configuration files.

Benchmark critical paths before increasing concurrency; don’t promise build speedups you haven’t measured.

Hand off before the release ends

Add clear shutdown criteria to your release checklist: finish the final validation, retrieve artifacts, and save diagnostic logs before ending the rental. Stopping the runner doesn’t cancel billing; check subscription status and the end date in the console.

Export any archives, test reports, and failure logs you need to keep.
Remove the temporary runner registration from your source control platform.
Revoke temporary tokens and back up your data before the rental ends.

Rent Cruise M4 Pro

Unity iOS · Export & archive

Turn Unity export and IPA archiving into one workflow

Run Unity’s Xcode project export, dependency installation, signing, and IPA archiving in one traceable environment. Cruise M4 Pro’s 64 GB memory and 2 TB SSD provide room for large projects, asset imports, and build caches. Verify capacity and concurrency against your workload.

01
Pin the export environment

Record the Unity Editor version, project dependencies, and iOS export settings. Generate the Xcode project from a fixed commit to avoid mismatched Editor versions on your local machine and node.
02
Verify signing and archiving

Check the target, build configuration, provisioning profile, and export method. Provide signing assets to the job through your team’s approved credentials workflow; never put them in the repository or public logs.
03
Keep caches separate from deliverables

Caches can be rebuilt; release artifacts must be retained. Set separate directories and cleanup rules for Unity intermediate files, DerivedData, and archived builds to keep them from filling the system disk over time.

Interactive workloads · Test before committing long term

Use the desktop for debugging and a repeatable environment for experiments

Go beyond unattended builds. Sign in to the console to open the node’s macOS remote desktop in your browser and debug in Xcode, or run scripts over SSH to test local model inference workflows on Apple Silicon.

Check interactive latency before remote development

When you’re clicking through a simulator, inspecting UI, or stepping through code, network latency affects the experience more than it does for background builds. Nodes are available in Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Try a location close to your team before choosing one for long-term use.

Check text clarity, responsiveness, and file transfers over your office network.
Schedule routine editing separately from long-running archives to reduce contention within your team.
If several people share a node, agree on desktop access and credential management rules first.

Use the browser desktop for interactive work and SSH for automation—both can support the same project.

Check memory usage before AI experiments

Choose based on model files, inference precision, context length, and the tools running alongside the model—not just its name. Use a short rental to install the environment and test a sample before choosing Glide M4 or Cruise M4 Pro.

Confirm that dependencies support Apple Silicon and record the installed versions and launch arguments.
Monitor memory pressure during actual runs; SSD capacity is not a substitute for memory.
Save inputs, parameters, and outputs so you can reproduce experiments on a new node.

64 GB of memory doesn’t guarantee that every model will run. Verify compatibility and capacity with your actual workload.

Pipeline checks · From signing to distribution

Make every build stage easy to diagnose

This is an illustrative excerpt of a fastlane workflow, not a benchmark from a VMFly node. Configure access to your signing repository, project scheme, app identifier, and distribution credentials. Get each step working on its own before chaining them into an unattended job.

cruise-m4pro — fastlane

$ bundle exec fastlane match appstore --readonly
[match] Fetching signing certificates and profiles
[match] Installing signing assets into the build keychain
[match] Signing assets are ready

$ bundle exec fastlane gym --scheme "$SCHEME" --export_method app-store
[gym] Archiving the selected scheme
[gym] Exporting the archive
[gym] IPA export completed

$ bundle exec fastlane pilot upload --ipa "$IPA_PATH"
[pilot] Uploading the selected IPA
[pilot] Upload completed; processing continues on TestFlight

match: Fetch only the credentials you need

In CI, retrieve existing signing assets in read-only mode. If the signing repository is inaccessible, check authorization first. Never print private keys, tokens, or decryption passwords to logs.

gym: Distinguish archiving from exporting

A successful archive doesn’t mean the IPA export succeeded. Keep the archive logs and check the scheme, signing configuration, and export parameters separately so the two stages aren’t mistaken for the same failure.

pilot: Uploading isn’t the end of processing

The distribution platform still needs to process the build after upload. Save the upload result and check its processing status; don’t mark the build as accepted just because the upload succeeded.

20 builds a day · Deployment options compared

Compare resource ownership and who handles operations

Imagine a small or midsize team triggering 20 builds a day. This illustrates job frequency; it’s not a performance benchmark and doesn’t determine how many machines you need. Track build duration, concurrent jobs, cache hit rate, and release peaks before comparing these three deployment options.

Deployment options for the same iOS pipeline; verify capabilities and delivery terms with each provider.
Decision factor	Rent a VMFly physical node	Buy Mac hardware	Shared virtual machine
Cost structure	Rent by the day, week, month, or quarter. Glide M4 costs $100.7/month; add-ons are extra.	Pay upfront for hardware, plus deployment, networking, power, and ongoing management.	Pay by platform term or usage; check queueing rules and concurrency limits too.
Provisioning	A physical machine is assigned after payment is confirmed; check the console for its live availability status.	Purchase, delivery, network setup, and remote access configuration are required.	Resources are assigned by the platform; queueing and environment persistence depend on the service.
Dedicated access	The entire Mac mini is assigned to one customer; it’s not a virtual machine.	Your team has dedicated hardware and is responsible for on-site and system management.	Host resources are generally shared with other instances; the platform handles isolation and resource allocation.
Scaling flexibility	Choose another configuration or add a node; your team handles environment and data migration.	Scaling usually means buying and deploying more hardware, while existing machines continue to use your capital budget.	Available configurations and scaling options depend on the platform’s catalog and scheduling rules.

Test your choice with the same commit

Twenty short builds a day may benefit most from a stable cache; a few long UI tests may need separate execution nodes. Don’t upgrade based on build count alone. Compare build time, memory, and disk usage for the same project, then decide whether to keep a Glide M4 long term or add a Cruise M4 Pro for release periods.

VMFly provides a dedicated physical node; your team remains responsible for project dependencies, runner permissions, signing assets, and artifact backups. If you need fully managed pipeline orchestration, first check whether your existing tools already cover these tasks.

Choose a plan for your workload

For daily builds, consider sustained load; for temporary scaling, consider how many days you’ll use the node. Compare the two configurations and four billing options, then choose a node for your pipeline.

Compare Rental Plans Rent a Dedicated Build Node