Remote Access Guide

Connect securely to a Cloud Mac

First decide whether your task needs the command line, a graphical desktop, or unattended execution. Then verify credentials, the toolchain, and permissions for the relevant path. VMRunner provides a dedicated Apple Silicon physical node, not a virtual machine; use the connection details shown for your delivered order in the portal.

Rent a Cloud Mac Troubleshooting
Access paths
3 types
Delivery model
Dedicated physical node
Availability
365 days a year
CONNECTION RUN SHEET

Access checklist

After node delivery
01
SSH management Repositories, builds, logs
Preferred
02
Graphical desktop Xcode, assets, interactive debugging
On demand
03
CI Runner Testing, signing, artifact delivery
Continuous
Credential isolation Pass
Host fingerprint Verify locally
First build Start small

Never give the same credentials to both personal sessions and automated jobs. Create a dedicated, revocable account first, then connect the Runner.

Choose an access method

Route by operation type; do not open a graphical desktop by default

The command line is best for frequent, scriptable operations; use graphical sessions for tools that require interaction; assign continuous jobs to a dedicated Runner. Clearer boundaries make connection issues easier to isolate.

Command-line management

Ideal for Git operations, dependency installation, log inspection, scripts, and builds. It uses less bandwidth and is easier to recover after an interruption.

  • Typical entry point: SSH
  • Best for: builds and operations
  • Recommended permissions: key-based login

Graphical desktop operations

Use it for Xcode UI debugging, simulator checks, audio/video projects, and tasks that require observing window state. Higher resolutions require a stronger local network.

  • Typical entry point: remote desktop
  • Best for: interactive tools
  • Recommended permissions: dedicated session account

Automated CI execution

Use it for testing, archiving, signing, and artifact delivery. The Runner uses a dedicated account, with environment variables injected per job; do not share credentials with a personal desktop session.

  • Typical entry point: self-hosted Runner
  • Best for: continuous pipelines
  • Recommended permissions: least privilege
Before connecting

Record delivery details and your local baseline first

When troubleshooting remote access, the biggest time sink is usually not a complex failure but uncertainty about the node address, account purpose, or local network baseline. Record the items below before your first connection so you can identify which layer changed.

Delivery records to keep

Order ID, node city, node address, account purpose, host-fingerprint verification result, and the time of the first successful connection. Keep private keys only on controlled devices; never place them in tickets, chat logs, or code repositories.

  1. 01

    Confirm the order is delivered

    Check the order status and connection details in the portal. Before delivery is complete, do not try to connect using an old address or someone else’s records.

  2. 02

    Save the node address and separate credentials

    Use revocable accounts or keys for personal work, automated jobs, and temporary collaboration. Do not share one long-lived credential set.

  3. 03

    Measure your local network baseline

    Record latency, packet loss, and stability on wired and wireless networks. When a graphical session lags, compare it with this baseline first.

  4. 04

    Plan account permissions

    Give development accounts only the permissions required for the working directory. Runner accounts should access only build directories, caches, and required signing resources.

SSH path

Verify host identity first, then let keys handle daily connections

The goal of the first connection is not to dismiss warnings quickly, but to confirm that the current address matches the delivered node. After verifying the fingerprint, set up an alias, keepalive settings, and a least-privilege account.

STEP 01

Verify the host fingerprint

ssh-keyscan -t ed25519 NODE_ADDRESS
ssh USER@NODE_ADDRESS

Compare the first fingerprint you read with the delivery details in the portal. If the fingerprint changes after an address change or system reinstall, confirm the reason before continuing; do not simply clear local records.

STEP 02

Generate and deploy a dedicated key

ssh-keygen -t ed25519 -a 64
ssh-copy-id USER@NODE_ADDRESS

Generate a separate key for the VMRunner node. Protect the private key with a local passphrase, never commit it to a repository, and do not reuse the Runner deployment key.

STEP 03

Configure an alias and keepalive

Host vmrunner-build
  HostName NODE_ADDRESS
  User ACCOUNT_NAME
  IdentityFile ~/.ssh/vmrunner_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

An alias reduces address-copying errors. Keepalive settings only detect a lost connection; they do not resume an interrupted process. Hand long-running tasks to a task manager or CI Runner.

Least-privilege boundaries

Do not make administrator access the daily default. Separate dependency installation, system configuration, and pipeline execution by account. Return to regular privileges immediately after temporary elevation and record the changes.

Graphical sessions

Set image quality only as high as the task requires

Use a remote desktop for tasks that must display Xcode, a simulator, or a timeline interface; it should not replace every background job. Start with a lower resolution to establish a stable session, then increase quality gradually.

  • Confirm that the graphical remote service is enabled on the delivered node, and restrict which accounts may log in.
  • Test with one display and a lower resolution first; increase the settings only after input and video are stable.
  • Check Command, Option, Control, and the local keyboard layout to avoid triggering the wrong shortcuts.
  • Transfer only necessary text through the clipboard. Never copy private keys, complete tokens, or certificate passwords.
  • Lock the session when you leave. Disconnect actively when the task ends instead of leaving an unused desktop open.

Graphical-session tuning order

Start with stability
01 Resolution

Choose the lowest setting that fully displays the tool windows, then observe input latency and screen refresh.

02 Color and animation

When the network fluctuates, reduce visual effects and prioritize bandwidth for interaction feedback and file synchronization.

03 Keyboard mapping

Test common shortcuts in a low-risk text window before performing signing, deletion, or publishing operations.

04 Session locking

After an interruption, confirm the state of the old session first to avoid restarting tools or using the same working directory twice.

Migration path

From a local Mac to a Cloud Mac: validate in three stages

Do not move all code, certificates, caches, and pipelines at once. Keep verifiable output at every stage and proceed only after the previous stage passes.

01 · DATA

Data synchronization

Start by syncing repositories, lock files, required assets, and build scripts. Large caches and dependencies that can be downloaded again are not first-round migration targets.

  • Verify the default branch and commit hash
  • Record dependency lockfile versions
  • Compare checksums for key assets
Output: a reproducible code baseline in the cloud
02 · TOOLCHAIN

Toolchain installation

Verify Xcode, command-line tools, package managers, certificates, and provisioning profiles. Run a small test target first rather than the full release pipeline.

  • Pin Xcode and SDK versions
  • Confirm the selected command-line tools path
  • Separate dependency caches from build directories
Output: an environment inventory validated by a test build
03 · RUNNER

CI integration

Create a dedicated Runner account, limit the scope of environment-variable access, run one rollback-friendly test job, and return the artifact.

  • Create a separate working directory for the Runner
  • Inject only variables required by the current job
  • Verify logs, exit codes, and artifact hashes
Output: the first auditable Cloud pipeline
Environment verification

Document the development environment as a checklist, not from memory

The same code can behave differently on two Macs because of differences in tool versions, paths, caches, or permissions. Record each item below before the first production build.

Check Verification method Pass criteria
Xcode and SDK xcodebuild -version Versions match the project baseline
Command-line tools xcode-select -p Path points to the target Xcode
Certificates and provisioning profiles Run a redacted signing check Target name and valid scope match
Package manager Record the version and lockfile status Dependencies install reproducibly
Cache directories Check ownership, capacity, and cleanup rules Personal jobs and CI are isolated
Build directory Run a clean test build Artifact path and permissions are clear
CI integration

Give automated jobs their own identity and working directory

The Runner should not reuse a developer’s desktop account. A separate identity makes it easier to revoke access, clean caches, identify file-ownership issues, and reduce interference from personal sessions.

CI troubleshooting
  1. 01

    Create a dedicated account

    The account should access only the repository workspace, dependency cache, build directory, and required signing resources. Do not grant routine administrator access.

  2. 02

    Register the Runner

    Use the pipeline platform’s registration flow to bind the Runner to the current node. Add labels that identify the chip, system, and job type.

  3. 03

    Inject controlled variables

    Configure variables by repository, environment, and job scope. Hide sensitive values in logs and never print the complete configuration file in build records.

  4. 04

    Run a test build

    Start with a target that has few dependencies and a short runtime. Check the exit code, test results, cache hits, and working-directory cleanup.

  5. 05

    Return and verify artifacts

    Record the artifact name, source commit, checksum, and storage location. After confirming successful delivery, expand to the full pipeline.

Security wrap-up

A successful connection does not mean the migration is complete

Before production use, check credentials, sharing scope, backups, and recovery information once more. The goal is to ensure every account, session, and automated job can be revoked independently.

A

Rotate initial credentials

After the first verification, replace the initial password or key, remove temporary authorizations no longer needed, and record each credential’s purpose and owner.

B

Limit shared accounts

Every user and Runner should use a separate identity. When permissions change, revoke only the relevant account without affecting other workloads.

C

Back up important data

Keep code primarily in a remote repository. Back up signing materials, project assets, and important artifacts according to your team’s policy, and regularly verify recovery procedures.

D

Disconnect idle sessions

Lock and close graphical sessions that are no longer in use, stop temporary services, and check that background jobs still have a clear owner.

E

Save recovery information

Record the order ID, node city, account purpose, tool versions, and most recent successful build so support can locate issues quickly.

Prepare reproducible details when requesting support

Provide the order ID, node city, time of occurrence, reproduction steps, redacted logs, and expected result. Do not send private keys, complete access tokens, certificate passwords, or unredacted configuration files.

Contact options
Ready to start

After choosing a node, validate the entire connection chain with a small build

Complete credential verification, tool-version recording, and test-artifact delivery before moving the production project to a dedicated Apple Silicon physical node.

Rent a Cloud Mac View the three plans