Before you rent and
once your Mac is ready.

Rentals are prepaid: choose a Mac, then select a rental period. Daily, weekly, monthly and quarterly rates are listed separately; the daily rate is not simply multiplied by the number of days. Choose the period that matches how long you expect to use the machine.

Additional SSD storage and Thunderbolt 5 clustering are charged separately. Before paying, check the model, location, rental period, add-ons and total due on the order page. The start and end times shown in the portal are authoritative.

Submit a ticket through the portal with your current order number, requested configuration, disk usage and a suitable time to pause builds. Each configuration runs on a separate physical machine, so a change is not an online resize of a VM.

Wait for support to confirm the migration method, billing and handover plan before proceeding. Before migration, export your settings and back up your projects, signing materials and build artifacts. Don’t assume a memory change will preserve the original machine’s full runtime state. If you’re downgrading, make sure the target SSD has enough room for your data.

These are the listed prices for add-ons. Thunderbolt 5 clustering is charged per machine; it does not include extra storage or memory with a base configuration. The configurator will show which options are available and any conditions that apply when you place your order.

Whether add-ons can be changed during a rental and how data on an additional drive can be moved depend on your order. Back up your data before removing an add-on drive. Don’t assume add-ons can be used or refunded separately from the machine.

We accept USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) only. All products and orders are billed in US dollars (USD). The payment gateways available for your order are determined by the response from our backend.

For USDT-TRC20, follow the network, address and amount shown on the payment page, and save the transaction hash. For card payments, complete verification on the gateway page. A payment screenshot does not confirm that your machine has been delivered; check the order status in the portal.

Check the order and billing records in the portal to make sure you paid for the correct order. Don’t pay again until you’ve confirmed the status. For an on-chain transfer, verify the network, receiving address, amount and transaction hash.

Then submit a ticket with your order number, payment method, payment time and transaction reference. For card payments, never send your full card number or verification code. For USDT-TRC20, the transaction hash is enough. For email assistance, contact support@osxhost.com.

Before renewing, check the service expiry date, rental period and amount due in the portal. After payment, confirm that the new expiry date is shown. A task still running on your machine does not mean the order has been renewed.

Early cancellation, add-on changes and refunds are handled according to the order and service terms; unused hours are not automatically refunded. When you submit a request, include your order number, reason and requested service end time. Keep your billing and payment records until you receive a clear outcome.

See the service terms for ordering and billing rules

You get a dedicated physical machine, not a VM. Each Apple Silicon Mac mini is assigned to one user for the rental period. Its CPU, unified memory and storage are not shared with other tenants. You can use both the macOS desktop and the command line.

Dedicated hardware doesn’t mean tasks can’t compete with each other. Archives, simulators, containers and model inference running on the same machine still share resources. Start with one task at a time, then increase concurrency while monitoring memory pressure and disk usage.

There are three configurations: Host M4 Lite (M4 / 16GB / 256GB), Host M4 Plus (M4 / 24GB / 512GB) and Host M4 Pro (M4 Pro / 64GB / 2TB). The base drive and additional SSD storage are separate options.

Lite is a good starting point for a typical single-app build. Consider Plus for multiple targets or running Flutter and simulators in parallel. Pro is suited to concurrent archive builds for large projects, Unity exports or MLX inference. Before choosing, estimate peak usage for DerivedData, dependency caches, simulator runtimes and build artifacts—not just the size of your repository.

Compare all 3 configurations and selection tips

First, check that your required version of Xcode is compatible with macOS, then confirm which versions are available before ordering. If you need a specific version, check with support before paying. Don’t assume every older version can be installed.

After delivery, note the macOS version, Xcode path and available SDKs. A system change may affect signing tools, Ruby dependencies and runners. Make a restorable backup, test the change in a separate task, and only then switch your production pipeline.

You can plan for multiple Xcode versions based on macOS compatibility and available disk space. Use beta releases for compatibility testing first; don’t replace the version used by a stable production pipeline. Follow the applicable licence terms when obtaining and using software.

For CI, set DEVELOPER_DIR explicitly for each task to avoid a global switch affecting other builds. After switching, run xcodebuild -version and xcodebuild -showsdks, verify the toolchain shown in the logs, then run your tests and archive.

We have five locations: Singapore, Tokyo, Seoul, Hong Kong and the US West Coast. All three configurations are available in all five locations. Check the portal for current availability.

Consider your team’s location, code repository and artifact storage when choosing. A location name doesn’t guarantee cross-region latency. Your carrier, corporate network and remote access method can all affect the experience.

Check the plan details, portal and delivery information for specific bandwidth, IP allocation and connection ports. We don’t promise a single speed, a dedicated public IP or access to every port on every order.

If your workload requires a fixed egress IP, inbound callbacks, an IP allowlist or large artifact uploads, list the protocols, traffic direction, target services and bandwidth needs before ordering so support can confirm what’s available. After delivery, test SSH and the ports your workload needs before connecting CI. Allow only the access you need.

For remote desktop work, start with a nearby location that has a stable route. For unattended builds, focus on dependency downloads, repository checkouts and artifact uploads. Geographic distance alone won’t tell you which pipeline will be fastest.

Test connection stability, repository checkout times and a complete build using your own network. If you need to confirm connectivity requirements first, tell us your team’s time zone, network environment and main toolchain. We don’t provide live latency measurements for individual cities.

Follow the connection guide for SSH and screen sharing

Yes. You can register it as a self-hosted GitHub Actions runner, a GitLab Runner or a Jenkins agent. First, run your build manually in the terminal. Then give your job runner the same working directory, toolchain paths and environment variables.

Use a dedicated build user and limit runner tags and repository access. Don’t let untrusted external contributions read signing credentials. Start with low concurrency, then monitor memory pressure, simulator count and archive output. Avoid having multiple jobs write to the same directory.

Keep signing materials separate from your source code. You can use fastlane match to manage encrypted signing materials and pass the decryption password through protected CI variables. Never put private keys, passwords or full credentials in your repository or support tickets.

Use a separate keychain for build jobs, restrict access and prevent sensitive values from appearing in logs. Keep an encrypted backup outside the machine, and revoke permissions you no longer need when people or tasks change. Before your rental ends, remove local credentials and CI variables—not just the project directory.

Debugging a physical device with Xcode is different from testing in a simulator. The cloud Mac can run supported development workflows, but remote access won’t automatically connect a USB device on your desk to the data centre.

If you need a physical device or USB accessory, send support the device model, connection method, authorisation steps and expected test workflow so they can confirm what’s possible before you place an order. Don’t assume local device passthrough is included unless it has been confirmed. For simulator-only regression testing, you can deploy through the usual Xcode workflow.

Flutter and React Native iOS builds can share Xcode, CocoaPods and signing configuration. Pin dependency versions and isolate caches by project. Run pod install and a complete build first, then decide which caches are safe to reuse across tasks.

Docker and OrbStack work well for build support services, but Linux containers don’t replace Xcode archiving on macOS. On Apple Silicon, check that your images support the right architecture. Containers, simulators and build jobs all use the same machine resources, so include them in your concurrency planning.

Our commitment is 99.9% uptime, calculated monthly. On a 30-day basis, that equates to approximately 43 minutes of allowed downtime. This is a calculation of the commitment threshold, not a prediction that service will be interrupted each month.

All locations operate normally year-round, 365 days a year. Check the service terms for which incidents count as downtime, the applicable scope and how uptime is calculated. User actions and task errors are not the same as a physical machine being unavailable.

Any downtime beyond the allowance is converted into an extension of the service period based on the duration of the impact. The extension applies to the affected service order. The uptime commitment does not automatically mean a cash refund or an additional standalone machine.

Keep connection errors, task logs and the start and end times you observed during the incident, including the time zone. Support will verify the incident and order, then confirm the eligible duration and extension. You can check the service expiry date in the portal.

Submit a support ticket through the portal within 7 days after the incident ends. Include your order number, location, start and end times with the time zone, and evidence such as an error message or relevant log excerpt. If multiple orders were affected, list each one separately rather than saying only “unavailable all night”.

Never send your login password, SSH private key or signing certificate. Use tickets to link your request to service records. General enquiries can be sent by email, but submit order-related claims while signed in.

After your rental ends, the machine is securely erased, wiped and reinstalled before it is assigned again. The platform does not access your projects or certificates on the machine. Don’t rely on the machine as the only long-term copy of your work.

Before you finish, export any projects, build logs and artifacts you need to keep. Revoke runner registrations, deployment keys and other service tokens, and check that your off-machine backups can be read. Don’t rely on being able to recover data after it has been erased.

Follow the expiry, retention and release rules shown in the portal. We don’t promise a standard additional retention period or guarantee that you’ll still be able to sign in and download files after your service expires. If you need a specific handover deadline, confirm it by submitting a ticket before expiry.

Before expiry, stop new jobs and copy your build artifacts and essential configuration off the machine. Verify that you can restore them before ending the service. If you need more time, renew in advance; an active SSH connection does not mean your renewal has succeeded.

Sign in to the portal and check the delivery details for your instance. Connection credentials and account sign-in are separate; never paste passwords into public logs, build artifacts or email messages.

If you suspect a leak, stop untrusted jobs, revoke the relevant keys and tokens, review runner permissions, and submit a ticket with your order number and when you noticed the issue. If you can’t access the portal, contact support@osxhost.com from the email address associated with your account and complete the requested identity checks.

For order-related issues, submit a ticket through the portal. For pre-sales questions, team purchases or portal access issues, email support@osxhost.com. These are our only support channels; there’s no need to submit the same question elsewhere.

Include the order number, location, time and time zone, expected result, actual error and steps you’ve already tried. For build issues, add the Xcode version, command you ran and a redacted log excerpt. Clear reproduction steps are more useful than a screenshot of a failed build alone.

Prepare your enquiry by topic