One dedicated Mac · two ways to connect

Build over SSH,
use Xcode over VNC

Connect to the same physical Mac mini from the command line or graphical desktop. Let your runner handle ongoing jobs, and open screen sharing when you need to inspect Xcode, a simulator, or certificate settings.

Rent a dedicated Mac View setup steps

Apple Silicon M4 · Two plans · From $20/day. The entire machine is assigned to one customer—not a virtual machine.

Dedicated team workspace

Jobs keep running; open the desktop when needed

SSHAutomation

Sync the project
Run tests
Archive builds

VNCInteractive checks

Open Xcode
Check the simulator
Verify signing

Both paths share the same project, disk, and toolchain—not two machines that need separate setup. Desktop work also uses the machine’s resources.

Choose the workflow, then connect

Automate from the command line; inspect in the desktop

You can use both methods. Choose how to connect based on whether the task needs a graphical interface—not whether someone is sitting at the computer.

SSH: for repeatable tasks

Use SSH for xcodebuild builds and tests, runner registration, log checks, and file transfers with scp or rsync. Build logs are text, so there’s no need to stream the desktop continuously.

Put dependency installation, tests, and archiving in your pipeline to reduce manual clicks.
Check runner processes, working directories, free disk space, and failure logs.
Run the runner as a service instead of tying long-running jobs to a single SSH session.

Best for: PR checks, nightly builds, batch packaging, and artifact sync.

VNC: for tasks that need a visual interface

Use VNC for Xcode’s graphical interface, simulator interaction, and Keychain or certificate setup. Connect with macOS Screen Sharing or a compatible VNC client.

Inspect project targets, build settings, and the actual signing configuration.
Open the simulator to reproduce UI issues and check the runtime and device type.
Handle settings that need interactive confirmation, then add repeatable steps to your scripts.

Best for: environment setup, visual debugging, and pre-release manual checks.

First connection

Check credentials once; test each connection path

Sign in to the console and open the relevant instance details. Use the address, username, port, and authentication method shown for that instance. Don’t assume the SSH port is also the VNC port.

01
Get your instance credentials

Check the instance ID and node, then note the SSH and VNC connection details separately. Make sure the instance is ready before connecting for the first time. If the console hasn’t returned the credentials, keep your order details and open a support ticket in the console—don’t guess the address or password.
02
Test command-line access
Connect with the port and username provided for the instance. When you see the host fingerprint prompt for the first time, verify it before continuing. If the fingerprint for the same address changes unexpectedly, stop and check whether the instance was reassigned.
```
ssh -p "$SSH_PORT" "$MAC_USER@$MAC_HOST"
sw_vers
uname -m
xcode-select -p
df -h
```
Set the variables in your local terminal to the values shown in the console. After connecting, check the macOS version, architecture, developer directory, and available disk space.
03
Open screen sharing

On your local Mac, open Screen Sharing and enter the VNC address and port provided for the instance. On other systems, use a compatible client. Sign in using the instance’s authentication method. First confirm that you can see the desktop and move the pointer, then open Xcode. If you can’t connect, check the address, port, authentication details, and local network restrictions in that order.
04
Restrict access

After your first sign-in, update the initial credentials using a method supported by the instance. Manage SSH keys separately for each team member, and never store passwords in your repository. Give the runner a registration token with the minimum permissions it needs. Keep credentials, certificates, and private keys in a controlled secrets management process. Run a minimal build before enabling the production pipeline.

View credentials in the console

Five locations · Network benchmarks

For desktop work, check round-trip latency; for builds, check the data path

VNC interaction depends on round-trip latency. For ongoing builds, the location of your repository, dependency sources, and artifact storage matters more. These are reference ranges for each location—not measurements from your current location or guarantees of connection latency.

Node, service region, and reference round-trip latency; choose a location based on your main workload
Node	Service region	Reference round-trip latency	Best for
Singapore	Southeast Asia	20–50 ms	Interactive development for teams in Southeast Asia; also check repository and dependency download paths.
Japan (Tokyo)	East Asia	30–60 ms	Xcode access for East Asian team members; keep runners and artifact storage nearby where possible.
South Korea (Seoul)	Northeast Asia	30–50 ms	Simulator checks, remote debugging, and project sync for teams in Northeast Asia.
Hong Kong	South China and Southeast Asia	20–40 ms	Screen sharing and day-to-day builds for team members in South China and Southeast Asia.
US East	Eastern North America and Western Europe	25–35 ms	Team collaboration across these regions; choose a location based on where your code and artifacts are stored.

These are reference ranges; actual latency depends on your network.

From your usual work network, try one desktop task, one dependency download, and one artifact upload. Record how responsive the desktop feels, transfer times, and build times separately—don’t reduce them to a single measure of how “fast” the machine is.

Reduce display load first, then check the connection

Save bandwidth for the task at hand

Start with display settings that are good enough for the job. Larger remote displays and more frequent screen changes increase encoding and transfer overhead. Tuning the desktop won’t reduce the compiler’s workload, but it can make interaction more responsive.

Choose a resolution that fits your workspace

Start at 1440 × 900 or 1600 × 900 so you can read the editor and logs comfortably. Increase the resolution only if you need more panels; don’t default to streaming the full screen at high resolution.

Change one setting at a time and compare text clarity with window-drag responsiveness.

Adjust color depth and quality in your client

If your client offers color depth, quality, or compression settings, lower the image quality first on a low-bandwidth connection. Keep code readable, and avoid video playback or constantly refreshing windows you don’t need.

Options vary by client; use the settings available in yours.

Disconnect when you don’t need the desktop

For large file transfers or unreliable networks, use SSH to read text logs and let the configured runner handle builds as a service. Don’t rely on a graphical terminal window to keep a long-running job alive; first make sure the job can run independently of an interactive session.

When you’re done, disconnect the desktop session without logging out of the system or shutting it down.

What remote Xcode development can—and can’t—do

Use the desktop to verify; use the pipeline to reproduce

Turn manual checks into traceable environment changes: record the Xcode version, simulator runtime, and signing settings, then verify them from the command line using the same project. Don’t leave a setting documented only as “clicked once in the desktop.”

Computers and desktop devices in a remote development workspace, illustrating how to access cloud Xcode from a local workstation — Remote development workspace illustration. Screen sharing streams the cloud desktop; it doesn’t automatically connect local peripherals to the remote machine.

What you can do in the cloud

Inspect Xcode projects, build and archive, test in simulators, and configure certificates—all in the remote macOS environment. SSH and VNC access the same files, so avoid manually changing a working directory while the runner is using it.

Plan real-device testing separately

An iPhone connected locally won’t appear in cloud Xcode just because you’ve opened VNC. Real-device testing needs a separate plan for device access and test execution. You can build and sign in the cloud, then use your team’s existing distribution process to deliver the build to test devices.

Manage projects, caches, and artifacts separately

Use scp for one-off files; rsync for repeat updates

Use your repository for version history, and file sync for working copies and artifacts. Don’t transfer certificates, private keys, or tokens alongside ordinary project files. Check ignore rules and the destination path before uploading.

scp: transfer a build artifact

Use scp for a specific archive or asset bundle. The command below downloads an existing archive from the remote machine; replace the remote directory and filename with the actual path.

scp -P "$SSH_PORT" \
  "$MAC_USER@$MAC_HOST:build/ios-build.zip" \
  ./ios-build.zip

The scp port option uses an uppercase -P. After the transfer, check the file size. To verify the contents match, compare checksums on both ends.

rsync: sync a project working copy

Use rsync to sync the same directory repeatedly. Start with a dry run and check the destination path and exclusions; the trailing slash means to sync the directory’s contents.

rsync -avn \
  -e "ssh -p $SSH_PORT" \
  --exclude '.git/' \
  --exclude 'DerivedData/' \
  ./project/ "$MAC_USER@$MAC_HOST:project/"

After checking the dry-run output, change -avn to -av and run the command. No delete option is used, so files missing locally won’t be removed from the remote machine.

Choose a location, then run your first job

Choose the location closest to your team

For interactive development, consider your office network; for ongoing builds, consider where your repository and artifacts are stored. Choose a node when ordering; availability is determined by the live status shown in the console.

Choose a node and rent a cloud Mac Compare benchmarks for all five locations