From connection to artifact verification

Connect a Cloud Mac to your build workflow

This is not a conceptual overview but an actionable path you can follow step by step. First verify the identity and secure settings of your dedicated physical node, then prepare Xcode, signing materials, and automation tasks. When issues arise, collect network output and build logs consistently.

5 categories Support topics
6 steps Automated build pipeline
2 options Trackable support channels
Rent a Cloud Mac now View Runner M4 configuration
RUNNER SUPPORT ROUTE MAC-01
01
Claim and verify Connection parameters, host fingerprint, initial password
Prepare
02
Prepare the build environment Xcode, toolchain, signing materials, directories
Configure
03
Run automation tasks Checkout, cache, archive, export, verify
Execute
04
Collect diagnostic materials Node, order, time, commands, and complete output
Troubleshoot
Every diagnosis starts with reproducible inputs
First connection

Verify node identity and security in five steps

RunnerVM delivers a dedicated physical Mac mini, not a virtual machine. The priority on first access is not running commands quickly, but confirming that you are connected to the device assigned to your order and replacing the initial access method with your team’s secure settings.

  1. 01

    Claim delivery details in the console

    Verify the order ID, node region, connection address, SSH port, VNC parameters, and initial username. Do not forward complete credentials in chat; for team collaboration, share only the fields required by the actual operator.

  2. 02

    Record the host fingerprint first

    Compare the host fingerprint shown in the console character by character with the first SSH prompt. If the algorithm or digest differs, stop connecting and submit a ticket. Do not bypass the issue by deleting the local known_hosts entry.

  3. 03

    Establish an SSH command-line connection

    Connect using the host, port, and username provided with the order. After signing in, first run sw_vers,uname -m and hostname, then record the system version, Apple Silicon architecture, and device name in the delivery record.

  4. 04

    Set up a VNC remote desktop when needed

    Enter the address, port, and password shown in the console in your local VNC client. For the first connection, use the default resolution to verify the keyboard, pointer, and window scaling. Increase the display size only after confirming session stability.

  5. 05

    Update the password and restrict access

    Change the initial password immediately, check SSH keys and administrator privileges, and retain only the access required for the task. Then reconnect through SSH and VNC to confirm the new credentials before importing the project or signing materials.

Command execution examples

From connection verification to archive output

The sequence below shows typical SSH, xcodebuild, and fastlane output. Replace the host, workspace, Scheme, export configuration, and lane with your project’s actual values; do not copy these commands and assume they fit every repository.

  • Confirm the connection target, then switch to the project directory.
  • Use a task-specific archive path to prevent concurrent overwrites.
  • Save complete standard output and the exit code, not only the last line.
runner-build-session zsh
Connect to node SSH 
$ ssh -p 22 runner@10.0.0.12
Host key fingerprint: SHA256:…
$ sw_vers
ProductName: macOS
$ uname -m
arm64
Create archive XCODEBUILD 
$ xcodebuild archive \
-workspace RunnerApp.xcworkspace \
-scheme RunnerApp \
-archivePath build/RunnerApp.xcarchive
** ARCHIVE SUCCEEDED **
Run automation workflow FASTLANE 
$ bundle exec fastlane ios build
[08:42:16]: Resolving signing settings
[08:43:02]: Archive completed
[08:43:11]: Export verified
[08:43:11]: fastlane finished successfully
Adjust the example commands for the project workspace, Scheme, signing method, and directory structure.
Environment setup

Make Xcode, signing materials, and directories independently verifiable

Environment issues are usually not about whether Xcode opens, but whether the GUI selection, command-line path, project settings, and signing context are aligned. Check them in the order below to distinguish toolchain issues from project issues more quickly.

01

Confirm the Xcode version and path

Run xcodebuild -version and xcode-select -p. If multiple versions are installed on the node, identify the project requirement first, then switch the developer directory to prevent the GUI and automation tasks from using different versions.

02

Verify Command Line Tools

Run xcrun --find xcodebuild,xcrun simctl list and one unsigned project resolution. If a tool is missing or the SDK list is abnormal, repair the toolchain first rather than modifying project files.

03

Create a task-specific signing keychain

Place certificates used by automation in a separate keychain, with explicit unlock steps and minimal access. Never write passwords to the repository, script arguments, or build logs.

04

Import certificates and provisioning profiles

Record the certificate name, validity period, team identifier, and provisioning profile UUID, and confirm that the Bundle Identifier matches the target configuration. After importing, use security find-identity -v -p codesigning to verify available identities.

05

Plan the build directories

Separate source, dependency caches, DerivedData, Archive, Export, and logs. Use a unique archive path for every task; shared caches should contain only reproducible content, never signing materials.

Automated builds

Turn one successful build into six repeatable stages

The goal of automation is not to move a local script to a remote host, but to make inputs, environment, signing, and outputs reproducible. Each stage should produce a clear record so failures can be traced to a specific step.

  1. 01

    Check out a pinned code version

    Use a commit hash or protected tag rather than a branch head that may move. Record submodule versions, Git LFS status, and repository cleanliness.

    git checkout --detach <commit>
  2. 02

    Restore and verify dependency caches

    Cache keys should include at least the lockfile digest, tool versions, and architecture. On a cache miss, install normally; do not treat a required cache hit as a build-success condition.

    bundle check || bundle install
  3. 03

    Load signing configuration

    Unlock the task-specific keychain, import the matching provisioning profiles, and verify available signing identities. Never write keys or passwords to standard output.

    security find-identity -v -p codesigning
  4. 04

    Run Archive

    Explicitly specify the workspace, Scheme, Configuration, Destination, and archive path. Save the complete log and the xcodebuild exit code.

    xcodebuild archive …
  5. 05

    Export delivery artifacts

    Keep export configuration under version control, without secrets. Separate the export and archive directories to prevent reruns from overwriting the original xcarchive.

    xcodebuild -exportArchive …
  6. 06

    Verify and register the result

    Check file existence, size, digest, signing information, and task exit code. Associate the artifact ID with the commit, Xcode version, and log path.

    shasum -a 256 build-output
Remote desktop

Use VNC for graphical tasks; run long jobs in independent processes

A remote desktop is useful for initial graphical setup, checking Xcode UI state, and tasks requiring visual confirmation. Build continuity should not depend on whether the local VNC window stays connected.

Connection parameters

Use exactly the address, port, username, and password shown in the console. If the client supports connection profiles, do not write the password to a synchronized plaintext file.

Resolution

Use the default size for the first connection. After stable interaction is confirmed, increase the resolution gradually. If input lags, lower color depth and display size first, then check the network path.

Session locking

Lock the graphical session before leaving the device; closing the VNC client is not a substitute for locking the screen. When team shifts change, revoke access that is no longer needed.

Tasks after disconnecting

Persistent builds should run in a CI runner, launchd, tmux, or another recoverable session. Perform one deliberate disconnect test first to confirm that the task and logs continue writing.

Remote session handover checklist VNC / SSH
Before starting Verify node and session identity

Confirm the order region, device name, and currently logged-in user.

While running Write the task to a dedicated log

Do not rely only on screen output to determine whether the build is still running.

When leaving Lock the session and verify background tasks

After disconnecting, use SSH to check processes, log growth, and exit status.

After handover Revoke temporary access

Remove temporary public keys, one-time files, and credentials no longer needed.

Network and latency

Record connectivity, routing, resolution, and port access in one diagnostic run

Network issues require knowing where the request originated, when it occurred, which target was accessed, and the complete output received. A single screenshot or “the connection is slow” cannot distinguish local networking, cross-region routing, DNS, port policies, and target-service status.

PING

Check basic round-trip time and packet loss

Send a fixed number of packets and retain the minimum, average, and maximum latency plus packet-loss rate. Do not use one response to represent the quality of the entire connection.

ping -c 20 target-host
TRACEROUTE

Identify where the route changes

Run it from the source network where the issue occurs and retain every hop. A nonresponsive intermediate node does not necessarily mean the link is down; also check whether the final target is reachable.

traceroute target-host
DNS

Check resolution results and timing

Record the current DNS server, returned addresses, and query time. If results differ across networks, submit both outputs; do not rewrite them manually.

dig target-host
PORT

Check target-port reachability

Test the SSH port or the port actually used by the project separately. A successful connection proves only that TCP is reachable, not that authentication or the higher-level protocol has completed.

nc -vz target-host 22
Ticket diagnostic package

Five items required for submission

NET-CHECK
Time of issue
State the local date, time, time zone, and duration.
Source location
Specify the source node, office or home network, and provider.
Target details
Provide the order ID, node region, target host, and port.
Complete output
Attach the raw results of ping, traceroute, DNS, and port checks.
Comparison results
If possible, include the same tests from another network or at another time.

Remove passwords, private keys, tokens, and business data before submitting, but do not delete timestamps, error codes, route hops, or command parameters.

Support escalation

Narrow the scope first, then submit a trackable ticket

Pre-sales questions, general inquiries, and explanations unrelated to a specific order can be sent by email. For node, build, connection, or billing issues, sign in to the console and submit a ticket so it can be linked to the order and tracked continuously.

  1. 01

    Find and follow the relevant guide

    Choose a path for first connection, environment setup, automation, or network troubleshooting. Record the steps, commands, results, and point where the issue first appeared.

  2. 02

    Prepare the minimum reproducible materials

    Provide the order ID, node region, issue time, reproduction steps, expected result, actual result, and complete redacted logs. For build issues, also state the commit and Xcode version.

  3. 03

    Submit a ticket in the console

    Choose the closest issue category and submit logs as attachments or code blocks in the body. Keep one issue per ticket; do not combine network, build, and billing problems in one record.

  4. 04

    Add updates to the original ticket

    After retesting, reply to the original ticket with the new time, commands, and output. Check urgent-event status through the console as well; do not create multiple duplicate tickets.

Linked to a specific order

Console ticket

Best for connection failures, node issues, build environments, billing verification, and matters requiring continued follow-up. Tickets can be linked to an order and retain the complete handling timeline.

  • Order ID and node region
  • Issue time with time zone
  • Reproduction steps and complete error output
  • Diagnostic commands already run and their results
Sign in to the console to submit a ticket
General inquiries

Send a support email

Suitable for pre-sales selection, process confirmation, security reports, and explanations not tied to a node. State the issue category in the subject and avoid passwords or keys in the body.

support@runnervm.com
Need a template?

Start with a structured report

The contact page lists required information for pre-sales, technical, billing, and security matters, making it useful for checking that your materials are complete before emailing.

View contact instructions
Common checks

Confirm these boundaries before troubleshooting

The answers below help distinguish device delivery, connection methods, build tasks, and support materials, reducing repeated attempts in the wrong direction.

Does RunnerVM provide virtual instances?

No. Each order corresponds to a dedicated physical Mac mini node with the Runner M4 specification: Mac Mini M4, 16GB RAM, 256GB SSD. Remote access is only the access method; it does not turn the service into a shared virtual resource.

Will a build continue after disconnecting VNC?

It depends on how the task was started. CI runners, launchd, tmux, and independent background processes typically do not depend on the VNC window; interactive tasks bound to the graphical session may be affected by session state. Before production use, disconnect once deliberately and check the process, logs, and exit status.

What should I prepare before first connection?

Prepare working SSH and VNC clients, your team’s credential-storage method, the Xcode version required by the project, a signing-material checklist, and a secrets-management process that does not write secrets to the repository. After claiming delivery details, verify the host fingerprint and device identity first.

Will troubleshooting change my order billing cycle?

No, not automatically. Runner M4 orders are available by day, week, month, or quarter; the order cycle and processing status are determined by the console record. To verify a specific order, submit a ticket linked to it in the console.

What should be cleaned up after a task finishes?

First export the archives, artifacts, and redacted logs you need to retain. Then clean the source workspace, temporary signing keychain, provisioning profiles, temporary public keys, access tokens, and sensitive information in project caches. Do not leave plaintext credentials in shell history or script arguments.

How do I choose the right node?

First test latency and routing to the target region from your actual office network or CI source, then consider your team’s time zone and artifact-transfer direction. Runner M4 can be ordered in Singapore, Tokyo, Seoul, Hong Kong, and the US East Coast; actual availability is returned in real time by the console.

Next build

Start with a verifiable Cloud Mac

Choose Runner M4 and a target region. After placing your order, follow this page to verify the connection, prepare the toolchain, and run your first repeatable build task.

Rent a Cloud Mac now Contact RunnerVM support