Projects and configuration
Keep source files and automation configuration in your team’s own version-control and backup processes. The working copy on a Cloud Mac should not be the only version.
Engineering Troubleshooting Guide
Narrow down Cloud Mac issues in the right order
This guide covers first-time connections, macOS usage, Xcode builds, MLX inference, storage expansion, and order issues. Complete the relevant checks first, then submit the order ID, time of occurrence, and sanitized logs so the support team can avoid repeated questions.
- Support areas
- 6 issue types
- Available configurations
- 3 machine tiers
- Service nodes
- 4 nodes
Troubleshooting flow
Identify the layer, then collect evidence
Submit a ticket
A
Before connecting
Access layer
Check delivery status, node, connection details, and local network.
B
During the task
Runtime layer
Check the version, dependencies, disk, memory, and logs one by one.
C
Before submitting
Evidence layer
Keep the timeline and reproduction steps; remove passwords, private keys, and sensitive data.
Recommended details
Order ID + model + node + time + sanitized logs
Start with the part of the workflow where the issue occurs
All six entry points are shown here. Choose the one closest to what you are seeing, and keep connection failures, build errors, and order questions in separate descriptions.
Remote connection
Delivery status, connection details, local network, and account input.
Account & order
Rental term, renewal options, node details, and order status.
macOS usage
System version, account permissions, network, and available disk space.
Xcode builds
Version, signing files, dependency cache, disk space, and build logs.
MLX inference
Model format, unified memory, listen address, concurrency, and loading logs.
Storage expansion
Capacity planning, working directories, cache cleanup, and export before the rental ends.
Pre-order checklist
Clarify the use case, configuration, and connection requirements
If you have not created an order yet, complete these six checks first. The clearer your use case and resource requirements, the easier it is to choose among the three available configurations and avoid mistaking storage, network, or rental-term choices for machine faults.
Node directory
All three machine tiers are available in Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Final availability is based on the console’s real-time response.
Order preparation checklist
6 / 6 items
- Define the use caseBuilds, testing, CI, or MLX inference
- Choose a machineM4 16GB, M4 24GB, or M4 Pro 64GB
- Choose a nodeUse your team’s time zones and data-transfer paths as a guide
- Confirm the billing cycleCheck the order for a daily, weekly, monthly, or quarterly term
- Confirm storage needsSeparate system, project, dependency cache, and model files
- Prepare the remote environmentMake sure the local network allows the required connections and remains stable
When connection fails, start with delivery status—not repeated password changes
First-time access issues usually involve order status, connection details, the local network, or the input process. Follow the checks below in order and change only one variable at a time.
-
01
Order layer
Confirm the order is ready to connect
Sign in to the console and check the current order. If it is still being processed, wait for the status to update; do not try connection details from an old screenshot or another order.
-
02
Details layer
Read the connection details field by field
Confirm that the node, host address, connection method, and account belong to the same order. Check for leading or trailing spaces when copying, and never put real credentials in chat logs, screenshot filenames, or public repositories.
-
03
Network layer
Rule out local network restrictions
Confirm that the local network, firewall, or proxy is not blocking the connection. You can switch to another trusted network for a comparison test, but do not change the account, client, and network at the same time.
-
04
Input layer
Recheck the account input
Distinguish uppercase, lowercase, and easily confused characters, and confirm that the keyboard layout is correct. If the issue is reproducible, record only the error type and time; never record the password itself.
Xcode build errors: check from the toolchain through the logs
First confirm the environment actually running the build, then address dependencies and signing. Clearing every cache or repeatedly changing Xcode versions makes the original issue harder to reproduce.
-
1
Lock the Xcode version
Record the selected Xcode path, version, and project requirements. Confirm that command-line tasks and the graphical interface use the same toolchain.
-
2
Check signing files
Confirm that the required files are injected through your team’s own secrets-management process, with the correct paths and permissions. Do not copy signing-file contents into a support request.
-
3
Narrow the dependency cache
First determine whether the failure occurs during download, resolution, compilation, or linking. Clear only the relevant dependency cache and keep logs from before and after the cleanup for comparison.
-
4
Check disk space
Review usage for the project directory, build products, archives, and dependency cache separately. If space is low, export essential artifacts before cleaning up rebuildable content.
-
5
Capture the minimum useful logs
Keep the necessary lines around the first error, the command run, and the exit status. Remove tokens, usernames, internal repository addresses, and signing information.
MLX inference
Confirm the model loads before testing service concurrency
For MLX inference issues, distinguish model format, unified memory, service listening, and request load. Establish a reproducible baseline with one request, then increase concurrency gradually so loading failures are not confused with service congestion.
FORMAT
Model format
Check first
Confirm that the model files are complete and the conversion method is consistent, and record the framework and version used.
MEMORY
Unified memory usage
Measure next
Record readings before loading, after loading, and after the first request instead of looking only at the instantaneous peak.
LISTEN
Service listen address
Check the entry point
Confirm that the listen scope and port match the access design, and configure the necessary access controls.
LOAD
Request concurrency
Test gradually
Start with one request, keep the input fixed, then increase concurrency step by step while recording latency and failure types.
LOG
Model loading logs
Preserve evidence
Keep the version, startup arguments, and error context; remove business inputs and sensitive paths.
Plan capacity by data role; do not treat the node as your only backup
Systems, project source files, dependency caches, build products, and model weights have different lifecycles. Group them first, then decide whether to add storage.
Dependencies and build cache
Caches can speed up repeated tasks, but they need cleanup boundaries. When investigating disk issues, measure usage by directory first instead of deleting everything.
Models and data files
Record the model source, format, version, and disk usage. Before uploading large files, verify the node path and reserve time to export them before the rental ends.
Archives and artifacts
Name build archives, test reports, and inference outputs by task batch. After acceptance, export anything that must be retained to storage controlled by your team.
Orders & renewals
Use the current console page as the source of truth
After signing in, review the current rental term, available renewal options, selected machine, and node details. Nodes run continuously 365 days a year; the actual order status and available options are returned in real time by the console.
To create a new order, choose one of the three available configurations and select a target node in Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong. Every listed combination can be ordered; actual availability is returned by the console.
Order fields to verify
CURRENT
- Rental term
- Start time, end time, and current period
- Renewal
- Renewal periods available for the current order
- Configuration
- Chip, memory, storage, and add-ons
- Node
- Service region currently assigned to the order
Make the first request ready for troubleshooting
Your request should identify the order, machine, node, time, reproduction steps, and what the logs show. “Unable to connect” or “Build failed” alone is usually not enough to locate the issue.
Order ID
Enter the order ID shown in the console; do not substitute a custom machine nickname.
Machine and node
Specify VMCache M4 16, VMCache M4 24, or VMCache M4 Pro 64, along with the corresponding node.
Time of occurrence
Include the time zone and state whether the issue is continuous, intermittent, or happened only once.
Reproduction steps
Starting from a known-good state, list the actions, input type, expected result, and actual result step by step.
Scope of impact
Explain whether the issue affects one task, one project, or all tasks, and list anything that still works normally for comparison.
Sanitized logs
Keep the error context, version, and exit status; remove passwords, private keys, tokens, and business data.
Two ways to contact us
Submit a support ticket
For existing orders, sign in to the console and submit a ticket first. If you cannot access the console or have a pre-sales question, email support@vmcache.com.
Next steps
Complete the checks first, then share the evidence with support
For new resources, compare the three configurations. For an existing order issue, submit a ticket with the order ID, node, time, reproduction steps, and sanitized logs.