First verify the physical node, configuration, rental period, and credentials. Then check the network, development environment, and job logs. Every step includes inputs, validation points, and completion criteria for first-time setup, daily builds, and troubleshooting.
When you need connection instructions, start with theremote access workflow; for an existing order, include the order number and node code in your ticket.
Do not start by reinstalling the environment. First determine whether the issue is in delivery, connectivity, the toolchain, job execution, data I/O, or billing. This can significantly reduce unnecessary changes.
Verify the node, machine configuration, system account, access credentials, rental start and end times, and security settings.
Completion criteria: Order details match the machine 02Check address reachability, port policy, account status, network jitter, keyboard layout, and session recovery in order.
Completion criteria: Stable reconnection and input 03Record Xcode, command-line tools, certificates, provisioning profiles, dependency caches, and project-directory permissions.
Completion criteria: Local and remote baselines are comparable 04Check runner registration, label routing, concurrency limits, cache directories, secret injection, and post-job cleanup.
Completion criteria: Jobs are repeatable without environment crossover 05Separate the system disk, project directory, build cache, and team storage. Check capacity, permissions, and sync status first.
Completion criteria: Data paths and export responsibility are clear 06Check the model, rental period, node, SSD add-ons, and number of Thunderbolt 5 parallel connections, then compare each billed item.
Completion criteria: Every charge traces back to configurationUse the baseline to determine whether later changes come from the order, system settings, or the project toolchain. Record only what is necessary; never put passwords, private keys, or full tokens in team documents.
Check that the order node code is SG, JP, KR, or HK, and record the delivery address. The node affects the access path, but network issues should not be hidden by changing project dependencies.
In System Information, confirm the ordered M4 or M4 Pro, memory capacity, and system-disk capacity. Record externally attached or added storage separately, including its mount location.
Confirm that the initial system account can sign in, then create a least-privilege account for automated jobs. Do not let a daily runner use unnecessary elevated permissions.
Store the remote address, system username, and session credentials separately. After updating them, sign out and reconnect once to confirm that the new credentials work as expected.
Add the rental start and end times to the project calendar and note the time zone. For long-running jobs, reserve time before expiry to save checkpoints, sync artifacts, and clean up the environment.
Check shared accounts, remote-access scope, directory permissions, and key storage. Installation scripts should be reviewable, and sensitive variables should be injected only while a job runs.
These terms describe resource ownership, connection methods, and the build environment. Use the corresponding names when reporting an issue so support can identify the affected layer quickly.
Keep the integration order fixed: registration, routing, rate limiting, caching, secrets, and cleanup. Whenever Xcode, dependencies, or signing materials change, rerun the same minimal pipeline for verification.
Create the executor using the registration method required by the project or organization. Record the runner name, scope, and service-start method. Then run a diagnostic job without sensitive variables.
Labels should cover the system, chip family, Xcode baseline, and purpose, such as build, test, or media processing. Do not let a generic label route high-load jobs to a lightweight queue.
Start with one job to validate CPU, memory, disk writes, and the Derived Data directory, then increase concurrency gradually. When jitter appears, retain queue length and the job timeline rather than looking only at the final failure code.
Store dependency caches, build intermediates, and export files separately. Set capacity limits, key rules, and cleanup conditions to prevent artifacts from old architectures or toolchains being reused incorrectly.
Expose sensitive variables only while the job runs, disable command echoing in logs, and limit which jobs can read them. If validation fails, check that the variables exist without printing their values.
On exit, remove temporary files, unmount temporary volumes, stop leftover processes, and clear short-lived credentials. Cleanup should run even when earlier steps fail, with reviewable result codes retained.
A failed remote build does not necessarily mean the machine is faulty. Validate tool versions, dependency resolution, directory permissions, and signing materials separately to identify the layer that actually changed.
Record the full version, build number, and currently selected path. Select the version explicitly in the pipeline so the GUI and command line do not use different toolchains.
Check the actual paths of the compiler, package manager, and script interpreter. Do not rely only on the installation interface; job logs should output a non-sensitive version summary.
Verify scope, purpose, and read permissions. Logs should contain only identifiers and check results, never private certificate content. After rotation, run one minimal signing validation.
Cache keys should include the dependency lockfile, tool version, and architecture. When build differences cannot be explained, validate with an empty cache instead of deleting all project data.
Confirm that the runner has the required permissions for source, cache, and export directories separately. Do not solve a single-directory issue by globally weakening permissions; record owner changes.
Disk issues usually come from mixed paths, unlimited caches, permission drift, or incomplete synchronization. First identify the data layer, then decide whether to clean up, expand, or migrate it.
Monitor available space continuously so build intermediates do not consume capacity needed by the system. Do not use system directories as a shared team-artifact repository.
A designated job account should manage source and configuration. After moving a directory, recheck permissions, symlinks, and absolute paths in scripts.
Separate caches by project, architecture, and tool version. Set capacity and retention cleanup rules to prevent old artifacts from affecting new jobs.
Verify exported artifacts before syncing them to team storage. Complete the export before the rental period ends and retain a handoff record.
Confirm the local network and target address first, then move to authentication and session layers. Display, keyboard, and clipboard issues are session-experience problems and should not be mixed with address reachability.
| Symptom | First step | Second step | Retain if still unresolved |
|---|---|---|---|
| Unable to establish a session | Confirm the node, address, and local network are available; rule out corporate network-policy blocking. | Retest on a known-good network without changing account and connection parameters at the same time. | Node, time, source network, exact error text, and consecutive test results. |
| Display latency | Lower resolution and color quality, and pause high-volume local uploads. | Compare round-trip latency and jitter across networks to determine whether the issue persists. | Node, resolution, network type, latency samples, and affected period. |
| Incorrect keyboard layout | Check the local input method, session keyboard layout, and system region settings. | Use a plain-text editor to test modifier keys, symbol keys, and shortcuts. | Local system, keyboard layout, affected keys, and reproduction steps. |
| Clipboard not syncing | Confirm that the session tool allows clipboard transfer, then test with short plain text. | Reconnect the session and test again; do not start with large files or rich text. | Session tool, content type, direction, and the smallest reproducible text. |
| Reconnect fails | Fully exit the old session, wait for the connection to release, then retry with the original address. | Check that the system account is still valid and avoid rapid repeated connection attempts. | Disconnect reason, retry interval, exact error text, and most recent successful time. |
| Credentials no longer work | Confirm that you are using the latest system username and session credentials, not an old record. | Have an authorized owner verify the latest change and rotation time. | Order number, node, username, and time of failure; do not attach the password. |
| Large-file transfer interrupted | Use a verifiable, resumable file-sync workflow instead of relying on the clipboard. | Compare source and destination file sizes and checksum results. | File size, transfer direction, start time, failure stage, and checksum summary. |
All nodes operate normally 365 days a year. If an incident occurs, the console timeline records its start, impact scope, recovery process, and end time; compensation eligibility and calculation follow the service terms.
Daily status, incident start time, and impact scope
Recovery actions, progress updates, and node scope
End time, duration, and follow-up notes
Order charges consist of the machine tier, rental period, node, SSD add-ons, and number of Thunderbolt 5 parallel connections. Recheck the order summary after changing the period or any add-on.
First check SoarMac M4 Air, SoarMac M4 Plus, or SoarMac M4 Pro, then confirm the daily, weekly, monthly, or quarterly period.
Confirm the SG, JP, KR, or HK node, plus +1TB SSD, +2TB SSD, or the number of Thunderbolt 5 parallel connections.
All prices are charged in USD. Supported methods are USDT-TRC20 and Visa / Mastercard / Amex via Stripe; actual gateway availability is determined by the system.
Writing only “it doesn’t work” leaves troubleshooting stuck at information gathering. Provide the facts below in order, and remove passwords, private keys, full tokens, and signing materials from logs.
Used to match the model, rental period, and delivery record; do not include payment credentials.
Specify SG, JP, KR, or HK and the approximate network region where the connection was initiated.
Use a time zone-aware timestamp and note the first occurrence, latest reproduction, and last known-good run.
Describe the input, actions, expected result, and actual result step by step from the initial state.
Keep the exact error text, exit code, and surrounding context; remove passwords, private keys, full tokens, and personal data.
Existing orders, connection issues, configuration checks, and service incidents can be linked to order records, making the console suitable for maintaining the timeline.
For product selection, bulk deployment, workflow evaluation, or issues that cannot be linked to an order, email support@soarmac.com or prepare the requested information from the contact page.
All three Apple Silicon dedicated physical machines are non-virtualized and available in Singapore, Tokyo, Seoul, and Hong Kong nodes. Before ordering, confirm the workload, memory, storage, rental period, and connection path.