A troubleshooting guide for iOS, macOS, CI/CD, and Apple Silicon workloads. Confirm the node and network first, then check the toolchain and job logs without changing multiple variables at once.
The console shows the node details for your current order. Preserve the original format when copying fields; do not guess the address, username, or port.
Log in to the console and verify the order, region, host address, username, and permitted connection methods. The node is in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East, or the US West.
Confirm that your office network does not block the target port, disable temporary proxies that rewrite routes, and record connection results separately for wired, wireless, and other networks.
Use SSH first for command-line access, file synchronization, and automation; use VNC when you need the macOS graphical interface. Establish only one connection during the first test to avoid interference between results.
After logging in, record the system version, available disk space, Xcode path, and current network time. Run a minimal project first, then move the full project and build cache.
Do not upload projects in bulk, change system settings, or register a CI runner before confirming a stable connection. Preserve a reproducible baseline first.
When a connection fails, move outward from identity information to the network. Change only one condition at a time, and preserve command output or error messages.
Confirm that the username, key, or connection password comes from the current order; do not reuse connection details from a completed order. Check key-file permissions and make sure copying did not add spaces or line breaks.
Run a connectivity test using the port shown in the console. A timeout usually points to the network path; an immediate refusal usually means the target is reachable but the service or port does not match.
Check endpoint security software, corporate egress policies, and router rules. Retest on another known-working network to quickly distinguish local restrictions from node-side issues.
Record latency, jitter, and packet loss rather than relying on a single ping. VNC is more sensitive to sustained jitter, and SSH builds can also stop when download connections reset.
Return to the console and verify the instance and order status. If the node is unreachable from multiple networks and the credentials are correct, preserve the time and original error text, then submit a node issue ticket.
The same commit can produce different results with different toolchains. Validate the system environment and project dependencies separately to determine whether the issue is with the node, toolchain, or repository configuration.
xcodebuild -version, and record the Xcode and build versions.xcode-select -p, and confirm that Command Line Tools points to the expected directory.sw_vers
xcodebuild -version
xcode-select -p
df -h
A successful runner registration does not mean the workflow is secure and reproducible. Define the execution scope, working directory, credentials, and concurrency strategy together.
Use short-lived registration details provided by the project or organization, and set labels that describe the chip, region, and purpose. Delete local temporary command history after registration.
Deliverable: runner name and label listAllow nodes to be called only by trusted repositories, protected branches, and explicitly defined workflows. Review tasks triggered by external contributions; do not give unknown scripts direct node access.
Deliverable: repository and branch authorization rulesHandle temporary files, derived data, and invalid caches before and after each job. If caches are retained, record their keys, sources, and invalidation conditions to prevent stale artifacts from contaminating new builds.
Deliverable: cleanup script and cache policyPut tokens, SSH keys, and signing materials under a controlled secrets process. Revoke and reissue them immediately when a team member leaves, repository permissions change, or anomalous logs appear.
Deliverable: credential owner and rotation recordDo not capture only the generic exit code at the end of the log. Save the complete log and read upward from the first error to capture the target, command, and dependency context.
| Failure category | Common log signals | Check first | Include in the ticket |
|---|---|---|---|
| Dependency resolution | Package version conflicts, repository fetch failures, inconsistent lock files | Lock files, dependency sources, cache keys, and network download results | Dependency management method, failed package name, first error section |
| Signing configuration | Certificate mismatch, unavailable permissions, missing configuration variables | Scheme, build configuration, and secret injection process | Redacted original error and build target |
| Test failure | Assertion failure, simulator differences, test timeout | Failed test, destination, parallelization parameters, and retry results | Test name, exit code, reproducible command |
| Network download | Connection reset, resolution failure, download timeout | Repeated requests to the same address, DNS, proxy, and egress path | Time, target type, and network test results |
Preserve the complete original log
Locate the first meaningful error
Reproduce independently with a minimal command
Remove credentials before submitting excerpts
More capacity does not replace data classification and backups. Define what must be retained first, then choose how to synchronize, cache, and move it.
Prefer syncing source code through version control, and place large binaries and private dependencies in a controlled storage workflow. After the initial migration, compare the commit hash, submodules, and lock files.
DerivedData, package caches, and the runner working directory can all affect reproducibility. Before deletion, record directory sizes and cache keys; afterward, compare build times and error changes.
Use attached SSD storage for projects, caches, or datasets that need more workspace. Confirm the mount point, read/write paths, and job permissions before putting it into production use.
Back up project data, signing materials, credentials, and build artifacts according to your team policy. Move data out and verify that copies are readable before the rental period ends; do not treat a single copy on the node as a long-term archive.
The more specific your support request, the faster it can move into reproduction and diagnosis. State the impact first, then provide a timeline and minimal logs—never send secret values.
Passwords, private keys, recovery codes, complete tokens, signing materials, or complete payment credentials. If logs contain secret values, delete them or replace them with clear redaction markers first.
Log in to the console, create a ticket, and select the relevant order so support can verify the correct node and service records.
Log in to the console to create a ticketConnection interruptions, node issues, and billing questions require different evidence. Choose the correct category and add materials in the same conversation to keep the context together.
Include the local network type, target-port test, original error, and time of occurrence. If switching networks restored access, describe the difference between both tests.
Category: Connection & AccessState the impact, last known normal time, instance status, and minimal reproduction command. Do not overwrite the original state with repeated restarts or bulk configuration changes.
Category: Node OperationsProvide the order ID, billing period, relevant add-ons, and issue description. All orders are billed in US dollars (USD); do not send complete payment credentials in a ticket.
Category: Orders & BillingUpdate progress, follow-up questions, and the final resolution in the corresponding console ticket. When adding new logs, state the collection time and changes made so results can be compared.
New orders can choose from two configurations and six node locations; for existing-order issues, log in to the console and submit a linked ticket.