Getting started

From your order
to your first
archive

Rent a dedicated Apple Silicon physical host and verify connectivity, your toolchain, and your build step by step. Get one project running first, then connect it to your team's CI.

Rent a cloud Mac View the steps

Two Mac plans, 5 locations, from $21.2/day. One dedicated physical machine, not a virtual machine. Check the console for live availability and delivery status.

Step 1 / Choose your compute

Start with your workload, then choose a host

For standard builds and an initial setup, start with the Arm Line M4. Choose the Arm Grid M4 Pro for model inference or higher unified memory needs. Don't size memory by project folder size alone—factor in concurrent jobs and toolchain usage too.

Arm Line M4

M4 / 16GB / 256GB

Well suited to your first Xcode build, a single CI build pipeline, or occasional iOS releases. Test dependency installation, cache size, and your build process with a real project first.

$21.2/day

Rent the Arm Line M4

Arm Grid M4 Pro

M4 Pro / 64GB / 2TB

Designed for model inference, larger build caches, and memory-intensive workflows. To determine whether a specific model will run, test it with your quantization method, context length, and runtime parameters.

$59.8/day

Rent the Arm Grid M4 Pro

Both plans are available in 5 locations

Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East Coast. For interactive desktop work, consider the network route between your team and the host. Unattended builds also depend on code checkout, dependency downloads, and artifact uploads. Geographic distance is a useful starting point, not a substitute for measured latency.

For your first rental, consider starting with a daily plan and running a complete workflow on the same project before committing to a longer term. See the pricing page for all four rental periods and add-ons.

View all plans and pricing

Step 2 / Payment and delivery

After payment, check your order status

We accept USDT-TRC20 and Visa / Mastercard / Amex via Stripe. All charges are in US dollars (USD). Available payment gateways are determined by the response from the backend.

01
Review your order

Check the Mac, rental period, location, and add-ons. For USDT transfers, select the TRC20 network and carefully verify the recipient details and amount shown on the payment page. Don't reuse payment details from an earlier order.
02
Wait for confirmation

On-chain payments require confirmation, and processing times vary with network conditions. For card payments, check the payment result and order status. Don't pay again just because the page hasn't updated yet, and don't assume a successful payment means the host has been delivered.
03
Get your connection details

Check delivery status in the console. Once the host is available, note its IP address, login username, initial password, and connection ports. If your payment receipt doesn't match the order status, submit a support ticket with your order number and transaction hash or payment receipt.

Check delivery in the console

Step 3 / Connect for the first time

Test SSH first, then open the desktop

Run these commands in a terminal on your local computer. Enter the address, port, and username shown in the console when prompted. The examples below are not connection credentials.

Start an SSH session

read -r -p "Node IP: " NODE_IP
read -r -p "SSH port: " SSH_PORT
read -r -p "Login user: " NODE_USER
ssh -p "$SSH_PORT" "$NODE_USER@$NODE_IP"

The first time you connect, SSH displays the host fingerprint. Verify it through a trusted channel before accepting it. If a saved fingerprint changes, first confirm whether the host was reinstalled or replaced; don't bypass the check.

Change the current user's password on the host

whoami
hostname
passwd

Run passwd in your cloud Mac SSH session. Follow the prompts to enter your old and new passwords; no characters appear as you type. Don't reuse passwords from other services or include them in build logs.

VNC client settings

Field	What to enter	How to check
Server address	Host IP from the console	Use the address for your current order, not your local computer.
Port	VNC port from the console	If the client has a separate port field, enter it there. Don't guess the port.
Authentication	Desktop connection credentials from the console	Don't assume the VNC and SSH passwords are always the same.
Initial display settings	Start with a lower resolution	Check that the display and input work, then increase image quality to suit your bandwidth.

You can also use macOS Screen Sharing. After changing your login password, check the delivery instructions to see whether your desktop connection credentials also need updating. Don't expose the VNC service directly to untrusted networks.

Step 4 / Prepare your build environment

Check your toolchain before your first build

Run these commands on your cloud Mac. Check the system and existing tools before installing anything that's missing. Don't overwrite versions of Xcode, Ruby, or other dependencies that your team has already pinned just to match the examples.

1. Check the system and Xcode

sw_vers
uname -m
df -h /
ls /Applications
xcode-select -p
xcodebuild -version

If xcode-select points to the standalone Command Line Tools, that doesn't mean the full Xcode app is available. If Xcode isn't installed, first obtain an installer approved for your team's licensing terms, then extract it into /Applications. Make sure you have enough disk space for extraction, dependencies, and build artifacts.

2. Select the full Xcode installation and initialize it

sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license
sudo xcodebuild -runFirstLaunch
xcodebuild -version
xcodebuild -showsdks

This example assumes the app is named Xcode.app. If you have multiple versions, use the actual path. Read the terms before accepting the license. To avoid changing the toolchain used by other jobs, you can set DEVELOPER_DIR to the required version for a single build.

3. Check Homebrew, Ruby, and Fastlane

command -v brew
brew --version
ruby --version
bundle --version

If Homebrew isn't installed, follow an installation process approved by your team. Don't paste in remote install scripts from untrusted sources. The common Apple Silicon install path is /opt/homebrew; check the actual output. If Homebrew is installed but unavailable in your current session, load its environment:

eval "$(/opt/homebrew/bin/brew shellenv)"
brew install ruby
export PATH="$(brew --prefix ruby)/bin:$PATH"
gem install bundler
bundle install
bundle exec fastlane --version

Run the last four commands from your project directory. This assumes the repository contains a Gemfile and lockfile that pin the Fastlane dependencies. If it doesn't, have your team decide on dependency versions and commit a lockfile before installing. Don't use administrator privileges to install build dependencies into the system Ruby.

4. Test an unsigned archive first

read -r -p "Workspace path: " WORKSPACE
read -r -p "Shared scheme: " SCHEME
xcodebuild -list -workspace "$WORKSPACE"
xcodebuild \
  -workspace "$WORKSPACE" \
  -scheme "$SCHEME" \
  -destination 'generic/platform=iOS' \
  -archivePath "$HOME/BuildArtifacts/FirstBuild.xcarchive" \
  CODE_SIGNING_ALLOWED=NO \
  archive

Change to your project directory, install the declared dependencies, and make sure the scheme is shared. For projects with only an .xcodeproj, replace -workspace with -project. This command tests the compile and archive steps; it won't produce a signed, distributable build, and it doesn't guarantee that build scripts requiring signing will pass.

Step 5 / Add automation

Get a local build working before registering a runner

Choose GitHub Actions or GitLab Runner to match your code hosting platform. Start by testing a job on a trusted branch. Check the service user, environment variables, and Keychain access before handing work over to your production pipeline.

GitHub Actions: register and install the user service

In your repository or organization runner settings, select macOS and ARM64. Follow the platform's current instructions to download, verify, and extract the package to a dedicated directory. Run the commands below from that directory, using the registration URL and short-lived token shown in the current settings page.

read -r -p "Repository or organization URL: " RUNNER_URL
read -r -s -p "Registration token: " RUNNER_TOKEN
printf '\n'
./config.sh \
  --url "$RUNNER_URL" \
  --token "$RUNNER_TOKEN" \
  --labels armvnc,macos,arm64
unset RUNNER_TOKEN
./svc.sh install
./svc.sh start
./svc.sh status

In your workflow, use runs-on: [self-hosted, macOS, ARM64, armvnc] and verify the actual labels shown by the platform. The user service's startup and operation are tied to the login session. After installation, test recovery after logging in again and after a restart; successful registration doesn't mean jobs will run in every state.

GitLab Runner: register a shell executor

Create a runner in your project or group settings and get its authentication token. Once Homebrew is configured, install the runner and register it by following the prompts. The service runs as the current user, who should also own the build files and credentials.

brew install gitlab-runner
read -r -p "CI server URL: " CI_SERVER_URL
read -r -s -p "Runner authentication token: " RUNNER_TOKEN
printf '\n'
gitlab-runner register \
  --url "$CI_SERVER_URL" \
  --token "$RUNNER_TOKEN" \
  --executor shell \
  --description "ArmVNC macOS ARM64"
unset RUNNER_TOKEN
gitlab-runner install
gitlab-runner start
gitlab-runner status
gitlab-runner verify

Configure runner tags and protected branch policies in your platform settings. Pipeline tags must match the runner's tags. User services typically depend on a login session; check the current runner documentation for LaunchAgent and startup behavior. Don't start the same runner instance again using a different service manager.

Include these four checks in your first CI job

Print whoami, xcode-select -p, and xcodebuild -version to make sure the job is running in the expected environment.
Set the toolchain PATH explicitly. Background services may not load your interactive shell configuration.
Run an unsigned build first, then configure a managed Keychain and signing steps. Never print secrets, passwords, or tokens in logs.
Set up artifact upload and cleanup policies. Don't run unreviewed code from public sources on a runner that holds signing materials.

Hosts run year-round, 365 days a year, but you're still responsible for managing your CI process. After logging out, updating the system, or restarting, make sure the runner service, network, and signing environment are back up. Before ending your rental, remove the runner from your platform, revoke credentials, and retrieve your artifacts.

Terms, in practical terms

Eight terms for understanding delivery and connectivity

To see whether a term matters, look at the task it affects: resource ownership, connectivity, job execution, or working across multiple machines.

Physical host: A real Mac located in a data center. The console provides connection details for this machine, not a development environment on your local computer.
Dedicated physical machine: One order reserves the compute and storage resources of an entire Mac for you. You're responsible for managing your own job concurrency, dependencies, and caches.
Not a virtual machine: The service is delivered on a physical device running native macOS. You can use both the graphical interface and command line in your workflow.
VNC: A remote desktop protocol. It lets you view and control a Mac desktop from different operating systems; the experience depends on your network and image quality settings.
Screen Sharing: The remote desktop feature built into macOS. If you're using a Mac client, connect to the host desktop using the details provided with your order.
Self-hosted runner: A CI execution host that you register and manage. Your code hosting platform dispatches jobs, and the runner process on your cloud Mac executes the builds.
Unified memory: Memory shared by the CPU and GPU in Apple Silicon. Models, build jobs, and system processes all use this resource.
Thunderbolt 5 interconnect: An optional configuration connecting multiple machines over Thunderbolt 5, billed per machine. It doesn't automatically combine their memory into one address space; you still need to orchestrate the workload.

Next / Build on your results

Once the build works, make the process repeatable

Document the verified Xcode version, dependency lockfile, and build commands in your repository. If something goes wrong, identify whether the issue is in connectivity, the toolchain, or the project before asking for help with a minimal reproduction.

Fine-tune your remote connection

Compare VNC, Screen Sharing, and SSH, then check resolution, tunneling, and reconnect behavior. This is connection guidance, not a remote access portal.

Read the connection guide

Choose a long-term setup

Check memory and disk usage with a real project, compare the four rental periods and storage add-ons, then choose a plan for your always-on CI workload.

Compare rental plans

Troubleshoot an issue

Find help with provisioning, connectivity, payments, and availability. When you submit a support ticket, include your order number, host ID, time of the issue, and redacted logs—never your password.

Visit the Help Center

Run your first checks on a real project

Start with a daily rental and verify connectivity, dependencies, and your archive. We accept USDT-TRC20 and Visa / Mastercard / Amex via Stripe, with all charges in USD.

Rent a cloud Mac Already have an order? Open the console