Secure Connection and Toolchain Verification

Connect to Your Cloud Mac with VNC and SSH

Check node status and host fingerprints before starting a graphical or command-line session. This guide covers first login, key setup, Xcode build verification, remote performance optimization, and troubleshooting.

Rent a Dedicated Mac Now Open the Console to View Your Node

The connection address, username, and temporary credentials are provided only after the node passes the order check. Availability and connection parameters are based on the console’s real-time response.

Pre-connection checks VNC graphical connection SSH command-line connection Toolchain verification Node latency reference Troubleshooting
Before you begin

Confirm these six connection requirements

Do not start by repeatedly retrying a password. Check the node, region, credentials, and local network first to quickly distinguish delivery, authentication, and network issues.

Node status

Open the console and confirm that the instance is ready to connect, then record the node ID. If the node is still initializing, do not save an unverified host fingerprint.

Connect after the status is ready

Node region

Confirm that the order region matches the instance region. The current catalog covers Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East, and the US West.

Region / Node ID

Username and temporary credentials

Copy the username provided in the console exactly, including capitalization. Change the temporary password immediately after your first login, and configure key-based authentication for SSH first.

Do not forward credentials by regular email

Local network

Test first on a stable wired connection or reliable Wi-Fi. Corporate proxies, guest networks, and public hotspots may restrict the ports required by SSH or VNC.

First rule out VPN and proxy interference

System firewall

Confirm that your local firewall allows the client to make outbound connections. If you connect through an office network, ask the network administrator to verify the destination and port policies.

SSH 22 / VNC 5900

Connection details

Compare the host address, port, username, and region. Do not reuse a client configuration saved for an old node with a newly assigned physical node.

Create a new connection profile for the new node
Security boundary

Read connection parameters only from the console. Do not submit private keys, complete passwords, access tokens, or unsanitized build logs to ordinary documents or code repositories.

Graphical interface

Make Your First Graphical Connection with VNC

VNC is suitable for the Xcode graphical interface, signing and archive checks, and tasks requiring desktop interaction. For your first connection, configure the address, authentication, image quality, and exit settings in order.

  1. 01

    Enter the address and port returned by the console

    Create a new connection in your VNC client and copy the host address exactly. If the console provides a custom port, use that port; do not guess or reuse parameters from an old instance.

    Check:The region label in the client configuration must match the order region.
  2. 02

    Authenticate with the node username

    Enter the node username and temporary credentials provided by the console. If authentication fails repeatedly, stop, copy the username again, and check your keyboard layout to avoid triggering security limits.

    Check:Make sure no spaces or line breaks were copied before or after the credentials.
  3. 03

    Adjust display quality for the connection

    Start with adaptive resolution and medium color quality to establish a stable baseline. For cross-continent connections, lower the resolution, color depth, and refresh rate, then increase image quality one setting at a time.

    Recommended starting point:1920 × 1080, 100% scaling, dynamic image quality enabled.
  4. 04

    Test the clipboard with non-sensitive content first

    Copy ordinary text and confirm that the local and remote clipboards work as expected in both directions. Do not use passwords, private keys, or access tokens to test clipboard functionality.

    Boundary:Disable clipboard synchronization as needed in shared team environments.
  5. 05

    End the session without interrupting tasks

    Before closing the window, confirm whether a build is running in the foreground. Delegate persistent tasks to a CI runner, launchd, or terminal session manager so a VNC disconnect does not terminate the foreground process.

    Check:After exiting, confirm in the console that the node is still running normally.
Command-line access

Use SSH for an Auditable Development Entry Point

SSH is ideal for repository synchronization, dependency installation, automated builds, and log collection. On the first connection, verify the host fingerprint rather than simply skipping the prompt, then minimize long-term permissions.

Stop immediately if the fingerprint does not match

Do not simply delete the local record and reconnect. First confirm whether the node was reinstalled, reassigned, or had its address changed, then verify the details through a console ticket.

01

Verify the host fingerprint

During the first connection, compare the fingerprint shown in the terminal segment by segment with the information provided in the console. If the address is unchanged but the fingerprint has changed, treat it as a security event rather than ignoring the warning.

02

Prefer key-based login

Use a separate public key for each team member and automation task. Keep private keys on controlled devices or in a key management system; do not upload them to shared node directories.

03

Minimize file and command permissions

Set private key files to be readable only by the current user. Grant CI tasks access only to the directories and commands required for the build; do not use administrator privileges by default.

04

Update the temporary password

Set a separate strong password immediately after the first login. Confirm that key-based login works before restricting password authentication according to team policy, so you do not disable the only working entry point first.

Generate a dedicated SSH key

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/hexvm_node
chmod 600 ~/.ssh/hexvm_node
ssh-add ~/.ssh/hexvm_node

Generate separate keys for members, CI runners, and temporary operations tasks so each can be revoked independently.

Make the first connection

ssh-keyscan -p "$NODE_PORT" "$NODE_HOST"
ssh -i ~/.ssh/hexvm_node \
  -p "$NODE_PORT" "$NODE_USER@$NODE_HOST"

Verify the displayed fingerprint first, then accept the host record. Copy variable values from the console; do not commit real credentials to scripts.

Development toolchain verification

From SSH Login to a Successful Archive

After connecting, verify the environment with version checks, a test build, and an archive command. Start with a small-scope check before connecting the full pipeline.

hexvm-node — zsh — 120 × 34 SSH
$ssh -i ~/.ssh/hexvm_node "$NODE_USER@$NODE_HOST"
Authenticated with public key.
Last login: current session from approved network
$sw_vers && xcodebuild -version
ProductName: macOS
Xcode 16.x
$xcodebuild test -scheme MobileApp -destination 'platform=macOS'
** TEST SUCCEEDED **
$bundle exec fastlane archive
Resolving signing settings...
Exporting archive artifact...
Archive completed successfully

Check versions first

Record the macOS, Xcode, and command-line tool versions, and ensure that the interactive terminal and CI runner use the same toolchain selection.

Run the smallest test next

Run a single scheme or test target first to isolate dependency, signing, and environment-variable issues before expanding to the full workspace.

Add archiving last

After the archive succeeds, check the artifact path, file permissions, and log-redaction rules before moving the command into an automated pipeline.

Network latency reference

Median round-trip latency across six node regions

The data below is for initial region screening and does not represent a fixed result for every network. Before making a final choice, repeat the test from the actual office network and CI egress.

Test window 14:00–16:00 local time on business days
Network conditions Local fixed broadband, with VPN and proxy disabled
Method Median of 20 ICMP round trips per path
Unit ms
Median network latency from major client test locations to the six HexVM node regions
Client test location Singapore Japan (Tokyo) South Korea (Seoul) Hong Kong US East US West
Beijing fixed broadband 78 ms 54 ms 47 ms 42 ms 198 ms 146 ms
Shanghai fixed broadband 69 ms 41 ms 49 ms 35 ms 190 ms 132 ms
Taipei fixed broadband 48 ms 32 ms 43 ms 24 ms 181 ms 112 ms
Manila fixed broadband 39 ms 71 ms 76 ms 36 ms 214 ms 139 ms
Los Angeles fixed broadband 177 ms 104 ms 119 ms 151 ms 68 ms 21 ms
New York fixed broadband 231 ms 168 ms 181 ms 205 ms 19 ms 73 ms
< 60 ms

Suitable for sustained graphical work

Keyboard input, window switching, and routine Xcode operations are usually smooth, but packet loss and jitter still need monitoring.

60–140 ms

Suitable for builds and light interaction

Graphical work is possible after lowering image quality. Command-line builds, log viewing, and CI tasks are usually not significantly affected.

> 140 ms

Prioritize command-line and automation

For cross-continent connections, delegate sustained work to SSH, CI runners, and background tasks, using VNC only for essential checks.

Actual latency is affected by the local carrier, international egress, routing changes, office proxies, Wi-Fi quality, and traffic at the same time. The combinations listed in the region catalog are generally available to order; actual availability is shown in real time by the console.

Performance optimization

Stabilize remote sessions instead of simply pursuing maximum image quality

Separate interactive work, persistent tasks, and large-file transfers to reduce the effect of network jitter on build workflows.

01

Start with a single-screen resolution baseline

Start with a single screen at 1920 × 1080 to establish a stable baseline. On high-latency connections, avoid enabling dual screens, high scaling, and frequent dynamic adjustments immediately.

  • If text is too small, adjust system scaling first instead of increasing the resolution blindly.
  • On mobile networks, use a fixed window size first to reduce repeated screen redraws.
02

Choose color quality based on the connection

Code editing, build logs, and configuration work do not require maximum color accuracy. When the connection fluctuates, lower color depth and image quality first, then check input latency.

  • Temporarily increase image quality for design reviews and video tasks.
  • For routine development, prefer adaptive compression and a static background.
03

Disable unnecessary audio and video transmission

Remote development centers on code, terminals, and build status. Disabling unused audio, camera redirection, and animation effects can reduce bandwidth usage.

  • Avoid playing high-bitrate media in a VNC session.
  • Disable unrelated desktop effects and continuously refreshing monitoring windows.
04

Run persistent tasks outside interactive sessions

Run long builds, tests, and dependency downloads in a dedicated terminal session, CI runner, or system task. A VNC or SSH disconnect should not directly end the task.

  • Write task output to a dedicated log file and record the exit code.
  • After reconnecting, check the process status before starting the same build again.
05

Use resumable transfers for large files

Use transfer methods that support incremental updates and verification for repositories, caches, and build artifacts. Do not move large files through the graphical clipboard or place sensitive artifacts in public locations.

  • Compress many small files before transferring them to reduce round-trip overhead.
  • After completion, verify the file size, checksum, and access permissions.
06

Put caches in the right location

Isolate dependency caches and DerivedData by project, branch, or toolchain version. If the hit rate drops, analyze the cache key first instead of expanding disk usage indefinitely.

  • Regularly remove invalid caches and old archives.
  • When disk space is low, locate large directories first, then delete files.
Troubleshooting

Narrow down connection issues by symptom

Change only one variable at a time, and record the node ID, region, occurrence time, and complete error text. This is the only way to determine whether the issue is local, network-related, authentication-related, or node-side.

Connection timeout: the client does not respond for an extended period
  1. Confirm in the console that the node status and connection address have not changed.
  2. Check the port, then retest after temporarily disabling the local VPN or proxy.
  3. Test separately over a home network and a mobile hotspot to determine whether the office network restricts outbound connections.
  4. Record the timeout time, region, client network, and target port, then submit a console ticket.
Authentication failed: username, password, or key rejected
  1. Copy the username returned by the console again and check capitalization and leading or trailing spaces.
  2. Confirm that you are using the current node credentials, not a password or key saved for an old instance.
  3. If the SSH key fails, check the private key path, file permissions, and whether the corresponding public key is configured.
  4. Stop retrying after repeated failures. Request verification through a console ticket and do not send complete credentials by email.
Laggy display: connection works but input latency is noticeable
  1. Reduce to a single screen at 1920 × 1080, then disable high color quality and audio/video transmission.
  2. Check local Wi-Fi signal, packet loss, and background downloads; switch to a wired connection first.
  3. Compare VNC and SSH responsiveness. If SSH is normal, prioritize adjusting graphical encoding and display parameters.
  4. For cross-continent access, run long builds in the background and use VNC only to check essential interfaces.
Host fingerprint changed: SSH displays an identity warning
  1. Stop connecting immediately. Do not use a command that skips verification.
  2. Confirm whether the node was reassigned or reinstalled, or whether the connection address came from an old configuration.
  3. Retrieve the current fingerprint from the console and compare it segment by segment.
  4. If you cannot confirm the cause, submit a console ticket with the node ID, region, and redacted warning text.
Port unreachable: network test returns a refusal
  1. Confirm that the protocol and port match; do not enter the SSH port in the VNC client.
  2. Check the local firewall, corporate egress policy, and outbound rules in security software.
  3. Test the same address and port from another independent network to determine whether the issue is limited to one carrier path.
  4. If the port is unreachable from multiple networks, submit a console ticket and include the test results and scope of impact.

Prepare this information before submitting a ticket

Node ID Node region Time the issue occurred Local network type Client and version Complete reproduction steps Redacted error logs Scope of impact

Do not submit private keys, complete passwords, access tokens, or logs containing sensitive signing material. If you need further assistance, sign in to the console to submit a ticket or email support@hexvm.com.

Submit a console ticket Visit the Help Center
Dedicated Apple Silicon nodes

Choose your dedicated Mac and start connecting in about 4 minutes

Each order includes an independent Mac mini physical node, not a virtual machine. Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East, and the US West operate year-round, 365 days a year.

All charges are settled in USD. Actual node and region availability is shown in real time by the console.

Rent a Dedicated Mac Now View Rental Plans