Remote access runbook

Connect to your cloud Mac in order, from connection details to a stable desktop

This guide is for developers who already have their device details. First verify the node, host address, and local network, then establish a VNC session. After connecting, calibrate the display, keyboard, and clipboard to avoid mistaking network issues for host problems.

5 physical nodes available
1 order dedicated physical Mac
365 days node uptime
Rent a cloud Mac now View environment setup guide
Remote access runbook VNC / DESKTOP ACCESS
Run when ready
  1. 01 Check device details Node, address, account
  2. 02 Add remote host Save the correct address
  3. 03 Verify identity Enter details only on a trusted device
  4. 04 Validate the desktop session Check display and input
When a connection fails, do not change several variables at once Verify one thing at a time
Before connecting

Confirm five details before opening the client

The most common remote-connection mistake is repeatedly switching clients before confirming the device status, address, or local network. Check the items below in order to separate account, network, and display issues.

01

Device status

Log in to theconsoleConfirm that the device linked to the order is accessible and that you are viewing the correct instance. Do not reuse the address from a screenshot of an older order.

02

Physical node

Confirm whether the device is located in Singapore, Tokyo, Seoul, Hong Kong, or the U.S. West node. Cross-region routing directly affects input response and screen refresh.

03

Host address

Check the address character by character. Do not copy the port, spaces, or explanatory text along with it. If the address changes, use the information currently shown in the console.

04

Account details

Enter the connection account and password only on a trusted device. Never store connection credentials in code repositories, group-chat screenshots, public tickets, or shared documents.

05

Local network

Prefer a stable wired connection or strong Wi-Fi. Pause sync tasks that consume upstream bandwidth and confirm that your local network is not blocking remote connections.

First connection

Validate your first VNC session in four steps

The following workflow uses a macOS client as an example. Confirm the result after each step; do not jump back and forth between the address, authentication, and display settings.

  1. Step 01

    Get current connection details

    Open the details for the relevant device in the console and record the node, host address, and connection account. If your team manages multiple devices, match each one using its order number and device label first.

    Validation: order, node, and device label match
  2. Step 02

    Add the remote host

    Open macOS Screen Sharing and enter the host address provided by the console. Give the entry a recognizable name, such as the project name, node, and device label.

    Validation: the client starts connecting instead of immediately reporting an address error
  3. Step 03

    Verify the connection identity

    Enter the connection account and password for the device. On the first connection, verify the host information. If it does not match the console record, stop and confirm the address again.

    Validation: authentication succeeds and the target device opens
  4. Step 04

    Open the desktop and validate it

    Wait for the desktop elements to finish loading, then test the mouse, keyboard, window dragging, and clipboard in order. Next, open Terminal and confirm the hostname to avoid running commands on another device by mistake.

    Validation: display, input, clipboard, and hostname are all correct
Display and input optimization

Stabilize interaction before pursuing higher image quality

High resolution, multilingual keyboards, and multiple displays add variables to a remote desktop. Change only one setting at a time, and record input latency and image clarity before and after each change.

Resolution and scaling

On the first connection, use a lower resolution to confirm a stable link, then increase it gradually. If text looks blurry, adjust the client scaling first. Do not change the remote resolution and local display scaling at the same time.

Keyboard layout

Make sure the local input source matches the remote layout. For Chinese, Japanese, and Korean input methods, check language switching and candidate windows. For European keyboards, verify the mapping of Option, AltGr, the backslash, and symbol keys.

Clipboard synchronization

Start by testing two-way copying with a single line of plain text, then test multiline commands. Never transfer passwords, private keys, or unredacted configuration through the clipboard; use a controlled transfer process for large files.

Multiple displays

Complete connection validation in single-display mode before adding a second screen. If you see black bars, inconsistent scaling, or cursor offset, return to single-screen mode and recheck the primary and secondary display arrangement.

Network latency reference

Median ping from key access cities to five nodes

The table compares relative distance and does not represent a fixed result for every user route. Values vary with the local carrier, cross-border routing, Wi-Fi quality, and test time. Before ordering, retest on your actual network.

Test date 2026-08-22
Access carrier Major local fixed-line provider
Test window 14:00–17:00 local time
Sample count 30 per route
Metric Median ICMP round-trip time
Median ping from key access cities to nodes in Singapore, Tokyo, Seoul, Hong Kong, and the U.S. West, in milliseconds
Access city Singapore Tokyo Seoul Hong Kong U.S. West
Shanghai 73 ms 48 ms 55 ms 34 ms 142 ms
Shenzhen 42 ms 66 ms 72 ms 21 ms 151 ms
Taipei 58 ms 31 ms 46 ms 37 ms 126 ms
Osaka 78 ms 18 ms 35 ms 61 ms 113 ms
Seoul 89 ms 37 ms 9 ms 67 ms 128 ms
Singapore 8 ms 72 ms 86 ms 39 ms 168 ms
Los Angeles 176 ms 112 ms 128 ms 151 ms 24 ms

Highlighted values show the lowest median for each access city in this sample. VNC responsiveness is also affected by jitter, packet loss, and upstream bandwidth, so do not choose a node based on a single ping test.

Secure connection practices

Manage your remote desktop as a production access point

A dedicated physical Mac provides resource isolation, but connection security still depends on accounts, credentials, and operating habits. Teams should establish traceable access boundaries for every operator.

  • Use a separate connection account Do not let multiple people share one account long term. Update access permissions promptly when team members change.
  • Set a strong, unique password Do not reuse passwords from code hosting, email, or other systems, and never put them in scripts.
  • Follow least privilege Grant daily build accounts only the permissions required for their tasks. Keep administrative operations separate from automated jobs.
  • Rotate credentials regularly Change the relevant credentials immediately when a member leaves the team, a device is lost, or you notice signs of suspicious login activity.
  • Lock the session when leaving the device Lock the remote desktop even when stepping away briefly, and close local connection windows you no longer need.
Safe to record

Troubleshooting context

Order number, node, time of occurrence, macOS version, client version, reproduction steps, and redacted error logs.

Do not share

Any connection secrets

Passwords, private keys, complete connection credentials, repository keys, and unredacted configuration files must never be shared in public communications.

Troubleshooting

Diagnose by symptom; do not change every setting at once

First record when the issue occurred and what you observed, then start with the easiest condition to verify. Retry once after each check so you can identify which variable affects the connection.

Unable to establish a connection
  1. In the console, confirm that the device, node, and host address belong to the same order.
  2. Check whether the address includes spaces, explanatory text, or an outdated record.
  3. Switch to a stable network and pause sync tasks that use upstream bandwidth.
  4. Record the client error text and time of occurrence, then submit redacted information.
Black screen or desktop not refreshing after connection
  1. Wait for the desktop to finish loading; avoid repeated disconnects and reconnects.
  2. Lower the client image quality or resolution by one level and observe again.
  3. Exit full-screen mode and switch to a single-display setup to rule out display-layout issues.
  4. If the screen is still blank, record whether the cursor is visible and when the display last worked normally.
Noticeable mouse or keyboard input lag
  1. Run multiple ping tests in succession to distinguish consistently high latency from occasional jitter.
  2. Close local large-file uploads, backups, and video calls, then test again.
  3. Lower the remote desktop resolution and image quality, then observe input response.
  4. Check whether a build is continuously consuming processor, memory, or disk resources.
Clipboard not synchronizing
  1. Copy one line of plain text first to rule out rich text and large-content issues.
  2. Test both directions separately: local to remote and remote to local.
  3. Check whether clipboard sharing is disabled in the client.
  4. Re-establish the session and test again. Do not transfer sensitive information through the clipboard.
Incorrect resolution, scaling, or cursor position
  1. Exit full-screen mode and restore single-display mode.
  2. Fix the local scaling ratio, then adjust the remote resolution separately.
  3. Disconnect and reconnect to confirm that the client has read the new display configuration.
  4. Record the local display resolution, scaling ratio, and client version.
Intermittent session disconnects
  1. Record the exact time and duration of each interruption.
  2. Check whether Wi-Fi roaming or a network switch occurred at the same time.
  3. Compare the automation timeline to determine whether the interruption coincided with a high-load task.
  4. Keep redacted client logs and submit a ticket through the console.
CI and desktop in parallel

Keep manual work from disrupting automated builds

A remote desktop and a self-hosted runner can run simultaneously, but both share the processor, memory, disk, and network of the same dedicated physical Mac. Teams need clear monitoring metrics and operating boundaries.

Parallel work runbook Rules for sharing a desktop session and build queue
Observe

Check resource status first

Before starting a large file copy, installing dependencies, or performing graphics work, check processor, memory, disk space, and network usage, and confirm whether a build is running.

Isolate

Use separate work directories

Do not modify the workspace currently used by the runner during manual debugging. Create a separate directory for temporary validation to prevent cleanup scripts from deleting another task's files.

Constrain

Avoid high-impact operations

During a build, do not arbitrarily terminate critical processes, bulk-clean caches, switch toolchain versions, or restart the device. If a change is necessary, pause new tasks from entering the queue first.

Record

Keep an incident timeline

Record the time of the anomaly, repository, runner label, task number, and manual actions. A timeline helps determine whether the cause was network conditions, resource contention, or an environment change.

Recommended validation order Check queue status → Review resources → Perform one action → Record the time → Compare with build logs
Next steps after connecting

Once the desktop is stable, configure Xcode and the runner

First record tool versions, the working directory, and the runner label in the support guide. If the connection is still abnormal, keep the time of occurrence, node, client version, and redacted logs, then contact the team through a console ticket or support email.

support@globemini.com
Configure Xcode and the runner Contact the team with redacted logs