Have an email address that can receive verification codes, a working payment method, and an SSH or screen-sharing client ready. Book a dedicated physical Mac, then retrieve your connection details from the portal once payment is confirmed.
2 models · 6 locations · from $21.4/day. Around 4 minutes is an estimate for a straightforward order; blockchain confirmations, verification steps and network conditions can affect the actual time.
First, make sure your email and payment method are ready. Then choose a model, location and rental period. Your delivery details are all in the portal, so there’s no need to look elsewhere for connection credentials.
Use an email address you can access reliably. Check that you can open both your inbox and spam folder; you’ll need this address for order updates and account verification.
Verification codes are only for the current verification process. Don’t share them with anyone.
Pay in USD with USDT-TRC20 or Visa / Mastercard / Amex via Stripe. If you’re paying with USDT, check the network and payment details shown on the page before sending funds.
Available payment gateways are confirmed at checkout.
For command-line work, have an SSH client ready. For the macOS graphical interface, prepare a screen-sharing client. Before connecting for the first time, check whether your local network blocks the required port.
Get one connection method working before setting up the other.
Open the portal, enter your email address and follow the on-screen steps to verify it. If you already have an account, just sign in. Check the spelling before requesting a verification code so you don’t waste time waiting on the wrong address.
Choose XN Core M4 or XN Pro M4P for your workload, then select a location and a daily, weekly, monthly or quarterly rental period. The 6 locations are Singapore, Tokyo, Seoul, Hong Kong, the US East Coast and the US West Coast. Both models are available at all 6 locations; availability is confirmed in real time in the portal.
Visa / Mastercard / Amex payments via Stripe are confirmed instantly, but you may still need to complete the verification requested on the page. USDT-TRC20 confirmation depends on blockchain processing, so a fixed one-minute confirmation time can’t be guaranteed. Check your order status after paying; don’t pay again just because the page hasn’t updated yet.
Once payment is confirmed, the system assigns a dedicated physical Mac and displays its connection details in the portal. Check the location, model, host and port. Retrieve credentials only from your signed-in portal, and never paste passwords into public build logs.
Connect using the host, port and username shown in the portal. First, confirm you’re on the right machine, then change the initial password and check the system. A successful SSH login doesn’t mean screen sharing is ready—test each connection method separately.
≈ 4 minutes Estimated time from signup and booking to receiving your connection details
This estimate excludes software installation, project uploads and full builds. Delivery may take longer if USDT-TRC20 confirmation is delayed. Your first login also depends on your local network and whether your client is ready.
Not sure what you’ll need over the long term? Start with a day and test your project. Check whether it builds successfully, whether peak memory use fits, and whether there’s enough room for artifacts and caches.
$21.4/day
For app builds, simulator testing and everyday CI. Run a full archive first, then check how much disk space your build cache, dependencies and simulator data use.
This model is a good place to start if you run one task at a time and your project is a manageable size. Avoid stacking unlimited runners on one machine and judging its performance by the resulting queue.
$59.3/day
For demanding parallel builds, multiple development tasks and large-model experiments. 64GB of unified memory and a 2TB primary drive give you more room for model files, dependencies and build caches.
Before running MLX or Core ML workloads, check the model size, quantisation and runtime requirements. Memory capacity alone doesn’t guarantee that every model will run; test with your actual workload first.
Both models are dedicated physical Macs, not virtual machines. Start with the location closest to your team, then test the connection under real conditions. For automated builds, also consider how source files and artifacts will be transferred. See the full price list to compare the four rental periods or check external storage options.
Keep your working connection open while you update settings one at a time. Be especially careful with firewall and SSH changes: test them in a second session before closing the original connection, so you don’t lock yourself out.
Set a strong, unique password. Use the password change flow provided by the system, and don’t store it in plain text in command arguments, scripts or support tickets. If your team shares a build machine, agree on who is responsible for managing its credentials.
Review the macOS firewall and remote access settings, and allow only what your workload needs. Before restricting access by source IP, check whether your public IP is fixed. Test new rules before closing your existing connection.
Note the macOS version and run uname -m to confirm the native architecture is arm64. Check that your project dependencies and toolchain are compatible before deciding whether to switch Xcode versions.
Run df -h to see how much space is left. The advertised primary drive capacity isn’t the same as free space: the system, development tools and caches all use disk space. Work out how much you’ll need before uploading large models or assets.
Read-only checks · These commands don’t change system settings
sw_vers
uname -m
df -h
xcode-select -pThe last command shows the current developer tools directory. If the toolchain isn’t configured yet, set it up in the next section before troubleshooting any errors.
The macOS graphical interface and command line are both ready to use. Check what’s already installed to avoid duplicate setup. Software installation, dependency downloads and your first build aren’t included in the estimated 4-minute delivery time.
Check your current Xcode version against your project’s requirements. If you need to install or switch versions, use a software package from a legitimate source. Once installation is complete, make sure the developer tools path points to the version you intend to use.
Command-line tools cover compilers and common dependencies; they aren’t a replacement for the full Xcode installation. If you use simulators, archives or SDKs, check that the complete development environment is installed.
xcodebuild -version
xcode-select -p
xcrun --find clang
xcrun simctl list devices availableCheck the version and available devices before building your project.
Run command -v brew to check whether Homebrew is installed. If it isn’t, follow Homebrew’s official installation instructions. Don’t run installation scripts from unknown sources.
Check the architecture and paths used by your shell before installing project dependencies. For team projects, reuse the existing dependency manifest and lockfile where possible to keep versions consistent between rentals.
command -v brew
brew --version
git --version
ruby --versionRun version checks only for tools that are installed.
Import signing certificates and provisioning profiles through a secure channel approved by your team. Grant only the permissions needed for the task, and store certificate passwords in an approved secrets manager—not in your repository.
Run a signed build manually first. Check that the certificate is valid and that the bundle identifier matches the provisioning profile. If an automated run fails, work out whether the issue is with the build or signing permissions.
Remove certificate copies and temporary files you no longer need when the project is complete.
If your project has a Gemfile, install the locked dependencies and run an existing lane with bundle exec fastlane. Get a local build working before enabling CI triggers.
Give your runner a clear working directory and set a sensible concurrency limit. Check build output for leaked keys, passwords or signing materials, then sync successful artifacts to storage you control.
bundle install
bundle exec fastlane --version
bundle exec fastlane lanesThese commands are for projects already set up with a Gemfile and Fastlane.
Test your setup with a real project on day one: fetch dependencies, complete a build, export the artifacts, sync them to storage you control, then verify access from a new connection session. Seeing a tool’s version number doesn’t mean your project can be built reliably from scratch.
Treat your cloud Mac as a machine for running tasks, not as the only place to store important files. Check the portal for your rental period, renewal details and order updates.
Sync source changes, build artifacts and essential configuration to storage you control. Caches can be rebuilt; your only copy of a certificate, uncommitted source code or experiment results shouldn’t live only on the Mac.
Open a sample of the files you’ve copied back to make sure the backup worked.
Check expiry reminders in the portal and plan renewals or backups around your workload. Before starting a long build, asset transfer or model experiment, check how much rental time remains instead of waiting until the task is done.
Don’t rely on post-expiry data retention as a backup plan.
To keep using your Mac, open the relevant order in the portal and follow the renewal steps. If you need a higher specification, check the upgrade process, data migration options and full cost before making a change.
An upgrade doesn’t automatically move files from your old Mac to the new one.
Stop starting new CI jobs and let running jobs finish. Export and verify important files, revoke temporary access keys and tokens, then remove sensitive materials. Confirm data retention and deletion arrangements in your order rather than planning around an unverified timeframe.
Once the basics are in place, fine-tune remote access and your build workflow. If something goes wrong, note the model, location, time and error message, then raise a ticket through the portal. Never include passwords or private keys.
Choose SSH or screen sharing for your workload, then set up file transfer. First, verify the host, port and credentials. If only one connection method fails, check its client settings and the corresponding service separately.
Set runner concurrency, cache locations and storage to suit your project. Get one complete task working before expanding your automation, so you can pinpoint issues without changing the toolchain, model and workload settings all at once.
Choose a model, location and rental period. Once payment is confirmed, get your connection details in the portal. Get today’s workload running first, then decide how long to renew for.