Remote access guide

Connect to your Mac
within ten minutes of startup

Start by checking connectivity over SSH, then open screen sharing. Your instance is a dedicated physical Mac mini with full access to the macOS desktop and command line—ideal for remote work, builds and testing.

The ten-minute target assumes you have already received your credentials and have your client and network ready. It is not a delivery-time estimate. Always use the connection address, port and authentication method shown in the console.

Rent a cloud Mac Sign in to view credentials
Choose how to connect

Use screen sharing for desktop work and SSH for automation

Use the graphical interface for everyday setup. For builds, logs and file transfers, the command line is usually the better choice. The two connection methods complement each other—you don't need to keep the desktop open during every build.

Ports below are service defaults. Use the ports shown in the console when connecting.
MethodBest forPortAuthentication and notes
macOS Screen SharingSetting up Xcode, using the Simulator, checking the desktop and remote workVNC default: TCP 5900; SSH port also required for tunnellingAuthenticate with the supplied system account. A desktop connection does not replace SSH public-key authentication.
Third-party VNC clientAccessing the macOS desktop from Windows or LinuxVNC default: TCP 5900, or the local tunnel port used by your clientMust support the server's authentication method. Don't disable authentication or allow access from all sources to work around compatibility issues.
SSH command lineRunning builds, viewing logs, registering runners and transferring files over SFTPSSH default: TCP 22; check the console for the public-facing portPublic-key login is recommended. Check the host fingerprint on your first connection before trusting it.

Check the port before troubleshooting the client. If a connection times out, start with the address, outbound network rules and destination port. If you see an authentication prompt, the network path is usually working; check the username, password or key instead.

Follow the steps for your OS

Three clients, one verification sequence

Start an SSH session to confirm the instance identity and working directory, then connect to the desktop. These steps don't require you to disable your local firewall or expose your cloud Mac to everyone.

Connect from macOS

  1. Open Terminal and connect with the username, address and SSH port shown in the console. When prompted about the host fingerprint for the first time, verify it before accepting.
  2. To access the desktop, open Screen Sharing and enter the instance's screen-sharing address. If you're using a tunnel, enter the local listening address and port instead.
  3. Enter the system username and password. Once connected, check the keyboard layout, display resolution and time zone before opening your project.
  4. Before ending the desktop session, make sure build logs have been saved. Disconnecting screen sharing doesn't stop your rental or end background tasks.

First check: Terminal can read system information, Finder opens on the desktop, and you can write to the project directory.

Connect from Windows

  1. Check that the OpenSSH client is available in PowerShell. If your organisation doesn't allow you to install components, check with your IT administrator first.
  2. Verify the address and port with an SSH command. It's normal for password characters not to appear as you type—don't paste the password again.
  3. Install a VNC client that supports macOS Screen Sharing authentication, then enter the host and port. Address formats vary between clients.
  4. We recommend accessing the desktop through an SSH tunnel. If the handshake fails, check authentication compatibility and then the service status. Don't keep guessing passwords.

First check: You can start an SSH session, authenticate over VNC and use the keyboard shortcuts you need.

Connect from Linux

  1. Use the OpenSSH client provided by your distribution. Check your local key permissions and make sure your private key isn't accessible to other users.
  2. Connect over SSH using the supplied details. You can use the same SSH endpoint with SFTP to transfer projects or build artifacts.
  3. Choose a VNC client that supports the server's authentication method. Connect through a local port forwarded over SSH rather than exposing the desktop service directly.
  4. When you first reach the desktop, check the clipboard and input method. Use SFTP for bulk file transfers instead of relying on the desktop clipboard to sync your project.

First check: Key authentication works, SFTP can access the target directory, and desktop input and display work as expected.

SSH and desktop tunnel commands

Set these variables in your local terminal first: SSH_USER is your system username, SSH_HOST is the instance address, and SSH_PORT is the SSH port shown in the console. Never put a password in a command or script.

ssh -p "$SSH_PORT" "$SSH_USER@$SSH_HOST"

ssh -N -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:15900:127.0.0.1:5900 \
  -p "$SSH_PORT" "$SSH_USER@$SSH_HOST"

The second command applies only if the remote screen-sharing service listens on local TCP port 5900 and SSH forwarding is allowed. Leave that terminal running, then connect your VNC client to 127.0.0.1:15900. This is a local port, not the instance's public port. If it's already in use, choose an unused local port.

Keep your session responsive

Reducing screen load helps more than blindly increasing bandwidth

Remote desktop performance depends on round-trip latency, packet loss, how much the screen changes and the client's encoding capabilities. These are starting points, not node speed test results or bandwidth guarantees. Test with your own local network.

Start with a lower resolution for a stable session, then adjust image quality one setting at a time.
Network and workloadStarting resolutionQuality and colour depthWhat to try
Mobile network or variable international connection1280 × 720Start with adaptive compression; try 16-bit colour if your client supports itTurn off desktop animations, pause large file syncs and check whether input feels responsive.
Stable broadband, coding and documents1920 × 1080Start with automatic quality; increase it only if text isn't clear enoughChange one setting at a time and compare scrolling, window dragging and keyboard input.
UI review and image editing1920 × 1080 or higherUse 24-bit or higher colour depth when you need accurate colour, depending on client supportCheck scaling and compression artifacts. Judge the final image quality from the exported file.

Use the desktop to work, not to judge real-time audio or video

Video previews, fast animations and high-frame-rate interactions create more screen changes. You can transcode audio and video remotely, but download the final output and review it locally. Don't mistake dropped frames in the remote desktop for a problem with the exported file.

Try this order: lower the resolution → enable adaptive quality → check for packet loss → adjust colour depth.

Don't rely on an open desktop for builds or transfers

For long builds, use a runner or a manageable background task, and save logs to a file. Transfer projects and artifacts over SFTP. Whether a task continues after you disconnect the desktop depends on how it was started—don't assume every terminal command will keep running.

If you need ongoing access, test a complete work session before choosing a longer rental period.

Know the limits of device testing

Opening the Simulator doesn't mean it can see your phone

A cloud Mac being dedicated to you and a mobile device being reachable over the network are two separate things. Xcode, the Simulator and build tasks can run remotely. Connecting a local iPhone or iPad also depends on device pairing, trust and network discovery.

Option 1: Validate in the remote Simulator first

Open your project on the cloud Mac and check that Xcode, the SDK and project settings are compatible. Then run the Simulator to test the UI, app logic and basic regressions. This is a good way to rule out build and runtime environment issues first.

The Simulator can't replace a real device for testing the camera, sensors, cellular connectivity, performance or thermal behaviour. Arrange separate testing on a physical device when you need to verify these features.

What you'll get: reproducible build records, test logs and Simulator results.

Option 2: Check network requirements for device debugging

Network debugging usually requires the device to be properly paired with the target Mac and compatible Xcode and OS versions. The device and Mac must also be able to discover each other or communicate over a verified network path.

An SSH tunnel won't automatically solve device discovery, initial pairing or trust issues. A reachable public address alone doesn't mean wireless device debugging will work.

Check before ordering: pairing method, network topology, device OS version and the access you need.

Remote device connections need to be validated separately. USB forwarding and other remote-device solutions depend on protocol compatibility, drivers, device reconnection and network quality. They aren't included by default, and no phone is included. If a local device must connect to Xcode on the cloud Mac, send our team the device model, OS version, pairing method and testing requirements so we can check feasibility before you plan the work. If you only need to validate an app package, you can give the signed build to a tester to install on a local device—there's no need to keep a remote debugging session open.

Ask about device testing
After connecting

Secure access before adding projects and keys

A dedicated physical machine keeps your compute resources separate from other tenants, but it doesn't replace account security. Complete these three steps before adding build certificates, code or automation credentials.

  1. Enable public-key login

    Generate a key on a trusted local device and add the public key to the relevant user's authorized keys file on the remote Mac. Keep the private key local; never upload it to the machine or attach it to a support ticket. Open a new terminal to verify key-based login, keep your existing session open as a fallback, and then review your password authentication settings.

  2. Change the supplied password

    Change the system password after your first login and store it in a trusted password manager. Don't put it in runner settings, shell history or a project repository. For team access, assign individually traceable accounts rather than sharing one set of credentials long term.

  3. Allow only the ports you need

    Keep only the SSH and desktop access paths you actually use, and prefer a tunnel when available. Before changing firewall or access rules, confirm your current admin connection and have a way to restore access. Don't disable every protection just to troubleshoot a connection.

What to include in a support ticket

Include the instance ID, client OS and version, connection method, time and time zone, the exact error text, and what happened: timed out, connection refused or authentication failed. You can attach a redacted screenshot, but never include a password, private key or full connection credentials.

Sign in to submit a ticket
Before you connect

Have all four ready before your first login

Check these items in order. If anything is missing, sort it out before you try again. If your organisation's network blocks required outbound connections, request the necessary access rules first.

  • Credentials saved securely
    The instance address, system username, authentication details and actual ports have been confirmed in the console and stored securely.
  • Client installed
    SSH works from the command line. For desktop access, you have a compatible screen-sharing or VNC client ready.
  • Public key added and verified
    If you're using key-based authentication, the public key is installed for the correct user and verified in a new session. The private key stays local.
  • Outbound ports allowed
    You've confirmed the actual SSH port. For a direct desktop connection, check the VNC port too; for a tunnel, check the local listening port.

After your first successful connection, note the client version, connection method and working settings. Teammates can follow the same steps, but shouldn't copy your personal key or password.

Confirm your connection first. Then move your work over.

Test the desktop, command line and your actual workload. Ready to rent? Choose a plan that fits your workload. Already have an instance? Check your credentials in the console.

Rent a cloud Mac Open the console