Rental terms, access, builds—
what should you check first?

Pay in advance for your chosen term; the machine and add-ons are priced separately. For example, ArmRDP M4 Base is listed at $21.1/day, $57.1/week, $105.7/month, or $287.5/quarter. These are separate term prices—not the daily rate multiplied by the number of days.

When comparing options, factor in how long you expect to use the machine and how much storage you need. Start with a daily term for a short test, compare weekly billing for regular releases, and consider monthly or quarterly billing for a permanent runner. Confirm the term dates, amount due, and expiry time on the console’s checkout page and in your order record.

Don’t assume your first payment enables automatic renewal. Check your subscription’s renewal settings, expiry time, and outstanding invoices in the console. Whether automatic renewal is enabled, and when it takes effect, depends on the status shown for that subscription.

Before a release, make sure your rental covers archiving, signing, and uploading build artifacts. When you’re ready to finish, stop accepting new jobs, let the queue drain, then export your code, certificate backups, and build artifacts. Don’t rely on the host’s disk as long-term backup storage after the rental expires.

The catalogue offers +1TB SSD, +2TB SSD, and per-machine Thunderbolt 5 daisy-chaining. First check which changes are available for your order in the console. Before confirming, verify how add-ons are applied to existing orders, when billing starts, and whether running tasks need adjustment. Don’t assume changes take effect immediately or are prorated automatically for the remaining days.

If the console doesn’t offer the option you need, submit a support ticket with your host ID, requested add-on, current free space, and preferred change date. More disk space doesn’t mean more memory. If DerivedData, simulator runtimes, and archives keep growing, check what’s using the space before adding capacity.

We accept USDT-TRC20 and Visa / Mastercard / Amex (via Stripe). All payments are in US dollars (USD). The $ symbol on this site always means US dollars; prices aren’t converted to local currencies.

Available gateways are determined by the response from the backend. Before paying, check the model, location, rental term, and add-ons. Keep your order number and payment receipt to look up an invoice or submit a payment support ticket later.

Refresh the order in the console and check that you’re viewing the same invoice. Don’t assume payment succeeded just because your browser returned to the site, and don’t pay again until the status is confirmed.

For USDT-TRC20, check the network, recipient details, and amount, and keep the transaction ID. For card payments, keep the payment confirmation and invoice number. If the status still hasn’t updated, submit a support ticket through the console. Never include your full card number, security code, or any password in a ticket.

It’s a dedicated physical Mac mini, not a VM. The entire node is yours for the rental term; it isn’t shared with other tenants. You get full access to the macOS GUI and command line, and Xcode, simulators, and Metal run natively on the physical machine.

The catalogue has three models: ArmRDP M4 Base (M4 / 16GB / 256GB), ArmRDP M4 Plus (M4 / 24GB / 512GB), and ArmRDP M4 Pro (M4 Pro / 64GB / 2TB). Compare peak memory use and disk working set when choosing; the chip name alone doesn’t tell you how well a model will fit your workload.

Your account permissions are those provided in the console. After your first login, run id to check your user and groups, and run sudo -l to see which administrative commands you can run. Confirm your permissions before using sudo to install software, register services, or change network settings. Using sudo doesn’t mean you need to enable remote root login.

Before reinstalling or changing the macOS version, back up your working directory, signing materials, and configuration. Then check in the console which reinstall options are available, or submit a ticket to confirm the target version. Don’t erase the disk or delete network configuration from a remote session—you could lose your recovery access.

There are five locations: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US West. All three models are available at each location, subject to real-time availability in the console.

For teams that use the GUI regularly, compare network routes from your engineers to each location. Teams focused on automated builds should also consider where their code repositories, package sources, and artifact destinations are. Distance is only one factor: carrier routing, bandwidth, and packet loss also affect performance. All locations run year-round, 365 days a year; schedule builds whenever you need.

A location change isn’t an instant switch that keeps your current disk and address. Moving between locations involves a new physical machine, connection details, and data migration. Confirm how to adjust your order by submitting a support ticket through the console.

For a smooth move, prepare the same toolchain version at the target location, copy over your repository and required configuration, and verify an archive and signing run. Then update runner labels and job routing. Retire the original node only after confirming the artifacts are complete, so you don’t lose your only working build environment too soon.

You can keep multiple Xcode versions installed, provided they’re compatible with your current macOS, and select a toolchain for each project. Run xcodebuild -version and xcode-select -p to check the current environment. In your pipeline, set DEVELOPER_DIR to point to the target Xcode and avoid repeatedly changing the system-wide selection between jobs.

When pinning a version, also record the SDK, simulator runtimes, dependency lockfiles, and build scripts. Before upgrading, duplicate a validation pipeline and confirm that archiving, codesign, and export all succeed. Then update your regular jobs. A larger SSD can hold more versions, but it won’t resolve compatibility limits between macOS and Xcode.

Simulators run natively on the physical node, provided the matching Xcode runtime is installed. Use VNC to troubleshoot GUI issues and the command line for automated jobs. When running multiple simulators and archives at once, monitor memory pressure and free disk space.

Treat certificates and provisioning profiles as sensitive materials. Use a dedicated Keychain for CI, store credentials in protected pipeline variables, and never commit them to your repository or attach them to support tickets. Verify signing once under the same user account the runner will use, then hand the job over to the unattended runner.

There’s no way to choose a machine count based only on the number of builds you run each day. Start with one machine and one concurrent job using a real project. Record total job time, queue time, peak memory, and archive size—these metrics are more useful for choosing a setup than compile times from an empty project.

A single machine can run multiple runner processes, but they still share its CPU, memory, and disk. For simultaneous, independent archive jobs, add dedicated nodes and route jobs by label. Give each job its own working directory, DerivedData path, and temporary signing environment to avoid cache contention.

Use SSH to install dependencies, run scripts, inspect logs, and manage CI services. Use VNC screen sharing to work in Xcode, view simulators, and troubleshoot GUI issues. Both connect to the same cloud Mac; they aren’t separate, isolated environments.

For your first connection, get the host address, port, and credentials from the console, then verify the host details before connecting. Once configured, build jobs should run continuously through the runner service—not rely on an open GUI session or a local SSH window.

There’s no fixed latency we can promise based on the location name alone; it depends on your network. SSH responsiveness mainly depends on round-trip time. VNC is also affected by resolution, screen activity, compression settings, and available bandwidth. A single ping result doesn’t reflect the experience of an extended session.

If the connection stutters, first check whether SSH works normally on the same network. Then lower the VNC resolution or color depth and turn off unnecessary animations. When submitting a support ticket, include your client OS, location, connection method, the time the issue occurred, and any packet loss. Specify whether input is slow, the display is slow, or the connection drops.

First, change the credentials you received and add your personal SSH public key. Test key-based login in a second session; once it works, you can disable SSH password login according to your security policy. Before changing the firewall or restricting source IPs, keep a verified way to regain access.

Whenever possible, access VNC through an SSH tunnel rather than exposing screen sharing to unnecessary sources. Give each team member their own key and revoke access promptly when they leave or change roles. When rotating credentials, also check runner variables, automation scripts, and saved credentials in local clients.