Need a desktop? Use VNC or macOS Screen Sharing. Running builds or scripts? Use SSH. You connect to a dedicated Apple Silicon physical host—not a virtual machine.
Already have an order? In the console, open your instance details to check the IP address, username and access ports, then follow the steps below. The host and port values in this guide are examples.
AV / ACCESS / 03One host, two ways to work
GUI
Use the desktop for interactive tasks
Local VNC client or macOS Screen Sharing
SSH tunnel → host desktop
CLI
Run builds without streaming the desktop
Local terminal or CI runner
SSH → command line and build processes
Host type
Dedicated physical host
Connection details
Instance details in the console
Example ports
SSH 22 / VNC 5900
Recommended setup
Key-based login + desktop tunnel
Use the ports listed for your instance. VNC and Screen Sharing usually use the same desktop service—they are not separate desktops.
Choose a protocol for the task
A better fit for desktop work or automation
Desktop / cross-platform
VNC
A good fit for Windows, Linux and iPad users. Open Xcode remotely, check build settings and handle system dialogs that require a click.
Enter the host address, port and any credentials required by the desktop service.
Use an SSH tunnel where possible; a standard VNC connection is not necessarily encrypted.
Your client must support the authentication method enabled on the host. If they do not match, try a compatible authentication setting.
Choose VNC when you are not using a Mac locally but need the full macOS desktop.
Desktop / Mac client
macOS Screen Sharing
The simplest option when you are using a Mac locally. It opens the built-in Screen Sharing app, so there is no need to install another desktop viewer.
In Finder, choose “Go → Connect to Server” and enter the VNC address.
Use the credentials provided for the host, not your local Mac login password.
When using a tunnel, connect to the forwarded address on your Mac. Keep the remote host address in the SSH command.
Choose Screen Sharing if your local computer is a Mac and you want fewer setup steps.
Command line / automation
SSH
Run xcodebuild, inspect logs, sync projects and manage runners without continuously streaming the desktop. SSH is a better fit for long builds.
Verify the host key fingerprint before authenticating with a password or key.
An interactive SSH session is not a reliable way to manage background tasks after disconnecting.
For persistent tasks, use a runner service or managed background process and save build logs.
Choose SSH when you can run the task as a command or need to connect it to a CI pipeline.
Set up your connection
Four local platforms, the same host details
The table below uses SSH port 22 and VNC port 5900 as examples. If your ports differ, substitute the correct numbers. Check your service credentials against the provisioning details and current host settings rather than assuming they match your SSH password.
Choosing a client and setting connection details
Local system
Desktop client
Desktop address and port
SSH access
Windows
TigerVNC Viewer; first check that it supports the host’s current VNC authentication method.
For a direct connection, use the client’s Host / Port fields. After setting up a tunnel as described below, set Host to 127.0.0.1 and Port to 15900.
Use Windows Terminal with the OpenSSH client and run ssh -p 22 build@HOST_IP.
Linux
Remmina in VNC mode, or TigerVNC Viewer with a compatible authentication method.
Connect through the tunnel at 127.0.0.1:15900. If your client has separate host and port fields, fill them in separately; do not enter a display number.
Use OpenSSH in a terminal. First verify a standard SSH login, then set up local port forwarding.
macOS
Built-in Screen Sharing.
For a direct connection, use vnc://HOST_IP:5900. Through a tunnel, use vnc://127.0.0.1:15900.
Use ssh in Terminal. You can also launch Screen Sharing with the open command.
iPad
A VNC client that supports macOS authentication and SSH tunnelling.
Configure the SSH host and authentication in the client, then set the desktop target to 127.0.0.1:5900 on the host. Field names vary by client.
Use an SSH client that supports key import. Verify key-based login first, then enable the client’s built-in forwarding.
Secure your first login
Verify the connection before moving your work
01
Verify the address and fingerprint
Get the host IP, SSH port and username from the console. Verify the host key fingerprint on your first connection. If the console does not show it, confirm it through a support ticket. Reinstalling the system may change the fingerprint; verify the change before updating your local record. Do not bypass the warning by disabling host key checks.
02
Change the initial password
After your first login, run passwd to change the current user’s password, and check which authentication method the desktop service uses. If it has a separate VNC password, change that too. Never store passwords in a repository, build log or shared script.
03
Verify key-based login
Add your locally generated public key to ~/.ssh/authorized_keys on the host. Keep the private key on a trusted client only. Open a new terminal to confirm that login works before considering stricter password authentication settings. Keep the original session open so you do not lock yourself out.
04
Limit desktop service exposure
Enable the desktop service only when you need it. In macOS, check “System Settings → General → Sharing → Screen Sharing” and limit which users can access it. Before disabling or changing the service, confirm SSH still works. Encrypting the tunnel does not automatically stop the remote port from listening on the public internet.
Generate a key locally; store only the public key on the host
Run these commands locally. Replace build and HOST_IP with the values provided for your host. Set a passphrase for the private key when prompted.
After logging in, create the directory, edit the public key file and set its permissions. Paste the full public key from the previous command on a single line. Do not paste your private key.
Back on your local machine, verify the connection: ssh -i ~/.ssh/armvnc_build -p 22 build@HOST_IP
Open the desktop through an SSH tunnel
Use port 15900 locally and port 5900 on the remote host. The forwarding binds only to your local loopback address, so other devices on your network cannot access it.
Once the command is running without errors, connect your desktop client to local port 15900. On macOS, open another terminal and run:
open 'vnc://127.0.0.1:15900'
The tunnel does not bypass VNC authentication. Close the desktop client when you are done, then press Ctrl + C in the tunnel terminal to stop forwarding.
Lower the image load, then check the network
Tune image quality for the task
These are starting points for troubleshooting, not bandwidth or latency guarantees. Whether you can change colour depth or compression depends on the protocol and client. Change one setting at a time and compare the same action, such as dragging an Xcode window, scrolling through logs or typing a short message.
Everyday coding and build checks
Starting resolution
1440 × 900
Starting colour depth
24-bit
Starting compression
Auto or medium
Prioritise readable text. If the client window is too small, enable proportional scaling first. Avoid increasing both the remote resolution and local scaling at the same time.
Good for: Xcode settings, log checks and occasional desktop tasks.
Long-distance or restricted networks
Starting resolution
1280 × 800
Starting colour depth
16-bit (if supported)
Starting compression
High
Turn off desktop animations and unnecessary previews first. Higher compression may reduce image detail and data transfer, but it cannot eliminate network round-trip time.
Good for: distant hosts, mobile networks and occasional packet loss.
Long-running archives and automation
Primary connection
SSH
Desktop session
On demand
Task management
Runner service
If you do not need to see the desktop, save build logs and artifacts directly. Disconnecting a desktop client does not log macOS out, and should not be used to stop a task.
Good for: persistent CI, unattended scripts and repeat builds.
Choose a host based on the workload: interactive desktop performance depends more on the network route between you and the host, while builds also depend on repository, dependency and artifact transfer routes. A smooth mouse movement does not tell you how fast a build will compile.
Narrow it down by symptom
Check the network, authentication and desktop session separately
Test SSH first, then the desktop connection. If SSH works but VNC does not, focus on the desktop service and tunnel target. If neither works, check the instance status, address, local network and ports. Reinstalling the system should not be your first step.
The connection keeps dropping. Do I need to restart my task after reconnecting?
First check whether the connection dropped or the task ended. After reconnecting over SSH or to the desktop, check the original process and its logs. Do not immediately submit another archive job: concurrent jobs may compete for resources or publish duplicate artifacts.
The SSH keepalive options above can help detect a dead connection, but they will not fix persistent packet loss. Test a wired local connection or another trusted network and compare the results against the same host. Run long jobs through a runner service or managed background process rather than relying on a terminal that stays open.
pgrep -fl xcodebuild
tail -n 80 ~/build.log
The second command applies only if you have saved logs at that path. If the file is not there, check the log location configured in your build script.
The screen goes black after locking. Should I restart the host?
Disconnect the desktop client, then reconnect and make sure “view only” mode is off. Check whether the client can still display the authentication screen. A black screen after authentication is a different issue from being unable to connect at all.
If SSH is working, keep the session open and check Screen Sharing settings, permitted users and the current session. Do not repeatedly force-quit system graphics processes or restart the host while a build is running. If the issue persists, open a support ticket in the console and say whether the screen went black before or after locking, along with the client name and version.
The desktop is visible, but the clipboard is not syncing
Make sure the client allows clipboard sharing and that “view only” mode is off. Test two-way copy and paste with a short plain-text snippet first. Images, files and rich text may not work over the same clipboard channel.
Check whether the client requires you to send clipboard contents separately, and reconnect if needed. Use SCP or SFTP to transfer project files. Do not use passwords, private keys or signing credentials to test clipboard sharing.
SSH times out or reports an authentication failure
A timeout usually happens before authentication. Verify the IP address and port, check whether your local network blocks that port, and use verbose output to see where the connection stops. If you see Permission denied, check the username, public key, file permissions and the private key selected by your client.
ssh -v -i ~/.ssh/armvnc_build -p 22 build@HOST_IP
Before sharing logs, remove unnecessary sensitive details such as usernames, IP addresses and local paths. Never send a private key or password. If the host fingerprint has changed, check whether the system was reinstalled or the instance changed. Do not delete the verification record without checking first.
The display size is wrong, or keyboard symbols do not match
If part of the screen is cut off, check the client’s fit-to-window or scaling settings, then check “System Settings → Displays” on the host. Resizing the client window alone may not change the remote desktop resolution.
If keys are mapped incorrectly, check your local keyboard layout, client key mapping and the remote input method. Test letters, numbers and symbols in a plain text editor before entering a password or command. Windows Ctrl / Alt and macOS Command / Option may need separate mappings.
Connected? Start your first build
Prepare your environment with the getting started guide, or visit the help centre for provisioning, connection and billing questions. If you have not rented a host yet, choose a model and location on the order page.
Payments accepted: USDT-TRC20 and Visa / Mastercard / Amex (via Stripe). Prices are in USD. Available payment gateways are confirmed at checkout.