Engineering Support Handbook

Take your Cloud Mac from connected to production-ready

Follow the real operating sequence to verify credentials, connect through VNC remote desktop, migrate your environment, and diagnose build issues. Every step provides a result and a next action, so no issue is left vague.

Sign in to the console and submit a ticket Rent a Cloud Mac now
For
Dedicated physical Mac mini
Typical setup
About 4 minutes
Support options
Console ticket or email
RUN / CONNECT-01

First Connection Checklist

Actionable
Credentials retrieved Console instance details
01
Network reachable Target address and port are reachable
02
Desktop opened VNC session displays the macOS graphical interface
03
Acceptance result

After the model, memory, storage, and selected node match, sync your project and build cache.

Choose by issue

Six help topics to get straight to the right procedure

Choose the topic closest to your current stage. Start connection failures with credentials and network checks; start build failures with the environment and logs; verify orders and node status in the console for live results.

Remote connection

Open the macOS desktop for the first time

Verify the address, port, username, and temporary password to complete your VNC session and initial security setup.

View connection steps Account & orders

View order and node details

Verify the model, term, node, additional storage, billing, and service status in the console.

Open the console System initialization

Complete post-delivery acceptance

Change temporary credentials and check the system version, disk space, network time, and administrator permissions.

Run the acceptance checklist Development environment

Recreate your Xcode, CI, and MLX environment

Install the toolchain from the version checklist, isolate dependencies, and retain build and inference records.

View the environment guide Network & storage

Separate connectivity issues from capacity issues

Check your local egress, target port, free disk space, sync jobs, and large-file transfer strategy.

Open the diagnostic tree Service status

Verify node and instance results

Use the live console response as the source of truth, combining node status, system load, and service records to determine the scope of impact.

View status guidance
First Connection Guide

Verify the connection before migrating your project

Complete these four checks before syncing repositories, models, or media assets. This separates delivery, network, and project-environment issues.

  1. 01

    Get current credentials from the console

    Open the instance details and verify the node ID, model, VNC address, port, username, and temporary password. Do not use connection details from old tickets or historical screenshots, and never forward complete credentials to anyone else.

    Node ID matches the order Address and port belong to the current instance Credentials contain no extra spaces
  2. 02

    Establish a VNC remote desktop connection

    Open a compatible VNC client on a trusted network and connect using the address and port shown in the console. If the handshake fails, first check your local network, proxy, firewall, and target port. Do not repeatedly try an incorrect password.

    Local network can access external services Proxy has not rewritten the target port Client has saved the current address
  3. 03

    Update account security settings

    Immediately change the temporary login password after entering the graphical interface, and confirm that screen locking, automatic login, and remote access settings follow your team’s rules. For team use, create separate, traceable local accounts for authorized members.

    Temporary password replaced Screen-lock policy confirmed Authorized members documented
  4. 04

    Verify system and order configuration

    Check the macOS version, M4 chip, memory, storage capacity, available disk space, system time, and network egress. SureVM M4 Core should show M4, 16GB, and 256GB; SureVM M4 Plus should show M4, 24GB, and 512GB.

    Chip and memory match the selected plan Disk capacity matches the add-on Time and network status are normal
Migration path

Three steps to migrate from a local Mac to a Cloud Mac

The goal is not to duplicate an entire old machine, but to rebuild a verifiable, reusable working environment. Sync essential data first, recreate the toolchain next, then connect your automation.

01 Data synchronization

Migrate only what the project needs

Prioritize code repositories, configuration templates, essential assets, and confirmed reusable caches. Compress or transfer large files in batches to avoid filling the disk in one sync.

  • Pull code and submodules through version control
  • Inject sensitive variables separately; do not commit them to the repository
  • Record storage paths for assets, models, and build artifacts
  • Verify key file counts and checksums after syncing
Delivery result Project data is readable and directory boundaries are clear
02 Toolchain reproduction

Rebuild the development environment from a version checklist

First confirm the versions of Xcode, command-line tools, language runtimes, and package managers, then install project dependencies. Do not copy untraceable global directories from the old machine.

  • Pin Xcode and Command Line Tools versions
  • Record Ruby, Node.js, Python, and Java versions
  • Restore CocoaPods, SwiftPM, and npm dependencies from lockfiles
  • Run a clean build and save the complete log
Delivery result The same commit builds reliably on the new node
03 CI integration and validation

Add the node to a traceable queue

Give the Runner a separate working directory and least-privilege access, establish cache-cleanup policies, and use a test branch to verify checkout, build, archiving, and log delivery.

  • Limit the repositories and execution accounts accessible to the Runner
  • Separate cache and build-artifact directories
  • Verify failed jobs return an exit code and logs
  • Record the node ID, job ID, and commit hash
Delivery result Automation jobs are reproducible, diagnosable, and easy to hand over
Xcode & CI

Troubleshoot build failures through an evidence chain

Do not start by clearing every cache or reinstalling every tool. Keep the failure log first, then narrow the scope through certificates, signing, Keychain, Runner permissions, caches, and the specific error.

Signing chain

Certificates, provisioning profiles, and Keychain

  1. Confirm certificate purpose and validity

    Verify the certificate type, team configuration, and validity period used by the build target. Do not mix development and release environments.

  2. Verify the source of signing settings

    Check that project settings, build parameters, and CI environment variables point to the same signing strategy.

  3. Confirm that Keychain is accessible to the job

    Interactive login access does not guarantee Runner access. Verify unlock and read permissions under the Runner execution account.

Execution environment

Runner permissions, caches, and logs

  1. Confirm the Runner’s actual execution account

    Check the working directory, Shell, PATH, and read/write permissions. Do not verify only in the interactive terminal of the remote desktop.

  2. Isolate dependency caches and derived data

    Set clear directories for CocoaPods, SwiftPM, npm, and DerivedData, and start by selectively clearing problematic caches.

  3. Keep the first complete failure log

    Record the job ID, commit hash, Xcode version, exit code, and first error instead of submitting only the final lines.

Log investigation order

Find the first failure before tracing cascading errors

The end of a build log often contains many downstream failures. Start with the first nonzero exit code, first signing error, or first dependency-resolution error, and use the job start time to identify the root cause.

01 Job context

Node ID, job ID, commit hash, branch.

02 Environment context

macOS, Xcode, runtime, and dependency versions.

03 Failure context

First error, exit code, related command, and time.

MLX & development environment

Make your experiment environment reproducible, not limited to the current session

Manage the Python environment, model files, parameters, and output records separately. This controls disk usage and makes it easy to compare experiment differences after dependency upgrades.

Environment runbook

Recommended directory and record boundaries

ENV
Isolate Python environments

Use a separate virtual environment for each project, pin the Python version, and keep the dependency list under project version control.

DEP
Dependency installation

Install from lockfiles and record MLX and key library versions. Before upgrading, copy the environment manifest and benchmark results.

MODEL
Model file management

Store models, quantized versions, and temporary download directories separately. Record their sources, checksums, and disk usage to avoid duplicate copies.

RUN
Retain run records

For each experiment, save the commit hash, parameters, dependency versions, input summary, duration, and output path. Do not record sensitive raw data.

Before you start

Confirm your disk budget

Model files, virtual environments, caches, and outputs consume space at the same time. Check available capacity before downloading and reserve room for intermediate files.

  • Keep only required model versions in the model directory
  • Set a clear cache cleanup schedule
  • Archive results before deleting intermediate files
After a change

Validate with a minimal example

After changing dependencies or models, first run a small example with fixed inputs. Compare the exit code, output structure, and resource usage before resuming the full job.

  • Keep environment manifests from before and after the change
  • Record the failed command and first error
  • Confirm the output path is writable and has enough capacity
Connection diagnostic tree

Rule out issues layer by layer, from credentials to node status

Each layer should answer one question. If a layer fails, do not jump ahead to reinstalling software. This reduces unrelated changes and preserves clear evidence for a ticket.

01
Credentials

Are the address, port, username, and password from the current instance?

If it fails

Reopen the instance details in the console, manually copy the current connection information, and check leading and trailing spaces and old client records.

02
Network

Can the local network reach the target address and port?

If it fails

Temporarily disable any proxy that rewrites traffic, check your organization’s egress policy, and cross-check from another trusted network.

03
Remote desktop service

The network is reachable, but does the VNC session fail during the handshake?

If it fails

Record the client name, version, exact error text, and time. Avoid repeatedly submitting incorrect credentials and creating additional noise.

04
System load

The connection works but the display is slow. Is a high-load task consuming resources?

Check this

Review CPU, memory, free disk space, and active build or inference jobs. Pause nonessential queues before testing again.

05
Node status

Does the console report the current instance as running normally?

If status is abnormal

Do not repeatedly restart the job yourself. Record the node ID, console status, time, and preceding check results, then submit a ticket.

Service status guidance

Use the live console result as the source of truth

All nodes are designed to run normally 365 days a year. If the instance status, connection result, and local checks do not match, send the specific node and time range to the support team for verification.

Record first
Node ID and time of occurrence
Then compare
Console status and local symptoms
Submit last
Redacted logs and reproduction steps
Submit a support request

Give the support team enough detail to reproduce the issue directly

A complete ticket should explain the object, time, action, and result. First redact repository URLs, tokens, private keys, personal data, and business content from logs.

TICKET / REQUIRED

Five items every ticket needs

Submit after redaction
NODE
Node ID and region

Enter the node ID shown in the console and specify Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or the US West.

MODEL
Model and configuration

Specify SureVM M4 Core or SureVM M4 Plus, and whether additional storage or Thunderbolt 5 daisy chaining is used.

TIME
Time and time zone

Provide the first occurrence, most recent reproduction time, and your time zone. Avoid writing only “just now” or “about yesterday.”

STEPS
Shortest reproduction steps

Starting from a normal state, list the actions, input conditions, expected result, and actual result in order.

LOG
Redacted logs and exact error text

Keep the time, exit code, and error context. Remove passwords, access tokens, private keys, complete payment credentials, and sensitive business data.

Existing customers

Submit a node ticket through the console

Console tickets can be linked to the instance, order, and node status, making them suitable for connection, system, billing, and ongoing technical issues.

Sign in and submit a ticket
Unable to sign in or pre-sales questions

Email the support team

Send a problem summary from an email address that can receive replies. The only external support email is support@surevm.com. Do not send account passwords or private keys by email.

support@surevm.com
Next steps

Have an issue? Submit evidence. Need a node? Configure it directly.

Use the console for instance management and support tickets; use the ordering portal to choose between two M4 configurations, rental terms, and five available nodes.

Open the console Rent a Cloud Mac now