This guide organizes node address checks, host fingerprint verification, Xcode graphical workflows, code transfers, network tuning, and secure sign-out into one clear sequence. Use SSH for command-line tasks, and open a remote session only when you need the full macOS graphical interface.
SSH uses less bandwidth and is ideal for builds, logs, dependencies, and automation. Graphical remote access is for the Xcode interface, simulator monitoring, and settings that must be configured from the desktop.
Use it for Git operations, dependency installation, script execution, log review, test builds, and CI tasks. First use SSH to verify the node address, credentials, and host status before setting up other access methods.
Use it to operate the Xcode interface, inspect project settings, monitor the simulator, and work with desktop apps. If the network fluctuates, lower the resolution, frame rate, and color quality first instead of repeatedly creating new sessions.
Read connection information from the console’s instance details for the relevant order. Do not enter the node address or credentials from chat messages, old screenshots, or forwarded text. When a host fingerprint prompt appears on the first connection, compare it with the fingerprint in the instance details and accept it only when they match exactly.
Check the node region, address, SSH port, username, and key type, and confirm that all fields belong to the same order and physical node.
The private key should be readable only by the current local user. If the client reports permissions that are too broad, fix the file permissions before reconnecting.
Compare the algorithm type and fingerprint value character by character. If they differ, stop connecting; do not bypass the warning by deleting the old record.
After signing in, confirm the hostname, current user, system version, available disk space, and Xcode path before installing dependencies.
The addresses, usernames, paths, and project names below are non-executable placeholders. Replace them with the fields from the console’s instance details and your actual project.
$ ssh -i /path/to/private_key -p <port> <user>@<node-address>
The authenticity of host cannot be established.
ED25519 key fingerprint is <fingerprint-to-verify>.
Continue connecting only after verification: yes
<user>@<host> % hostname
<instance-hostname>
<user>@<host> % xcodebuild test \
-workspace <project-workspace> \
-scheme <test-scheme> \
-destination 'platform=macOS'
Test Suite '<test-suite>' passed
Executed <test-count> tests, with 0 failures
<user>@<host> % bundle exec fastlane <workflow-name>
[fastlane] Checking project configuration
[fastlane] Running tests
[fastlane] Exporting artifact
[fastlane] Finished without reported errorsField names vary by graphical client, but the connection logic is the same: take the address and port from the instance details, choose resolution and image quality based on the local network, and enable clipboard and file sharing only when necessary.
Check in the console that the target instance is running normally and that no abandoned graphical session is occupying it. If several team members share the workflow, agree on a session handoff process to avoid disconnecting one another.
Copy connection parameters from the instance details one by one. Do not store keys, passwords, or recovery information in shared notes, public repositories, ticket screenshots, or unencrypted sync folders.
For the first connection, use one display, 1920×1080 or lower resolution, and medium color quality. Increase settings gradually after input and video are stable; do not enable high resolution, frame rate, and color depth at the same time.
Enable text clipboard sharing only when necessary. Map directories to a dedicated exchange folder; never share the local user directory, key directory, or paths containing signing materials directly.
Confirm whether client disconnection keeps tasks running, locks the desktop, or ends the session. Use the explicit sign-out flow when finished; do not simply close the client window and assume the session has ended.
When choosing a transfer method, consider traceability, incremental updates, file permissions, and the exposure of sensitive information. Do not move private code or build materials through public download links.
Best for repository code, dependency lockfiles, and reviewable configuration. Confirm the remote URL and branch before pulling; configure private credentials through controlled methods and keep them out of the repository.
Best for incremental resource uploads, sanitized log downloads, and returning build artifacts. Restrict the remote destination directory, then check ownership, permissions, size, and modification time.
Best for one-time delivery of assets, caches, or archives. Generate a digest on the sending side, recalculate it on the node, and compare character by character; extract and process the archive only when the results match.
High resolution, frame rate, and color quality all increase transfer pressure. Change one parameter at a time, preserve before-and-after comparisons, and avoid masking the real cause with multiple simultaneous changes.
| Symptom | First step | Second step | How to verify |
|---|---|---|---|
| Mouse input latency | Lower the resolution | Lower the frame rate | Move a window and check whether input stays synchronized |
| Frequent screen redraws | Lower color quality | Disable dynamic desktop effects | Scroll through a code file and observe the redraw area |
| Intermittent session disconnects | Switch to wired or stable Wi-Fi | Pause other high-bandwidth tasks | Keep an SSH session open to monitor connection continuity |
| Input works but the screen is stuck | Wait for the current render to finish | Reconnect to the original session | Avoid creating multiple parallel graphical sessions |
Prefer a wired connection; on Wi-Fi, keep the signal stable and avoid sustained high-bandwidth transfers.
Adjust resolution, frame rate, and color quality in that order, changing and recording only one item at a time.
Keep builds, logs, and file operations in SSH; use the graphical session only for tasks that require a graphical interface.
Retest after every step and save the complete error text, time of occurrence, node region, and client version. Do not submit only “unable to connect” or a single cropped screenshot.
Confirm that the local network works, then verify that the node address and port come from the current instance details. Next check whether the local firewall, corporate network policy, or VPN is blocking the connection. If SSH and the graphical session time out together, prioritize the network path and node status instead of repeatedly reinstalling the graphical client.
A changed fingerprint may indicate an incorrect address, a connection to another node, or changed instance information. Stop connecting, recheck the current address and fingerprint in the console, and confirm the order ID and node region. Update the local record only after the new fingerprint’s source has been confirmed.
First confirm that the username’s capitalization matches the instance details, then verify that the client loaded the intended key rather than an old file with the same name. Check the key file’s permissions, format, and path. If an agent or key-management tool is enabled, verify that it has not replaced the expected authentication material. Do not repeatedly try credentials from unknown sources.
Keep the SSH connection open and confirm that the system still responds. Then check for an existing graphical session, overly high display settings, and client support for the current connection mode. Lower to one display and a lower resolution, then reconnect to the original session. If SSH works but the display remains unavailable, record the client version and session time before submitting a ticket.
The team should define the current session owner and handoff time. Check existing sessions before connecting, and use the client’s disconnect or sign-out action when leaving; do not resolve contention by forcibly creating a new session. If background builds must continue, run them in a persistent command-line workflow rather than relying on an open graphical window.
Include the order ID, node region, incident time, complete reproduction steps, and sanitized logs. For graphical sessions, also provide the client name, version, resolution, and network type.
After completing the task, sign out of the graphical session, stop listeners you no longer need, check for exposed credentials, and delete temporary exchange files locally and on the node.
If credentials entered a public repository, shared screenshot, public download directory, or uncontrolled log, stop using them immediately and rotate them. Deleting public copies does not replace rotation because the content may already be cached or copied.
Check SSH tunnels, port forwards, client background processes, and local proxies. Keep an access point only when it still has a clear purpose, and record its owner, purpose, and shutdown condition.
Retain the system version, Xcode path, dependency lockfiles, build commands, and error summaries; remove private keys, account passwords, recovery codes, temporary exchange archives, and unsanitized logs.
Choose a configuration and node to deploy first. If you are still preparing the toolchain, continue with the first-deployment guide or visit the Help Center for help with a specific issue.