Development Environment Handover

From setup to your first build

Rent a dedicated physical cloud Mac and connect your existing repositories, toolchain, and CI pipeline. Follow the steps in order. If you already have a repository and build scripts, allow about 30–60 minutes for the environment migration; file transfers and Xcode downloads take additional time.

Already have an instance?Sign in to the console for connection details. The commands and output below are examples. Use the actual address and credentials shown in your console.

Choose a planGet credentialsMigrateVerify build
Before you start

Order first, then save your connection details

Choose three things when you place your order: the Mac determines your build and parallel-task capacity, the location affects remote access latency, and the billing period determines how long you can use it. All three plans provide a dedicated physical Mac, not a virtual machine. Check the console for current availability.

01 / Plan

Choose a Mac, location, and billing period

ZSH 16 is a good starting point for validating a single build workflow. For parallel builds or a persistent runner, consider ZSH 24. For MLX experiments that need more unified memory, take a look at ZSH Pro 64. Then choose the location closest to where your team connects from.

Check: Mac, SSD capacity, location, and billing period (day, week, month, or quarter).

02 / Payment

Pay in USD

Pay with USDT-TRC20 or use Visa, Mastercard, or Amex through Stripe. Before sending USDT, confirm you’re using the TRC20 network. For card payments, follow the gateway shown at checkout.

Check: payment result and order status in the console. Available payment gateways are confirmed by the backend.

03 / Delivery

Get your SSH and screen-sharing credentials

Once your instance is ready, save its connection address, username, initial login credentials, and host fingerprint from the console. Don’t store them in a repository, build log, or shared team document.

Check: you can connect over SSH and open the macOS desktop.

Migration steps

Migrate in three stages: data, toolchain, CI

First, get one repository building successfully on the new Mac before connecting automation. That way, if something fails, you can tell whether files are missing, tool versions differ, or the runner is misconfigured.

01Files

Migrate repositories and signing assets first

Use rsync to transfer your repository, or clone it again from a trusted remote. Transfer certificates, provisioning profiles, and keychain exports separately using encryption. Don’t put private keys in a regular sync folder.

  • Make sure the repository branches, submodules, and Git LFS files are all present.
  • After importing signing assets, verify keychain access in the build user’s session.
  • Check the required environment variables; don’t copy local secrets in plain text.

Manual check: about 10–20 minutes; transfer time depends on the amount of data.

02Toolchain

Pin versions, then restore caches

Install command-line dependencies with Homebrew and manage the project’s Xcode versions with xcodes. First, check where xcode-select points, then install the dependencies required by fastlane, CocoaPods, and SPM.

  • Record xcodebuild -version and compare it with the version required by your project.
  • Resolve dependencies once; don’t carry absolute paths from the old machine into your cache.
  • Get a local build working for one scheme before tackling parallel tests.

Manual check: about 10–20 minutes; software downloads take additional time.

03CI pipeline

Register a dedicated runner last

Connect the Mac to your existing GitHub Actions or GitLab Runner workflow. Follow the registration steps provided by your repository or organization, and run build jobs under a dedicated system account.

  • Give the runner labels that clearly identify its Mac model and location.
  • Have a test job verify Xcode, signing, and the artifact output path.
  • Limit concurrency and check that jobs don’t leave sensitive temporary files behind.

Manual check: about 10–20 minutes; the first job takes additional time.

These estimates are for planning manual checks only; they aren’t promises about provisioning or download times. If your build relies on a large cache, migrate reproducible settings first, then decide whether to transfer cache files.

Verification

Check your setup with three command sequences

The terminal output below is illustrative, not an instance’s actual address, fingerprint, or build result. Replace the example address and scheme with the values shown in your console and project. Before connecting over SSH for the first time, compare the host fingerprint character by character with the one shown in the console.

zsh — mac@sg-node Example output

Connect and verify the fingerprint

zsh % ssh -o StrictHostKeyChecking=ask mac@203.0.113.10
The authenticity of host '203.0.113.10' can't be established.
Host key verification required before continuing.
Stop at the confirmation prompt. Compare the ED25519 fingerprint shown in your terminal with the one saved in the console. If they don’t match, stop and open a support ticket.

Verify the build

zsh % xcodebuild -version
Xcode 16.2
zsh % xcodebuild -scheme App -configuration Release build
** BUILD SUCCEEDED **
Check the Xcode version first, then build using your project’s scheme and configuration. The example version may differ from the one installed on your instance.

Verify the distribution workflow

zsh % fastlane beta
Running lane 'beta'
Archive complete
Upload to TestFlight complete
Before uploading, check your team’s signing assets, permissions, and fastlane lane configuration. Make sure real tokens aren’t printed to CI logs.
Desktop access

Need a desktop? Connect with screen sharing

Use SSH to install dependencies, pull code, and run builds. For Xcode settings, simulators, and other graphical tools, connect to the macOS desktop using screen sharing. Find the instance’s screen-sharing address and credentials in the console, then connect with your computer’s built-in screen-sharing client.

When you first connect to the desktop, check whether the display resolution and scaling work well on your network. If the remote session feels sluggish, try lowering the resolution and turning off unnecessary animations before comparing the experience on other networks. Use clipboard sync only for non-sensitive text. Transfer certificates and private keys through a controlled, encrypted method instead.

DISPLAY / CONNECTBefore you connect
Address & credentials
Get these from the current instance’s console page; don’t reuse details from another instance.
Display settings
Start with a stable, readable resolution, then adjust image quality to suit your bandwidth.
Clipboard
Sync only the text you need; transfer sensitive files separately.
Connection issues
Check the instance status and address, then check your local network and firewall rules.
After delivery

Complete the initial security setup

A successful connection doesn’t mean setup is complete. Finish these four steps before adding the instance to persistent CI. Have the team that will actually use the Mac verify each one—don’t rely on a screenshot of a successful login.

  1. 01 Change the initial password Set a new password for the provided account in macOS, then update your team’s secure credential records. Don’t paste the password in plain text into chats or pipeline variable descriptions.
  2. 02 Switch to SSH keys Install your public key and verify you can log in from a new terminal before changing the password login policy. Keep your existing session open so a configuration mistake doesn’t lock you out.
  3. 03 Check the firewall Turn on the macOS firewall and check access for development and screen sharing one item at a time. Record the current rules before making changes, and confirm you can still connect for administration.
  4. 04 Schedule system updates Run softwareupdate -l regularly to check for updates. Before installing upgrades that could affect your build environment, back up your files and confirm compatibility with Xcode and your project.
Manage your rental

Check your billing period before renewing; back up data before release

Check the console’s order page for your current billing period, dates, invoices, and renewal options. For expiry reminders, rely on the console and service notifications you receive, not estimates from your local calendar. If you still need the instance, confirm the Mac, location, billing period, and amount in the console before renewing.

Before you finish using the instance, back up unpushed repository changes, signing assets, build artifacts, and any audit records you need. Verify the backup is readable on another device, then release the instance from the console. Release triggers disk erasure and a system reinstall, so it isn’t a substitute for a backup.

Keep exploring

Find the next guide for your current task

For more on SSH, VNC, and setting up a day-to-day development environment, browse our technical articles on remote Mac development. For build settings, caches, and runner configuration, see our cloud Xcode build guide. For instance or billing issues, contact technical support.

Environment & connectivity

Set up a remote Mac development environment

Learn more about SSH keys, Homebrew setup, screen sharing, and connecting to your editor remotely.

Builds & CI

Complete guide to cloud Xcode builds

Explore Xcode versions, build caches, test commands, and how to connect a self-hosted runner.

Instances & billing

Technical support center

If you can’t connect, your build environment is acting up, or you have a renewal question, start with the troubleshooting steps, then submit a support ticket through the console.

NEXT / GET STARTED

Run your first build

Choose a Mac, location, and billing period. Once your instance is ready, follow this checklist to connect, migrate, and verify your setup.