Remote access · Connect, then build

Connect to your cloud Mac

Use VNC to access the macOS desktop and SSH for scripts and CI. You connect to a dedicated physical Mac, not a virtual machine, so you can use the right connection for Xcode debugging and automated builds.

Rent a cloud Mac Sign in for connection details

Already have a host? Have its address, SSH port, username and connection credentials ready. This guide recommends using an SSH tunnel for VNC.

Desktop access: VNC screen sharing
Command execution: SSH / runner

macOS desktop Example after connecting

Xcode project Release build check

Desktop and command line on the same physical machine

BuildSettings.xcconfigRelease

CONFIGURATION = Release
SDKROOT = iphoneos
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym
ENABLE_TESTABILITY = NO

ArchiveSignExport

Simulator preview

UI check Layout · interaction

VNC: view and control the desktop SSH: run build commands

Illustrative workspace layout, not a live desktop or performance result. The actual interface and tool versions depend on the host configuration.

Choose how to connect

Need the desktop, or just a command line?

When setting up your toolchain for the first time, use screen sharing to check graphical settings. Once your pipeline is stable, let a runner handle command-line tasks. Both methods access the same host, so you don't need a separate build environment for desktop work.

Desktop

VNC screen sharing

Use VNC to open Xcode, check the Simulator, review Keychain settings and troubleshoot tasks that need a mouse. You see the remote host's desktop; compilation doesn't run on your local machine.

Start with a single display and a moderate resolution. Check that text, mouse and keyboard input work as expected.
We recommend connecting through an SSH tunnel instead of exposing the VNC port directly to the internet.
Closing the viewer doesn't shut down the host. Run long jobs in CI or a session you can reconnect to.

Best for: UI debugging, initial setup and interactive troubleshooting

Command line

SSH and self-hosted runners

Use SSH to install dependencies, run xcodebuild, organise logs and register a CI runner. SSH doesn't transmit the desktop, so routine scripting doesn't require an active VNC connection.

Verify the host fingerprint on your first connection before accepting the host key.
Use SSH public keys for interactive administration and separate, revocable credentials for automation.
Run continuous builds with a runner service instead of leaving a terminal open on your laptop.

Best for: automated builds, dependency management and log diagnostics

VNC desktop passwords, SSH login passwords and SSH key passphrases are separate credentials. If a connection fails, check which protocol the credentials belong to before changing client settings.

macOS client

Connect from Finder and share your screen

For the recommended setup, create the SSH tunnel below before connecting to the local forwarding address. VNC traffic then travels through an encrypted connection, without opening a separate port for remote desktop access.

01
Check your host details

Sign in to the portal and open the connection details for your instance. Note the host address, SSH port and username, and check your VNC credentials separately. If the address or port differs from the example, use the values provided for your instance.
02
Keep the tunnel open

Run the forwarding command on this page in a local terminal. With -N, a successful connection won't show an interactive command prompt. Leave the terminal open. If you see an error, resolve it before trying to connect to the desktop.
03
Enter the VNC address

In Finder, choose “Go → Connect to Server” or press ⌘ K, then enter vnc://127.0.0.1:15900. macOS opens the Screen Sharing app. Follow the prompts to enter the remote VNC credentials.
04
Test the connection, then adjust the display

First check that you can use Finder, type text and open Xcode. Select control mode when you need to interact with the desktop, not view-only mode. If the desktop doesn't fit the local window, enable scaling before adjusting image quality for your network.

The loopback address works only on the computer running the tunnel. To use a viewer on another computer, create a separate tunnel on that machine; you can't reuse the first computer's local connection.

Windows / Linux clients

Enter the host and port separately, then start with conservative settings

Use a VNC-compatible viewer such as TigerVNC. On Windows, use the OpenSSH client; on Linux, create the tunnel with ssh in a terminal. Then connect your desktop viewer to the forwarded port on your local machine.

Windows: start SSH, then open your viewer

Run the tunnel command in PowerShell or Windows Terminal. If you see a message that ssh can't be found, check whether the OpenSSH Client feature is installed.

In your VNC viewer, enter 127.0.0.1 as the host and 15900 as the port. Some clients treat the number after a single colon as a display number. If your client has only one address field, use its format for specifying an explicit port.

Keyboard mapping: check Command, Option and common shortcuts first.

Linux: troubleshoot the tunnel and desktop separately

Keep the SSH tunnel running in one terminal, then open your graphical VNC viewer. If the tunnel has stopped, the viewer's failure to connect to the local port doesn't mean the remote desktop password is wrong.

When installing a client through your package manager, choose a version that supports the remote authentication method. If you see “Unsupported security type”, check compatibility instead of disabling authentication or weakening security on the host.

Network check: make sure the client is connecting to the local forwarding port.

These are suggested starting settings, not a promise of image quality or frame rate. Option names vary by viewer version.
Setting	Start with	When to adjust
Colour depth	Automatic; try 16-bit if bandwidth is limited	Use full colour when checking screenshots, colours or small text. Lower colour depth isn't suitable for colour validation.
Encoding and compression	Keep automatic encoding and use adaptive compression	Increase compression slightly if dragging windows stutters. Reduce lossy compression if text looks blurry.
Desktop size	Start with 1440 × 900 or 1600 × 900	Increase the resolution once interaction is stable. Avoid streaming multiple high-resolution screens from the start.
Continuous updates	Use adaptive updates and disable unnecessary continuous refresh	Increase the update rate only when troubleshooting dynamic interfaces. Code editing doesn't need video-level refresh rates.
Clipboard	Enable as needed; turn off syncing for sensitive tasks	Before copying certificate passphrases or credentials, check the sync direction between local and remote systems.

Recommended connection

Route VNC through an SSH tunnel

The addresses below are documentation examples and won't connect as written. Replace 192.0.2.10, macuser and the port with the connection details from your portal. This example assumes the remote VNC service listens on port 5900 on the host itself.

Local viewer127.0.0.1:15900

Encrypted SSH tunnelHost address and SSH port

Remote VNC service127.0.0.1:5900

Run this on your local computer

ssh -N -T -L 127.0.0.1:15900:127.0.0.1:5900 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -p 22 macuser@192.0.2.10

What the command does

-L listens only on the local loopback address. The first port is the local endpoint; the last is the remote VNC service port. -p sets the SSH port, not the VNC port. -N -T forwards traffic without opening an interactive remote terminal.

Check the connection and close the tunnel

Verify the SSH fingerprint on your first connection. Once connected, use your viewer with the local port. Press Ctrl C to close the tunnel. If the local port is already in use, replace 15900 with an unused port and update the viewer address to match.

Troubleshoot one layer at a time

If the connection times out, check the address, SSH port and source restrictions. If authentication fails, check the username and key. If the forwarding target refuses the connection, check the remote VNC service and port. Don't try to fix every connection issue by repeatedly changing passwords.

Test key-based login before disabling password login

Generate a dedicated Ed25519 key for your local machine and protect it with a passphrase. Add only the public key to the remote user's ~/.ssh/authorized_keys. Keep the private key on your local machine; never upload it to a host, repository or support ticket.

If a key with the same name already exists, don't overwrite it. Choose a new filename and specify it with -i when connecting. A public key file ends in .pub; the private key doesn't.

Generate a dedicated connection key

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/armrdp_ed25519

On macOS and Linux, the remote user's ~/.ssh directory is typically set to 700, and authorized_keys to 600. On Windows, restrict access to your local private key using file permissions; don't blindly copy Unix permission commands.

Display and network

Reduce the display load before checking server location

Compilation happens remotely, but desktop responsiveness also depends on your local network, routing between networks, resolution and how much the screen changes. Don't judge build performance by dragging a window in VNC, or treat geographic distance as a direct measure of latency.

01
Start with a smaller display

Use a single display and reduce high-resolution desktops, animated backgrounds and window effects. Changing the remote desktop size reduces the amount of screen data sent more effectively than simply shrinking the local viewer window.
02
Change one setting at a time

Test resolution, colour depth and compression one by one. Repeat the same action, such as opening the same project or dragging the same window. Changing several settings at once makes it hard to tell which one helped.
03
Check the network route

Pause large local file transfers and use a stable wired connection where possible. Compare SSH responsiveness with VNC screen updates. If SSH is responsive but VNC is sluggish, check the display settings before switching machines.

Geographic and time zone reference for 5 locations. These are not city-by-city latency measurements; check the portal for current availability.
Location	Local time zone	What to consider
Singapore	UTC+8	A good first location to test if most of your team is in Southeast Asia.
Tokyo, Japan	UTC+9	If most of your team is in Japan or East Asia, compare the actual network route from your location.
Seoul, South Korea	UTC+9	If most of your team is in South Korea or Northeast Asia, consider your provider's routing.
Hong Kong	UTC+8	If most of your team is in South China or Southeast Asia, check desktop responsiveness and repository access.
Western United States	UTC−8 / UTC−7	Consider this location if most of your team is on the West Coast of North America. The time zone changes with daylight saving time.

If you use the desktop only for occasional setup, also consider the routes to your code repository, dependency cache and artifact storage when choosing a location. For continuous builds, prioritise a stable toolchain and pipeline; you don't need to leave VNC connected overnight.

Connection security

Keep a way to verify access whenever you tighten security

Apply remote security changes in the right order. Confirm that the new method works before revoking the old one. Avoid changing keys, source addresses and authentication policies all at once, so you can identify the cause if something goes wrong.

Before disabling password login

Keep your current SSH session open. In a second terminal, connect with the specified private key and verify that you have the required administrative permissions. Only then adjust SSH password authentication. Check the configuration syntax first, then apply it using the service management method for your system.

Success looks like this: a new session can log in with a public key and run the required commands.

Before restricting source IPs

Check whether your local public IP is static, then allow it in the relevant network or host access rules. Don't treat a temporary home network address as permanent, and don't apply firewall commands to an interface unless you're sure which one it is.

Success looks like this: permitted networks can connect, while other sources can't reach the relevant port.

Rotate credentials regularly

Use separate keys for each team member and automated task. If someone leaves, a device is lost or a key may have been exposed, add and test a new public key before removing the old one. Also check credentials stored in CI and the related access logs.

Success looks like this: the old key is revoked, and the current runner and admin connection still work.

Still can't connect? Pinpoint the failing layer

Sign in to the portal and submit a support ticket with the host ID, client operating system and version, protocol, exact error message, time and time zone, and whether you're using an SSH tunnel. Redact passwords, tokens and other sensitive information from screenshots. Never send a private key or full certificate.

Get connected, then hand builds to a runner

Rent by the day to test things out, from $21.1/day. First make sure SSH and screen sharing both work. Then pin your Xcode and dependency versions so routine builds no longer depend on your local computer staying online.

Rent a cloud Mac Plans and billing