One key per person
Do not let multiple people share one private key. Individual keys make it easier to identify users, revoke access separately, and reduce the risk that one leak affects the entire team.
REMOTE ACCESS / CONNECTION GUIDE
Connect to your Cloud Mac by desktop or command line
Use browser remote desktop from the console when you need Xcode, system settings, or graphical tools. Use SSH for builds, file synchronization, or automation. Both methods connect to the same dedicated physical machine, where your files, dependencies, and runtime environment remain available on the node.
Runs 365 days a year
Dedicated physical machine
Not a virtual machine
DISPLAY
1920 × 1080
KEYBOARD
Local mapping
$ ssh node-user@$NODE_HOST
Host key verified
macOS session ready
$
Physical node online
SSH / DESKTOP
01 / CHOOSE A METHOD
Choose your connection method by task
Browser remote desktop and SSH serve different purposes. The former provides a full macOS graphical interface, while the latter is ideal for scriptable, low-bandwidth, and long-running tasks.
| Comparison | Browser remote desktop | SSH |
|---|---|---|
| Best for | Xcode graphical work, system settings, app interface checks, and keyboard and display configuration | Build scripts, Git operations, dependency installation, log inspection, automation, and batch file processing |
| Interaction | A remote desktop displayed in your browser, controlled with your local keyboard and pointer | A terminal command line that supports keys, terminal multiplexers, and scripts |
| Before you start | The node is online, your browser allows required session features, and you have the node login details | Node address, username, private key file, and a verified first-time host fingerprint |
| Network guidance | Prioritize a stable connection; reduce resolution and color quality when latency is high | Lower bandwidth requirements; use a terminal multiplexer and write logs to a file for long-running tasks |
| How to exit | Save your work first, then exit the desktop session or close the remote view | Use exit to end the session normally without interrupting tasks that are still writing |
Tip: On your first connection, use browser remote desktop to verify system status and keyboard layout, then configure SSH keys. For daily development, keep the desktop available for graphical work while running builds and synchronization through SSH.
02 / GRAPHICAL INTERFACE
Open browser remote desktop from the console
The complete process usually includes checking node status, verifying credentials, establishing the session, and adapting local input. If the desktop does not load, do not repeatedly submit login requests.
-
01
Open node details
Sign in to the console and find the target node in the instance list. Confirm that the node ID, region, and status match your order, then open the connection entry once the status shows online. If your team manages multiple Cloud Macs, verify the node ID first to avoid entering the wrong environment.
Check Node ID · Region · Online status -
02
Verify login details
Use the login details shown by the console for this node; do not reuse credentials from another node. When pasting, check for spaces at the beginning or end. If access is handed over within your team, use a controlled credential process rather than sharing it in group chats or build logs.
Check Username · Credential scope · Input spaces -
03
Enter the desktop and test input
After the desktop loads, open a text area with no sensitive content and test letters, numbers, symbols, Command, Option, and switching between language inputs. If keystrokes do not match your local keyboard, align the local and remote system layouts before entering certificates or commands.
Test Symbol keys · Modifier keys · Input method -
04
Adjust resolution and display quality
For text editing and Xcode work, start with 1920 × 1080 . If the display has noticeable latency, lower the resolution first, then reduce color quality. Once the network is stable again, raise each setting one at a time to identify which setting caused the lag.
Starting point 1920 × 1080
When the page is blank
Wait for the current connection to finish, then refresh the node details once. Confirm that your browser is not blocking required session features, and retest in a separate window without extensions.
When keys are mapped incorrectly
Record the key pressed, the expected character, and the actual character. Align the local and remote layouts first, then check whether the browser is intercepting shortcut keys.
When the display is blurry
Confirm that browser zoom is at the standard level, then match the remote resolution. Do not change browser zoom, system scaling, and remote image quality at the same time.
03 / COMMAND LINE
Establish a verifiable SSH session
Before connecting over SSH, confirm the address, username, and source of the private key. The first host fingerprint must be compared with the console record; never skip this check.
Create a dedicated key
LOCAL
ssh-keygen -t ed25519 -f ~/.ssh/mw_nodeCreate a separate key for the MacWorker node and set a local passphrase. Do not overwrite the default key already used by your team.
Set connection parameters
LOCAL
export NODE_HOST="Node address shown in the console"
export NODE_USER="Username shown in the console"Use the address and username currently shown in the console. These environment variables apply only to the current terminal session and keep connection parameters out of repeated command history.
First connection
VERIFY
ssh -i ~/.ssh/mw_node "$NODE_USER@$NODE_HOST"When the terminal displays the fingerprint, pause and compare the algorithm type and complete fingerprint character by character with the console record. Confirm the connection only when they match exactly.
Exit normally
REMOTE
exitBefore exiting, confirm that file writes, dependency installation, and build tasks are complete. Put long-running tasks in a recoverable session instead of relying on a single terminal window to stay connected.
04 / SECURITY BASELINE
Limit access to the right people and nodes
A dedicated physical node does not share compute resources with other tenants, but your team still needs to manage keys, credentials, membership changes, and login records.
Restrict credential sharing
Do not store credentials in code repositories, build logs, or project documentation. When a handoff is required, use a team-approved controlled process and review the access scope afterward.
Revoke member access promptly
When a member leaves the project or changes roles, remove the corresponding public key and console access the same day. Also rotate any shared credentials they may have accessed.
Review login records regularly
Review login times, sources, and failed attempts at least once per team release cycle. If activity falls outside expected working hours or regional patterns, freeze the relevant credentials before investigating.
After every membership change
Remove public keys and console access
Every release cycle
Review login records and active keys
After suspicious activity
Stop using old credentials and preserve a timeline of evidence
05 / FILE TRANSFERS
Move inputs and artifacts over encrypted connections
Before uploading, identify the files the task actually needs. When downloading, retrieve only the target artifacts. Dependency caches, temporary directories, and historical archives should not be transferred with the entire project by default.
UPLOAD
Upload build resources
scp -i ~/.ssh/mw_node -r ./BuildInput "$NODE_USER@$NODE_HOST:~/Work/"Use this for a one-time upload of a clearly defined directory. Exclude local logs, temporary artifacts, and unnecessary historical files before transfer, and confirm that the destination has enough disk space.
DOWNLOAD
Download build artifacts
scp -i ~/.ssh/mw_node "$NODE_USER@$NODE_HOST:~/Work/output.zip" ./Artifacts/Organize and verify the artifact on the node first, then download a single archive. After downloading, compare the file size or checksum so incomplete artifacts do not enter the next stage.
Control large file transfers
01
Narrow the scope first
Sync only the current branch and resources required for the task; do not copy the entire working directory by default.
02
Split transfers into batches
Batch transfers on high-latency networks and avoid periods of local network congestion.
03
Verify last
Keep the source files and delete intermediate archives only after confirming that the size and checksum match.
06 / SESSION OPTIMIZATION
Reduce interaction costs on high-latency connections
First determine whether the problem is with graphical transmission or command execution. A laggy remote desktop does not necessarily indicate reduced node performance; if SSH responds normally, adjust display settings first.
DISPLAY
1920 × 1080
Start with a moderate resolution
Keep one display area and a moderate resolution initially. If latency is noticeable, lower the resolution step by step without changing multiple parameters at once. Increase text clarity after interaction becomes smooth.
COLOR
Lower step by step
Prioritize input responsiveness
Coding and system configuration usually do not require the highest color quality. Lower image quality to reduce screen updates, then restore it temporarily for visual checks.
TERMINAL
tmux
Keep tasks running through brief network drops
Run builds, tests, and dependency work in a terminal multiplexer session, and write output to a log file at the same time. Reconnect and resume the session instead of starting the task over.
tmux new -s build
tmux attach -t build
RECOVERY
Save state
Prepare recovery points for disconnects
Break long workflows into repeatable steps, write output to a fixed directory, and record the most recently completed stage. After a disconnect, check processes and artifacts before restarting anything.
07 / QUICK TROUBLESHOOTING
Narrow connection issues by symptom
During troubleshooting, keep the node ID, time of occurrence, connection method, and complete error summary. Change only one variable at a time so you can identify what actually fixed the issue.
SSH reports authentication failure
Check the username and private key path first, then verify the private key permissions and that the public key is configured on the target node. Use verbose mode to confirm which key the client actually tried:
ssh -v -i ~/.ssh/mw_node "$NODE_USER@$NODE_HOST"Do not send a complete private key or detailed logs containing sensitive fields to anyone else. When submitting a ticket, provide only the error stage, algorithm information, and a sanitized summary.
The page is blank after connecting in a browser
Confirm that the node is still online and wait for the current session to finish establishing. Then retry in a separate browser window without extensions and check whether the browser is blocking required session features. If SSH connects but the desktop remains blank, record the browser version, time of occurrence, and node ID before submitting a ticket.
Keyboard symbols or modifier keys are mapped incorrectly
In a text area with no sensitive content, record the expected and actual characters, then compare the local and remote keyboard layouts. Check whether Command, Option, or Control is being intercepted by the local system or browser shortcuts. Retest each key after adjustment; do not experiment directly in a credential field.
Desktop or SSH connection times out
Check the local network, target address, node status, and client settings in that order. Retest on a known-stable local network first, then confirm that the address has not expired or been copied incorrectly. If both connection methods to the same node time out, record the local time, network, and duration of the error.
SSH reports that the host fingerprint has changed
Stop the connection immediately. Do not bypass the warning by disabling verification or deleting the known-hosts record. Confirm whether the node address changed, then verify the new fingerprint and reason for the change through the console. Remove the old record for that address and reconnect only after verification is complete.
Minimum information for a support ticket: node ID, time and time zone, connection method, client and version, complete error summary, and troubleshooting steps already performed. Do not include private keys, passwords, payment credentials, or project source code.
READY TO CONNECT
Choose a node and connect directly from the console
Confirm that the node is online, then open browser remote desktop or configure SSH based on your task. When you need both graphical tools and command-line collaboration, both sessions can connect to the same dedicated physical Mac.