This guide covers connections, Xcode builds, CI/CD runners, storage, node networking, and billing for dedicated physical Mac nodes. Complete the basic checks in order, then submit the order, environment details, and redacted logs together to reduce back-and-forth.
Do not change the network, system version, and build configuration at the same time. Change one variable at a time, and keep the original error text and timestamp to determine whether the issue is in the connection, environment, or project layer.
First verify the node address, port, username, and credentials. Then check local network restrictions, client encryption settings, and session status. Do not repeatedly try old credentials.
Open connection checksRecord the failed stage, then check disk space, Xcode and SDK versions, dependency lockfiles, signing materials, and the complete build log. Preserve the first actual error.
View the build diagnostic sequenceCheck the runner service process, registration status, label matching, working-directory permissions, and concurrency limit. Showing as online does not guarantee that the current job labels will match.
Verify runner configurationSeparate usage from source code, dependency caches, DerivedData, archives, and delivery artifacts. Export required files first, then clean by directory; do not delete data whose purpose is uncertain.
Read storage FAQsRecord the current node, repository hosting region, main operator location, and large-file transfer direction before evaluating migration. Prepare an independent copy of code and build artifacts first.
Compare nodes and network pathsPrepare the order number, selected configuration, billing cycle, payment method, and console status. Submit only the transaction identifier; never send full card details or private keys.
Submit a billing ticket in the consoleWhen you first access a node, complete connection and security checks before configuring the development environment. This separates system issues from project dependency issues and makes later reproduction clearer.
Verify the node assigned to the order, server address, port, username, and temporary credentials. Use connection details only with currently authorized members; do not forward them through chat history or public documents.
Done when: You can establish a stable session and confirm that you entered the node assigned to the order.After first access, update the temporary credentials and create system accounts that follow your team’s permissions policy. Ensure administrator access is limited to members who need to install tools or adjust services.
Done when: Temporary credentials are no longer used, and everyday and administrative accounts have distinct purposes.Record the macOS version, chip, available disk space, Xcode version, command-line tools path, and target SDK. Add this information to your team’s build operations guide.
Done when: The same version set explains differences between local and cloud builds.Install dependencies from the project lockfile, set a dedicated cache directory, and then register the self-hosted runner. For the first job, use low concurrency to verify signing, archiving, and upload paths.
Done when: A minimal build job runs repeatedly and leaves a complete log.Start with a known-buildable commit and run only dependency installation, compilation, and archiving. After success, add parallel jobs, cache restoration, and delivery steps.
Prepare before checking the connectionBuild issues typically span six layers: space, signing, versions, dependencies, logs, and concurrency. After each layer, rerun the same commit and record whether the result changes.
Check available space on the system volume, DerivedData, dependency caches, archive directories, and exported artifacts separately. When space is low, save required artifacts first, then clean by directory.
Confirm that the selected team, certificate validity, provisioning profile target, and Bundle Identifier match. Do not attach signing private keys to logs or tickets.
Record the Xcode path actually used for the build. Confirm that the command-line tools do not point to another version, and verify that the project’s target SDK is installed.
Use the lockfile to determine whether the cache is stale. First try a clean build without restoring the cache; if it succeeds, restore dependency caches one at a time to locate the inconsistency.
Keep the command, exit code, and first actual error. The final screen often omits the initial failure, so include a redacted log from job start through exit.
Reduce concurrency to one job and observe memory, disk, and network usage. If one job succeeds but parallel jobs fail, increase concurrency gradually to find the stable limit.
If all six checks are complete and the cause remains unclear, submit the failed commit identifier, command, environment versions, exit code, and redacted log.
Submit a build issue ticketA dedicated physical node works well as a self-hosted runner, but reliable operation depends on a clear registration strategy, labels, service management, cache boundaries, and permission controls.
Use a unique runner name for each node. Record its repository or organization, registration scope, working directory, and service account. Revoke the old registration before migrating a node.
Labels should describe stable facts such as chip architecture, major Xcode version, node region, and purpose. Do not create hard-to-maintain combinations from temporary project names.
Run the runner as a managed service and record its startup method and log location. After a system restart, verify automatic recovery and test a minimal job.
Manage dependencies, DerivedData, and archives in separate directories with cleanup thresholds. Caches accelerate builds; they should not be the project’s only copy or a long-term delivery repository.
Give the everyday build account access only to the directories and commands required by its jobs. Use administrator privileges only when installing tools, changing system configuration, or managing services.
Service process → Registration validity → Label matching → Working-directory permissions → External connectivity → Platform job queue.
Consistent terminology in tickets prevents physical nodes, remote sessions, runners, and build caches from being treated as one type of failure.
VMArm offers five node regions: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US West. Compare remote operation, repository pulls, dependency downloads, and artifact uploads together.
Suitable for Southeast Asian teams and repositories or delivery workflows primarily serving Southeast Asia.
Suitable for teams in Japan and East Asia, balancing remote desktop operation with access to regional build resources.
Suitable for developers, dependency mirrors, and delivery workflows serving South Korea and Northeast Asia.
Suitable for teams collaborating across Southern China and Southeast Asia; test both repository and remote-session paths before choosing.
Suitable for teams on the North American West Coast and projects whose repositories, dependency sources, or delivery systems are in North America.
| What to check | How to test | What to record | What to determine |
|---|---|---|---|
| Remote session | Test connection and interaction during working hours and off-peak hours separately | Local network, node, client version, and time of occurrence | Persistent issue or time-specific fluctuation |
| Code repository | Use the same repository and commit to test cloning, pulling, and submodules | Repository region, duration, failed command, and exit code | Slow connection setup or slow large-file transfer |
| Dependency download | Run a complete dependency resolution once with caching disabled | Dependency source, package manager version, failed package, and retry count | Single dependency source or overall bandwidth issue |
| Artifact upload | Compare transfers using redacted test files of the same size | File size, target region, start time, and end time | Uplink, target service, or file-size impact |
A ticket should not merely prove that an issue exists. It should let support identify the same order, node, time, and failed step.
Used to verify the configuration, billing cycle, and delivery record.
Specify Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or US West.
Provide the time with its time zone and state whether the issue is reproducible.
Provide the full macOS version, not only the major version name.
Include the version and path targeted by the command-line tools actually used.
Start from the normal state and describe each click or command in the order it was performed.
Keep the error context and exit code, removing tokens, private keys, and other sensitive information.
Sign in, select the relevant order, and submit the issue. Complete order and node context is especially useful for connection, build, migration, and billing issues.
Go to the consoleBefore ordering, provide the use case, target configuration, number of concurrent builds, preferred region, and expected activation date.
View contact optionsRemove access tokens, signing private keys, complete payment details, and other sensitive content before submitting. To understand data handling, read thePrivacy Policy.
Response order depends on impact and reproducibility. Support handles node delivery, connection, environment, and order issues; project business logic must still be confirmed by the project maintainers.
Assess the impact based on whether connection is impossible, builds are fully blocked, some jobs fail, or the request is general, and confirm whether a viable workaround exists.
Confirm receipt of the order number, node, time, environment, and logs. If required information is missing, clearly list the fields to add.
Explain the current check layer, items ruled out, next validation action, and tests the user needs to run. Avoid repeating steps that add no new information.
The ticket enters the closure process once the issue is restored, the root cause and workaround are explained, or the issue is confirmed as project configuration with actionable checks provided.
Choose VMArm M4 Core or VMArm M4 Plus, then select a node in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or US West. Actual availability is returned in real time by the console.