An engineer-ready troubleshooting path

Locate the issue first, then restore your Cloud Mac in the fewest steps.

From first-time SSH connections and Xcode toolchains to CI/CD runners and node networking, this page provides the checks first and explains how to interpret them. If the issue persists, include your order number, node, timestamp, and redacted logs when submitting a support ticket.

Priority path
Complete your first connection in 4 steps
Coverage
6 common task types
Human support
Email and console tickets
ONCEMAC SUPPORT BOARD Node checklist
Ready to troubleshoot
A1
Verify connection details Host address, username, key file
Connection
B2
Verify the toolchain Xcode, CLT path, build logs
Build
C3
Verify execution boundaries Disk, network, processes, and reboot records
Node
Remove keys, access tokens, and full IP addresses before submitting
Quick navigation

Find the answer by task—no need to read from the beginning.

Choose connection, Xcode, CI/CD, storage, networking, or renewal to keep the relevant entry points. You can also search by command, symptom, or tool name.

Showing all 6 help categories.

Start here if this is your first time

Establish your first SSH connection in four steps.

Use the connection details shown on the instance details page in the console. Do not guess the host address from an old ticket or historical command; copy the current details again after a node is re-provisioned.

  1. 01

    Copy the current connection details

    Open the instance details in the console and copy the host address, SSH username, port, and key information. Confirm that the selected order and node match, then paste the command into your local terminal.

  2. 02

    Save the private key in a controlled directory

    Store the key file in a directory controlled by your local user. Do not commit it to a Git repository, build artifact, or team chat. The filename is up to you, but the path in subsequent commands must match.

  3. 03

    Tighten local file permissions

    Run this in a local macOS or Linux terminal: chmod 600 ~/.ssh/oncemac_key. If SSH reports that the private-key permissions are too open, fix the permissions first instead of bypassing the security check.

  4. 04

    Connect and verify the node identity

    Run the SSH command provided by the console. On the first connection, verify the source of the host fingerprint. After entering the node, run hostname, sw_vers and whoami to confirm the host, operating system, and current user.

Command execution order

Verify the connection and versions first, then start the full build.

Change only one variable per investigation. First confirm that the SSH session is stable, then check the Xcode version, and finally run the build command with a result bundle and logs. This separates connection, toolchain, and project issues.

  • Connection layerAfter SSH succeeds, record the node name and current user.
  • Toolchain layerConfirm the active Xcode version and developer directory.
  • Project layerKeep the scheme, destination, exit code, and logs.
  • Automation layerInclude only redacted fastlane output in a ticket.
once-node / build-diagnostics
SSH
$ ssh -i ~/.ssh/oncemac_key user@host
Last login: current session
connected: once-node

$ xcodebuild -version
Xcode 16.x
Build version 16x

$ xcode-select -p
/Applications/Xcode.app/Contents/Developer

$ set -o pipefail
$ xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'generic/platform=iOS' \
  -resultBundlePath ./BuildResults.xcresult \
  build | tee build.log

** BUILD SUCCEEDED **

$ bundle exec fastlane ios build
[fastlane] resolving dependencies
[fastlane] archive completed
[fastlane] lane finished successfully
Toolchain verification

Break Xcode issues down into version, path, signing, and logging.

“It builds locally but not on the node” is rarely enough to identify the cause. Compare both environments using the same commit, dependency lockfile, scheme, destination, and environment variables, then compare their outputs.

XC-01

Confirm the Xcode version

Run xcodebuild -version, and record the major version and Build version. If the pipeline requires a specific version, print it at the start of the job instead of checking only during initial setup.

xcodebuild -version
xcrun --find simctl
swift --version
XC-02

Confirm the developer directory

Run xcode-select -p to check the current Command Line Tools path. If multiple Xcode versions are installed, define DEVELOPER_DIR explicitly in the runner environment so interactive sessions and automated jobs do not read different paths.

xcode-select -p
echo "$DEVELOPER_DIR"
xcrun --sdk iphoneos --show-sdk-path
XC-03

Check the signing environment

First confirm that the keychain is accessible and that the certificate name matches the provisioning-profile requirements. Then check the project’s Team, Bundle Identifier, and signing method. For a ticket, provide only the redacted error section—never attach certificates, private keys, or passwords.

security list-keychains
security find-identity -v -p codesigning
xcodebuild -showBuildSettings
XC-04

Export reviewable logs

Use set -o pipefail to preserve the real exit status, while using tee to write the log. For complex failures, generate .xcresult and remove usernames, paths, tokens, and business data before sharing.

set -o pipefail
xcodebuild build | tee build.log
echo "${PIPESTATUS[0]}"
Automation runners

Before connecting CI/CD, pin the execution identity and working directory.

OnceMac provides dedicated physical nodes with a complete macOS command-line environment. Teams should validate platform features, plugin compatibility, and job definitions against their own repository and version requirements.

RUNNER / 01

GitHub Actions self-hosted runner

  • Confirm that the macOS user running the runner service matches the user used for manual SSH testing.
  • Check the repository, organization, or enterprise registration scope to prevent jobs from being assigned to the wrong labels.
  • Assign the node a recognizable label and explicitly use the corresponding runs-on condition in the workflow.
  • Verify that the non-interactive shell can read the required PATH, Ruby, Homebrew, and Xcode paths.
  • Before starting concurrent jobs, confirm DerivedData, package-manager caches, and available disk space.
RUNNER / 02

GitLab Runner

  • Verify the executor type, runner tags, protected-branch rules, and job-matching conditions.
  • Confirm the user, HOME, and keychain context of the LaunchAgent or service process.
  • Print whoami, pwd, the Xcode version, and available disk space at the start of the job.
  • Cache keys should include the dependency lockfile or toolchain version to prevent reuse of incompatible caches.
  • On failure, retain the job log, exit code, and runner service status.
RUNNER / 03

Jenkins node

  • Confirm that the agent startup method, working directory, and node labels meet the Pipeline conditions.
  • Check that the Jenkins execution user can read the repository, build directory, and required keychain.
  • Put Xcode selection, dependency installation, and build commands in a reviewable Pipeline.
  • Limit the number of concurrent executors on the same physical node to avoid disk and memory contention.
  • Before archiving, record the workspace size, build-result path, and cleanup policy.
Reproducible migration

Migrate files—not an unauditable legacy environment.

Rebuild the toolchain from Git, lockfiles, and Brewfile whenever possible, and migrate only the working directories and caches you actually need. Copying an entire legacy user environment also brings outdated settings, absolute paths, and sensitive credentials to the new node.

MIGRATION MANIFEST Environment migration checklist
Source code Clone from Git and verify the commit hash Do not copy an old working tree containing uncommitted secrets
System tools Declaratively restore with Brewfile Recheck versions and PATH after restoration
Project files Incremental transfer with rsync Explicitly exclude cache, log, and credential directories
Build cache Migrate selectively according to the toolchain version Prefer regeneration when versions change

Migrate the working directory with rsync

Use dry-run mode first to review what will be copied and deleted, then perform the actual sync. The operator must confirm any deletions at the destination.

rsync -avhn \
  --exclude '.git' \
  --exclude 'DerivedData' \
  ./Project/ user@host:~/Project/

Pin the code state with Git

Record the branch, commit hash, and uncommitted changes on the source node. After cloning on the new node, verify the hash before restoring dependencies; do not use an archive instead of version history.

git status --short
git rev-parse HEAD
git clone repository-url
git checkout commit-hash

Rebuild tools with Brewfile

Review the list before exporting and remove software you no longer need. After restoration, verify each command’s version; a successful install command alone does not prove that the environment works.

brew bundle dump --file Brewfile
brew bundle check --file Brewfile
brew bundle install --file Brewfile
Verify sensitive credentials separately before migration

SSH private keys, repository tokens, signing material, environment files, and service keys should not be copied in bulk with the project directory. After confirming least-privilege access on the new node, configure them again through your team’s approved secure process.

Shortest troubleshooting path

Rule out verifiable conditions first, then submit the full context.

Handle all five issue types in this order: confirm the symptom, run the minimum command, record the result, and stop ineffective changes. Expand an item to view its checklist.

Unable to connect SSH timeout, connection refused, or key authentication failure
  1. Copy the host address, port, and username again from the current instance details, and confirm that you are not using information from an old order.
  2. Run chmod 600 to check local private-key permissions and confirm that the key path in the command exists.
  3. Use ssh -vvv to inspect the connection phase, but remove personal information from the full address, username, and key path before submitting a ticket.
  4. Retest from another trusted network to distinguish local egress restrictions from node connectivity issues.
  5. Include the order number, node, timestamp, error type, and redacted tail of the debug output in the ticket.
Build failed xcodebuild, dependency-resolution, or signing-stage failure
  1. Record the commit hash, scheme, destination, Xcode version, and developer directory.
  2. Clearly distinguish dependency-resolution, compilation, test, signing, and archive failures.
  3. Use set -o pipefail to preserve the real exit code, and export .xcresult or the complete log.
  4. Do not upgrade dependencies, switch Xcode, and clear all caches at the same time; change one variable at a time.
  5. Attach the logs around the first key error, removing repository tokens, signing material, and business data.
Insufficient disk space Build interrupted, archive failed, or the working directory keeps growing
  1. Run df -h to view volume capacity, then use du -sh to locate the workspace, DerivedData, archives, and dependency caches.
  2. Confirm that logs, test results, and historical artifacts have defined retention periods instead of deleting the entire user directory.
  3. Before cleanup, save build artifacts that still need to be downloaded and confirm that no running job uses the directory.
  4. If long-term capacity needs exceed the base SSD, evaluate the +1TB SSD or +2TB SSD add-on options.
  5. Include a disk-usage summary, growing directories, and failed-job timestamp in the ticket; do not upload project source files.
Network instability SSH lag, failed dependency downloads, or unstable repository connections
  1. Record symptoms separately for the local-to-node and node-to-repository or dependency-source paths; do not combine them into one conclusion.
  2. For continuous sampling, record the test location, carrier, node, command, and sample count. A single ping does not represent sustained performance.
  3. Check DNS resolution, proxy environment variables, the Git remote, and package-manager sources against your team configuration.
  4. Compare from another trusted local network to avoid misidentifying local Wi-Fi or egress policy as a node issue.
  5. Include the time range, target type, failure rate, and redacted output in the ticket.
Node reboot Session interrupted, services not restored, or runner offline
  1. Check the current node status in the console first; do not repeatedly send power commands.
  2. After reconnecting, run uptime and compare the boot time with the time the issue occurred.
  3. Check the startup method and current service status of the self-hosted runner, GitLab Runner, or Jenkins agent.
  4. Confirm that the build workspace is intact and revalidate artifacts from incomplete jobs; do not reuse archives with an unknown state.
  5. Include the order number, node, timestamp, symptoms before and after the reboot, and the services that need to be restored.
Human support

Submit enough information once to reduce back-and-forth.

Submit questions about existing orders, node status, and renewals through a console ticket first. For configuration and scope questions before ordering, email us. The only public contact email is support@oncemac.com.

SUPPORT PACKET Ticket information pack
01

Order and node

Provide the order number, configuration name, and node region. Do not provide payment credentials or complete billing details.

02

Time of occurrence

Specify the time zone, first occurrence, most recent reproduction, and whether the issue is ongoing.

03

Reproduction steps

List the command, expected result, actual result, and exit code. Avoid writing only “it doesn’t work.”

04

Redacted logs

Keep the error context, but remove keys, tokens, passwords, full IP addresses, signing material, and business data.

05

Checks already performed

Describe the network, version, path, disk, and retry checks completed to avoid repeating ineffective steps.

Existing order

Submit a ticket through the console

For node connection, build, billing, renewal, and order-status issues. The ticket is linked to your signed-in account to preserve the instance context.

Open the console
Pre-sales and general questions

Send a structured email

Include your use case, target node, Xcode version, concurrent build count, storage requirements, and desired activation time.

support@oncemac.com
Dedicated physical Mac mini nodes

Need a new node? Choose your configuration and term.

OnceMac offers 3 available configurations across 6 nodes, operating normally 365 days a year. All orders are billed in USD, with orders, nodes, and tickets managed centrally in the console.