Engineering Support Desk

Diagnose in order, then reach the right team

This guide covers Cloud Mac delivery, remote access, SSH, Xcode, CI/CD, storage, and billing. Complete the five basic checks first to determine whether the issue is local networking, access details, a macOS session, or the build environment.

When engineering help is needed, include the order number, target node, time of occurrence, screenshots, and completed steps in a console ticket. Never submit passwords, private keys, or recovery credentials.

Rent a Cloud Mac now Log in to the console to submit a ticket

7 categories: Issue areas
5 checks: Basic diagnostics
2 options: Contact channels

OVPS / INCIDENT ROUTE Rapid Diagnostic Board

Recommended check order Node → Network → Credentials → Session → Client

01
Confirm node details Verify that the order number, node address, port, and account name all refer to the same host.
Basics
02
Verify the network path Retest after switching networks to distinguish local egress issues from target-node issues.
Network
03
Check access details Check credential update times, SSH keys, and the host fingerprint.
Identity
04
Check the macOS session Confirm whether the graphical session, lock screen, and background tasks are still running.
Session
05
Rule out client differences Record the client version, display settings, proxy, and exact error text.
Local

Runs reliably all year, 365 days Move to a console ticket if unresolved

Choose an issue type first

Seven entry points to start in the right place

Delivery

Order submitted, but access details are not confirmed

Check the order status, selected model, and target node first. Then confirm that the console has generated the node address, port, account name, and connection instructions.

Record the order number and submission time
Confirm the selected node matches the order
Do not create the same order repeatedly

Remote access

The graphical interface will not open, shows a blank screen, or disconnects repeatedly

Confirm the node address and port first, then retest from another network. Keep the client name, version, display settings, and a screenshot of the complete error.

Confirm the session is not stuck at the lock screen
Retest at a lower display resolution
Check local proxy and firewall rules

SSH

Key rejected, fingerprint changed, or connection timed out

Check the local private-key permissions, public-key content, target account, port, and host fingerprint separately. Never paste a private key into a ticket or email.

Keep the exact error text with its timestamp
Confirm the public key was not damaged by line breaks
Keep the old session open after replacing the key

Xcode

Version mismatch, build failure, or abnormal cache behavior

Record the macOS, Xcode, project commit, and dependency versions. First verify the environment without changing code, then decide whether to clear caches.

Save the first genuine failure log
Separate environment errors from code errors
Record cache-directory usage before clearing anything

CI/CD

Runner offline, job stuck, or working directory changed

Check the runner service process, registration scope, working directory, concurrent jobs, and network egress. Run a minimal test job before restoring the full pipeline.

Record the failed job ID
Check when the runner was last online
Confirm the disk is not full of cache data

Storage

Low disk space, oversized cache, or failed writes

Measure usage by directory and distinguish project files, dependency caches, build artifacts, logs, and temporary files. Do not delete system directories of unknown origin.

Record available space and unusual directories
Check log files that keep growing
Run a minimal build again after cleanup

Billing

Review billing periods, nodes, add-ons, or payment records

Review the USD invoice item by item, including the model, rental period, node, storage add-ons, and Thunderbolt 5 parallel connections, then check the payment record.

Confirm the daily, weekly, monthly, or quarterly period
Check add-on quantities and unit prices
Include the order number; never submit payment credentials

Preserve the current state before cleaning up or replacing anything.

Build logs, exact errors, client versions, disk usage, and timestamps greatly reduce back-and-forth. For credentials, describe only their status—never send passwords, private keys, or recovery credentials.

Five basic checks

Break “can’t connect” into five verifiable steps

CHECKLIST / 05

Rapid Diagnostic Panel

Run in order

01
Node information
Confirm the order number, node code, node address, port, and account name in the console. Check for leading or trailing spaces when copying; do not enter details from memory.

Output: node record
02
Network reachability
Record the current network, proxy, and egress environment. Retest on both the original network and another trusted network. If only one network fails, check local egress restrictions first.

Output: network comparison
03
Credential status
Confirm whether temporary credentials have been updated, the SSH public key is complete, and private-key permissions are appropriate. Verify that the host fingerprint matches the first record.

Output: status description
04
macOS session status
Determine whether the entire host is unreachable or only the graphical session is unresponsive. If SSH still connects, check the session, lock screen, and related processes first.

Output: session boundary
05
Local client settings
Record the client name, version, display resolution, color settings, proxy, and exact error text. When retesting with another compatible client, keep all other conditions unchanged.

Output: client comparison

You can continue on your own

A single component has been isolated

For example, only one local network fails, only an old key is rejected, or only one client displays incorrectly. Change one variable at a time and verify again.

View the connection guide

Engineering support needed

Reproducible across networks and clients

Put the five check results, time of occurrence, and error screenshots in one ticket. Engineering can continue checking the node and session directly from the evidence.

Open a console ticket

Terminology guide

Define each object clearly to avoid mixing protocols, sessions, and hosts

Cloud Mac: A macOS work environment accessed over a network for Xcode builds, automated tests, scripts, and local model inference. The term describes how it is used, not whether it is virtualized.
Physical node: The Apple Silicon host that fulfills the order and its network location. Node details usually include an address, port, and region code.
Dedicated: Each active rental corresponds to one dedicated physical host; its compute resources are not shared with other tenants on that host.
Non-virtual machine: The delivery is a dedicated physical machine, not a virtual instance carved from a shared host. Troubleshooting should distinguish host status from remote-session status.
VNC: A remote desktop protocol for accessing the macOS graphical interface. It is suitable for operating Xcode, viewing graphical tools, and verifying the desktop session.
SSH: A secure connection method for command-line login, script execution, file operations, and CI/CD management. Check the address, port, account, key, and host fingerprint when connecting.
self-hosted runner: A continuous-integration executor deployed on the rented host. The team configures its project scope, working directory, concurrency, and caching policy.
Session recovery: Re-entering the existing macOS session after a remote desktop disconnects. This restores the graphical session; it does not restart the host or recreate the build environment.

Connection troubleshooting guide

Handle first login, key replacement, and display issues separately

What should I check first when the first remote login fails?

Copy the node address, port, and account name from the console again, confirming they belong to the same order. Then check whether the local network uses a proxy, port restrictions, or additional firewall rules.

Record the client name, version, and complete error text.
Confirm there are no extra spaces in the fields and preserve the account name’s capitalization.
Retest on another trusted network, but do not change the credentials at the same time.
If SSH is reachable but the graphical interface is not, state that difference clearly in the ticket.

Why does the old connection still fail after updating temporary credentials?

Fully exit the client that stored the old credentials, then create a new connection. Some clients cache the account name or authentication data, so changing only the password field may not clear the old record.

After confirming the new credentials work, remove the old record. Do not show password contents in tickets, screenshots, or email; state only the update time, account name used, and error type.

How can I replace an SSH key safely without locking myself out?

Keep the current SSH session open, then add and verify the new public key. Use a second terminal to connect with the new key; remove the old public key only after the new connection succeeds.

Generate a dedicated key for this host; do not reuse key files from unknown sources.
Check that the public key is complete on one line and was not wrapped or truncated during copying.
Check the local private-key permissions and target account.
Save the host-fingerprint record. If the fingerprint changes unexpectedly, stop connecting and submit a ticket for verification.

How should I handle a black screen, visual corruption, or input lag in VNC?

First determine whether SSH still works. If command-line access is normal, the issue is more likely in the graphical session or client display settings than an offline physical node.

Lower the client resolution and color quality, disable the local proxy, and retest. Record whether the issue occurs only in full-screen, scaled, or multi-display mode. Do not force-terminate multiple system processes in succession.

How can I produce reproducible results when latency seems high?

Record the local network type, target node, test period, protocol, and client version. Run the same steps on the original and another trusted network, keeping the resolution, proxy, and workload consistent.

Do not report only that it is “slow.” Specify whether input response, screen refresh, file transfer, or command echo is slow, and whether the issue is continuous.

Build troubleshooting

Stabilize the environment before analyzing Xcode, the runner, and storage

Step 01

Confirm the Xcode and macOS versions

Record the full Xcode version, command-line-tools path, macOS version, and project commit. If the team has a fixed baseline, compare these with the last successful build.

xcodebuild -version
xcode-select -p
sw_vers

Step 02

Check the signing-environment boundary

Confirm the relationships among project settings, certificate files, provisioning profiles, and build-script references. You may submit screenshots with sensitive fields masked, but never upload signing private keys or passwords.

Keep the first exact signing error
Record the failed target and build configuration
Separate local script errors from project-configuration errors

Step 03

Clear caches based on evidence

Record usage for DerivedData, dependency caches, and the working directory first, then clear only directories related to the failed project. Run one minimal build afterward to avoid concurrent jobs overwriting the result.

du -sh ~/Library/Developer/Xcode/DerivedData
df -h

Step 04

Reconnect the CI runner

Check the runner service process, registration scope, working directory, and last-online time. Use a minimal test job without publishing actions to verify the network, permissions, and execution environment.

Record the failed job ID and time
Confirm the same executor is not registered more than once
Check working-directory ownership and remaining space

Step 05

Find the source of disk growth

Measure project files, dependencies, build artifacts, logs, and temporary files separately. If space keeps declining, record the growing directory and observation interval before submitting a ticket.

df -h
du -sh ~/Library/Developer/*
du -sh ~/Library/Caches/*

Do not make an environment reset your first step.

Preserve logs, versions, disk usage, and the failed job ID first. Clearing every cache or overwriting configuration may make the issue disappear temporarily while removing the evidence needed to diagnose it.

Billing help

Review each line by period, configuration, node, and add-on

USD pricing

Confirm the rental period first

Billing may be daily, weekly, monthly, or quarterly. Do not derive one period from the daily price; use the catalog price for the selected model.

Payment records

Only two payment methods are supported

USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) are supported. A ticket only needs the order number and a non-sensitive identifier from the transaction record.

Node and add-ons

Review the invoice components line by line

Confirm the model, rental period, target node, additional storage type, and number of Thunderbolt 5 parallel connections. Availability is determined by the console in real time.

Prices for four rental periods of add-ons
Add-on	Daily	Weekly	Monthly	Quarterly
+1TB SSD	$2.6	$7.1	$13.2	$35.9
+2TB SSD	$5.2	$14.2	$26.4	$71.8
Thunderbolt 5 parallel connection (each)	$2	$5.3	$9.9	$26.9

What should I include in a billing ticket?

Provide the order number, model, rental period, target node, add-on names and quantities, and a non-sensitive transaction identifier from the payment record. Never send a full card number, verification code, wallet private key, or password.

Submit a ticket

Give engineering support information they can act on immediately

SUPPORT PACKET

A complete ticket should contain six items

No sensitive credentials

Order number

Copy the complete number from the console; do not provide only the model name or node city.

Target node

Specify the actual ordered node: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, US East, or US West.

Time of occurrence

State the local time and time zone, and say whether the issue is continuous or intermittent.

Error screenshot or log

Preserve the exact error and context while masking account credentials, private keys, signing materials, and other sensitive content.

Steps already taken

List the test networks, clients, commands, and result of each step in order. Avoid writing only “tried everything.”

Expected outcome

State whether you want to restore connectivity, confirm billing, reconnect the runner, or identify a specific build failure.

Active issue

Console ticket

Best for node, connectivity, build, storage, and billing issues. Order context remains associated with the ticket under the same account.

Cannot log in

Support email

When emailing, include the account email, order number, and issue summary. Do not attach passwords, private keys, or recovery credentials.

Contact support@officevps.com

Escalation path

If the knowledge articles do not resolve the issue, continue by status

Ticket status identifies the current owner and next action. Reply in the original ticket with additional material; do not create multiple tickets for the same issue.

Submitted

Materials are in the queue

Check that the order number, node, time of occurrence, error records, and completed steps are all included. Add missing information to the original ticket.

In progress

Engineering is reviewing the issue

The team may check node connectivity, session status, delivery records, or billing details. Avoid further environment changes so new variables do not overwrite the evidence.

More information needed

More reproducible details are required

Add logs, screenshots, network comparisons, or client versions requested in the ticket. Submit only relevant excerpts and continue masking sensitive fields.

Resolved

Verify recovery and record the result

Run the original workflow once to verify, then record the actual cause, effective steps, and environment versions as a baseline for the team.

Open a console ticket View first-use steps

Prepare to deploy

Choose a dedicated physical machine and deliver your build environment to the right node

Three Apple Silicon configurations cover light builds, everyday development, parallel CI, and local model inference. Only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) are supported; all orders are settled in USD.

Rent a Cloud Mac now View the three plans