LemonVM provides dedicated Mac mini physical nodes. Use SSH first for command-line builds, log collection, and automation; use VNC for Xcode GUI work, remote editing, and tasks that require a full desktop. Before connecting, get the host address, port, username, and initial credentials from the console.
The same cloud Mac can handle command-line and graphical tasks at once. A reliable setup uses SSH for long-running tasks and diagnostics, and VNC for work that requires the desktop to be visible.
Ideal for xcodebuild, fastlane, dependency installation, repository synchronization, log inspection, and background scripts. During brief network instability, use a session-keeping tool to keep remote tasks running.
Use VNC for the Xcode GUI, simulators, asset management, editing timelines, and other tasks that require seeing the desktop state. When latency is high, lower image quality and resolution before reconnecting repeatedly.
Do not reuse an address or port from another order. Always use the connection details shown in Console for the current service.
Copy the host address and SSH port from the current service details. The address, port, and node together define the connection target; verify them again after switching nodes or services.
The username must match the connection details exactly. Do not substitute your local computer username, repository account, or a team member’s name in the SSH command.
The private key file must be readable only by the current local user. On macOS or Linux, run chmod 600 ~/.ssh/lemonvm_key, then use -i to specify the file.
When the host fingerprint appears on the first connection, compare it with the information shown in Console. Write it to known_hostsonly when the values match; do not skip the check.
Add Host, HostName, User, Port, and IdentityFile to your local SSH configuration to reduce manual input errors, but never put private key contents in the configuration file.
ssh -i ~/.ssh/lemonvm_key -p Port username@host-addressStart the first connection with medium image quality and a lower resolution. After confirming that input, clipboard, and window switching work normally, adjust display settings based on available line capacity.
Use the VNC host and port provided in Console; do not reuse the SSH port. If the client requires a combined address, enter the host and port in the client’s format.
Prioritize responsive mouse, keyboard, and windows. Once text is clear enough, increase color and image quality instead of consuming all available bandwidth on the first connection.
Higher resolutions increase the amount of data sent per frame. On weak connections, start with one display and a lower resolution, then adjust the remote desktop size after the session is stable.
After connecting, test bidirectional copying with text that contains no sensitive information. Never transfer private keys, complete access tokens, or long-lived credentials through a shared clipboard.
Note the shortcuts for exiting full screen and releasing keyboard capture in the client. This prevents remote key combinations from being intercepted locally and mistaken for a session failure.
If the VNC display freezes, use SSH first to check load and network status. If SSH still connects, the physical node is usually online and the issue is more likely in the graphical session or network path.
Change only one variable at a time during diagnosis. Verify the SSH handshake first, observe network probing next, and finally run a verifiable remote command. This separates credential, port, network-path, and task-environment issues.
Connecting to with no response: check the address, port, and local egress restrictions.$ ssh -v -p Port username@host-address
debug1: Connecting to host [address] port [port]
debug1: Server host key: SHA256:[fingerprint]
debug1: Authentication succeeded (publickey)
$ ping -c 5 host-address
5 packets transmitted, 5 packets received
round-trip min/avg/max = 41.2/44.8/49.1 ms
$ ssh lemon-node "xcodebuild -version"
Xcode [current version]
Build version [current build number]
$ ssh lemon-node "cd ~/project && xcodebuild build"
** BUILD SUCCEEDED **The table shows relative differences from major access locations to Singapore, Tokyo, Seoul, Hong Kong, and the US West. Interactive VNC depends more on latency and jitter, while background builds depend more on connection stability and sustained throughput.
| Access location and carrier | Singapore | Tokyo | Seoul | Hong Kong | US West |
|---|---|---|---|---|---|
| Shanghai · China Telecom | 68 ms | 42 ms | 51 ms | 35 ms | 146 ms |
| Beijing · China Unicom | 91 ms | 54 ms | 46 ms | 58 ms | 139 ms |
| Shenzhen · China Mobile | 53 ms | 67 ms | 76 ms | 24 ms | 168 ms |
| Taipei · Fixed broadband | 62 ms | 39 ms | 48 ms | 31 ms | 126 ms |
| Los Angeles · Business fiber | 171 ms | 112 ms | 124 ms | 143 ms | 27 ms |
How to read: For the same access location, compare the horizontal values first; for VNC, also monitor jitter and packet loss over time. Actual connection quality depends on local Wi-Fi, carrier egress, cross-border routing, and background transfers.
Do not switch nodes, change image quality, and restart the client at the same time. Follow these six steps one by one and record latency, packet loss, or interaction response before and after each change.
Switch to wired networking or stable 5 GHz Wi-Fi, and pause local downloads and cloud sync. If other devices on the same LAN also experience jitter, fix the local link first.
Probe continuously for at least several minutes to distinguish stable high latency from intermittent packet loss. Short spikes are more likely to cause VNC mouse jumps and frozen frames.
Choose the node closest to your primary access direction among Singapore, Tokyo, Seoul, Hong Kong, and the US West. Teams should prioritize the direction of the main operator or build dependencies.
First lower color quality, compression level, or frame rate, then check whether input response improves. If the image is clear but interaction is slow, do not simply increase the bandwidth setting.
Temporarily switch to one display and a lower resolution. If responsiveness improves significantly, the data volume per frame exceeds what the current connection can handle comfortably.
Check repository pulls, dependency downloads, asset uploads, artifact transfers, and remote synchronization tasks. Schedule large-file transfers separately from real-time VNC work.
The security boundary for remote access consists of local keys, initial credentials, session locking, and team handoffs. Never paste long-lived access details into public chats or repositories.
Use separate keys for different devices and store private keys only on controlled endpoints. Remove the corresponding public key promptly when a device leaves the team or is lost.
After completing the initial environment check, update temporary credentials. Do not leave directly usable access details in scripts, build logs, or repository configuration.
Lock the remote desktop when stepping away temporarily; do not close background tasks that are still running. In shared workspaces, lock the local computer as well.
When collaborating, record who performed each task and when; do not share one long-lived key. During handoffs, document the task status, log location, and next steps.
A missing VNC display does not mean the physical node has stopped. Confirm the status through another connection channel first to avoid restarting builds, overwriting output, or interrupting active tasks.
Check the local network first, then test the target host and port. After the network recovers, reconnect and review task logs and process status instead of rerunning the original command immediately.
Check: local egress, target port, most recent log timestampCheck the current service status in Console, then use SSH to verify system responsiveness. After recovery, check power and session settings to prevent unsuitable sleep during long-running tasks.
Check: SSH response, system time, running processesLower display settings and re-establish the graphical session. Do not restart the entire node before confirming task status; background builds may still be running normally.
Check: remote load, graphical session, client settingsAfter reconnecting, read the logs, exit code, and artifact directory. Start another build only after confirming that the original task has finished or failed, preventing concurrent writes to the same output location.
Check: process ID, exit code, artifact modification time