Each rental includes one dedicated Apple Silicon physical node. When connectivity fails, check the console status first, then local networking, authentication, system services, and task processes—rather than repeatedly reinstalling the toolchain without enough information.
Do not copy addresses or credentials from chat history or old documents. Use the node status, connection address, account details, and access controls returned for the current order in the console.
First confirm that the physical node assigned to the order is ready for connection. If the status is still updating, keep the order ID and wait for the console to return the next step. Do not create duplicate orders repeatedly.
Check the host address and port character by character, ensuring you have not copied spaces, full-width symbols, or details from an old node. Users on corporate networks should also confirm that egress policy allows the target port.
Use the account details assigned within the order, and restrict the private key so only the current user can read it. Do not put passwords, private keys, or signing certificates in ordinary email messages or public repositories.
Use SSH for command-line work, code synchronization, and automated tasks. Use the remote connection method provided with the order when you need the macOS graphical interface.
SSH errors occur at different stages. A connection timeout usually points to the network path; a changed host fingerprint requires verifying the node identity first; authentication failures call for checking the username, key format, and file permissions.
Keep the private key in a controlled directory, outside the project repository. If permissions are too broad, the SSH client will refuse to use the file.
chmod 600 ~/.ssh/mangovm_node
ssh -i ~/.ssh/mangovm_node -p <PORT> <USER>@<HOST>Verify the fingerprint shown on the first connection against the information provided in the console. If you cannot confirm it, stop connecting and submit a ticket; do not simply ignore the warning.
Builds, archives, and dependency installations should run under a Runner, launchd, or a reliable session manager. Do not attach critical tasks only to a single SSH session on your laptop.
Check the username, private-key path, private-key permissions, and whether the key belongs to the current node, in that order. If the network connection is established but authentication fails, you do not need to restart the node first.
Submit a ticket with the authentication summaryRetest from another trusted network first, then record the target port, the client’s public egress address, and the start and end times. A timeout is unrelated to key contents; do not mask a network issue by repeatedly replacing keys.
Continue through the diagnostic treeA fixed physical node is well suited to preserving toolchains and project caches. Stability comes from explicit concurrency limits, isolated work directories, traceable logs, and cleanup after tasks—not from endlessly adding background processes.
Create a separate Runner for each project or organization, with labels that clearly state the chip, toolchain, and purpose. Use the registration token only in a controlled environment, then remove it from temporary commands and logs.
Large Xcode builds, simulator tests, and archives may compete for CPU, memory, and disk. Start with single-task concurrency, observe peak usage, then adjust gradually based on real logs.
Keep signing certificates, keys, and access tokens in controlled variables or isolated through local permissions. Do not write them to repositories, build artifacts, or downloadable logs. Clean up temporary files when the task ends.
Record the commit version, Xcode version, SDK, dependency lockfile, start time, exit code, and key errors. Attach only redacted excerpts and the relevant task ID to a ticket.
MangoVM nodes run normally 365 days a year. Schedule macOS and development-tool upgrades during a business low point of your choice; before making changes, complete data backups, compatibility checks, and rollback preparation.
Export the project, dependency lockfiles, build configuration, key logs, and local data to retain from the same point in time, and record the backup scope and verification results. Keep the backup separate from the node’s local disk.
Check the target macOS, Xcode, SDK, package manager, Runner, and project scripts item by item. First complete compilation, testing, archiving, and pre-upload validation on non-critical tasks.
Stop new builds from entering the queue and confirm that no archive, cache cleanup, or dependency update is writing to disk. Record the upgrade start time, operator, and pre-upgrade version.
If a critical project cannot compile, the Runner cannot register, or a core dependency is incompatible, stop making further changes, preserve the logs, and restore the data and toolchain using the recovery steps recorded in advance.
| Check item | Record before upgrade | Validate after upgrade | Retain if an issue occurs |
|---|---|---|---|
| Xcode and SDK | Current version, project target, command-line tools path | Build, unit tests, archive | Version output and first failure log |
| Dependency management | Lockfiles, mirror settings, cache scope | Restore dependencies in a clean directory | Lockfile and resolver error excerpts |
| Runner service | Labels, concurrency, working directory, startup method | Come online automatically after restart and accept tasks | Service status and task exit codes |
| Project data | Backup scope, export location, verification results | Sample reads and restore tests | Missing paths and most recent known-good version |
When an add-on storage device or Thunderbolt 5 pairing behaves unexpectedly, first confirm the add-on on the order, then verify system detection, the mount path, directory permissions, and task configuration. Prices and terms are those officially listed on the plan page.
Confirm that the order includes the target add-on, that the billing term matches, and that the console has returned the corresponding configuration. Do not rely only on an old path in the project script.
Confirm that the system detects the target volume and that the build user has the required read/write access to the working directory. Do not bypass a single-directory issue by granting overly broad access to the entire disk.
Verify the paired add-ons, cable connections, and task assignments one node at a time. First validate read/write access or coordination between nodes with one reproducible task, then resume the batch queue.
The plan page lists daily, weekly, monthly, and quarterly prices for +1TB SSD, +2TB SSD, and Thunderbolt 5 pairing. For billing issues, provide the order ID and selected term together.
Skipping earlier layers mixes symptoms together. Follow the sequence below, recording the time, result, and change at every step; enter the next layer only after confirming the previous one is working.
Check that the node status, order ID, region, and connection details are complete. If the details are still updating, stop local authentication attempts and record the current status.
Retest from another trusted network to rule out path differences caused by corporate egress, firewalls, proxies, or a local VPN. Record the test network and time.
Check the username, key path, file permissions, and host fingerprint. Do not carry known_hosts entries or automation variables from an old node directly into a new order.
Check SSH, Runner, build agents, and project dependency services. Record service status, the latest exit code, and the most recent configuration change; do not restart repeatedly without keeping records.
Check the concurrency queue, disk space, working-directory permissions, dependency locks, and task timeout. Record the first failed step separately from subsequent cascading errors.
The closer the information is to the failure layer, the easier it is for the support team to reproduce the issue. All channels accept only necessary information; have the support team confirm a secure submission method before sharing sensitive materials.
Describe the target workload, concurrency, preferred region, expected rental term, and storage needs. For an existing order, provide the order ID—never submit login credentials.
Provide the order ID, region, connection method, time, client network, error summary, and results from the first five diagnostic-tree layers. Do not write only “Unable to connect.”
Stop suspicious tasks, revoke potentially exposed temporary access, and preserve logs and the timeline. Submit the order ID, discovery method, impact scope, and actions taken. Do not send keys that remain usable.
If you need a new node, go straight to the ordering flow. If an existing order has an issue, submit a console ticket with reproduction steps and redacted logs.