Rent a dedicated Mac mini by the day—not a shared virtual machine. Choose a model, get your connection details, and follow the steps below to run your first build.
Delivery takes about 15 minutes after payment. The time needed to connect and check your setup depends on your keys, project, and signing credentials.
Rent from 1 day. Choose from two M4 models and daily, weekly, monthly, or quarterly billing. Availability is confirmed in real time by the console.
When ordering, choose a model, region, rental term, and payment method. For a one-off release, start with 1 day. For continuous CI, compare weekly, monthly, and quarterly terms. Pay upfront for the selected term; all prices are in USD.
Ideal for building a single app with Xcode, packaging with fastlane, and getting SSH, VNC, and your development toolchain up and running. If you also need to run simulators and containers in parallel, check your project's actual memory usage first.
Ideal for running Xcode, simulators, and containers in parallel, or for workloads that need more room for MLX models and build caches. For large model files, check the SSD add-on options when ordering.
Available regions: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East Coast, and the US West Coast. Choose one close to your team and code services that you can connect to reliably. Both models are available in all six regions.
Payment is limited to USDT-TRC20 or Visa, Mastercard, and Amex processed by Stripe. Available payment gateways are confirmed in the console.
View your delivery details in the console. Never paste login details, private keys, or signing certificates into a support ticket. For troubleshooting, provide your order number and redacted error output.
| Field | Purpose | How to check |
|---|---|---|
| Host address | Specifies the target for SSH and VNC connections. | Copy the address shown in the console and check that it has no extra spaces. |
| Username | Identifies your SSH login together with the host address. | Use the account listed for your order; don't guess the system's default username. |
| SSH public key | Authorizes your device to log in using a key. | Upload the public key file; keep the private key on your own device. |
| VNC access | Opens the macOS graphical interface. | Follow the connection method and credentials on your delivery page. Don't use VNC as an SSH port. |
Generate a key pair on your own computer, then upload the public key to the console. Connect using the private key on your device. Don't generate the only private key for accessing this host on the remote machine itself.
Check the address, username, and public key first, then make sure your local network can reach the host. If the TCP connection times out, check the network. If the key is rejected, verify your identity and access permissions.
Use the delivery details to set your connection variables in a local terminal. Check the macOS version and processor architecture, then list the available schemes from your project directory. Only build or archive the project after confirming its scheme and signing configuration.
ssh -i ~/.ssh/id_ed25519 "$VM_USER@$VM_HOST"Once connected, your command prompt switches to the remote Mac. On your first connection, verify the host fingerprint against your delivery details.
sw_vers -productName
uname -m
sysctl -n machdep.cpu.brand_stringYou should see macOS, arm64, and Apple M4, respectively. The delivered machine's actual output determines the macOS version.
xcodebuild -list
xcodebuild -scheme "$SCHEME" -destination 'generic/platform=iOS' build CODE_SIGNING_ALLOWED=NOAn unsigned build is a quick way to check whether your project builds. On success, check the exit status and BUILD SUCCEEDED. On failure, start troubleshooting with the first build error.
fastlane gym --scheme "$SCHEME"Archiving and exporting require the certificates, provisioning profiles, and fastlane configuration your project needs. Check the exported files when the command finishes; don't rely only on the last line of the log.
Here, VM_USER,VM_HOST , and SCHEME are shell variables. Set them using your delivery details and the actual scheme in your project. If your project requires a specific Xcode version, run xcodebuild -version to check it before switching.
Use SSH to transfer files, run builds, and check logs. Connect via VNC when you need to use the Xcode interface, a simulator, or system settings. Both connect to the same dedicated Mac mini.
In your VNC client, enter the address and access details shown on the delivery page. Don't copy the SSH username, key, or port into the VNC client.
Start with a lower display resolution in your client. Once the image and input are stable, increase it. For cross-region access, prioritize responsiveness over maximum image quality.
Make sure you can reproduce builds using SSH commands. If your VNC session disconnects, builds, logs, and CI troubleshooting won't depend on the desktop.
If the screen is black, first confirm you're connected to the right order and region, then check the session status. Don't try to fix a remote display issue by repeatedly changing the project or deleting build caches.
To set up a GitHub Actions self-hosted runner, first generate a registration command and short-lived token in your repository's runner settings. Then run the command provided for your platform on this Mac. Never put the token in a repository, screenshot, or build log.
Register the runner with the repository that needs builds or with a controlled organization, and give it a label that identifies this macOS host. Once the runner shows as online, submit a workflow.
Start by checking out the code, then run the same Xcode command you used for manual verification. Once it succeeds, add dependency caching, tests, signing, and distribution one step at a time to avoid introducing multiple failure points at once.
The runner can access the build environment on this machine. Set permission boundaries for the branches and repositories that can trigger jobs, protect your signing credentials, and remove any runner registration you no longer need before your rental ends.
First confirm the runner is selected correctly, the code can be checked out, andxcodebuild -version matches your manual check. Then run a verified scheme. Match the workflow's scheme, target platform, and signing settings to your project; example commands aren't universal packaging configurations.
Your rental starts at delivery. Plan backups, runner cleanup, and renewal decisions before it ends. Don't leave your only copy of source code, certificates, or build artifacts on the remote machine.
Check that your source changes are committed. Retrieve archives, logs, model files, and configuration, then verify the files open from your own storage. Store signing credentials according to your team's established security process.
If your build isn't complete, check renewal options in the console. If parallel jobs are limited by memory or disk space, compare Commit 16 and Commit 24, then choose based on your actual needs.
Check for jobs still in the CI queue and whether the runner is still linked to a repository. Data handling after your rental ends follows the service terms and the rules shown in the console. Back up your data during the rental.
For help with connections, build commands, or billing, start with the docs. To learn more about setting up a remote Mac development environment, browse the published guides on our blog. Blog content is subject to change.
Start with 1 day, choose a region and model, then follow this checklist to run your first build after delivery.