Task-focused support guide

Find your next step, from first connection to build troubleshooting

DebugMac provides dedicated Apple Silicon physical nodes, not virtual machines. Start by checking credentials, region, and toolchain, then use command output to locate connection, build, storage, or network-path issues.

Rent a Cloud Mac View the getting-started guide

What you receive: Dedicated Debug M4 physical node
Connection methods: SSH and macOS graphical interface
Support channels: Console tickets and support email

BREAKPOINT REVIEW DESK Diagnostic task sheet

Verify each item

CASE / BUILD-042 Awaiting reproduction

Lock inputs first, then check the execution environment

Node: JP · Debug M4
Task: Xcode Archive
Entry point: SSH public key
Evidence: Commands, timestamps, redacted logs

Troubleshooting path

01Check the host fingerprintConfirm the connection target is unchanged
02Record toolchain versionsPin Xcode and dependency inputs
03Narrow the scopeSeparate local, network-path, and node-session issues

InputOrder and region RunReproduce and sample OutputVerifiable support ticket

Support index

Six task categories are expanded at once—no key steps hidden behind filters

Selecting a category jumps to and highlights its section while keeping the other guides visible for checking upstream and downstream conditions.

First connection

Verify credentials and host fingerprint

Prepare the address, username, and SSH public key; verify the fingerprint before starting command-line and graphical sessions.

Daily builds

Pin Xcode and archive inputs

From repository state and toolchain checks to signing and archive export, retain version details that make results reproducible.

CI automation

Keep runners traceable and clean

Limit concurrency, manage caches and temporary directories explicitly, and return key build output to the pipeline.

Storage expansion

Verify capacity, mounts, and linked devices

Confirm add-ons before ordering; after delivery, check disk capacity, mount points, file systems, and read/write targets.

Network diagnostics

Separate local, path, and session checks

Narrow the scope layer by layer with latency, path, port, and transfer tests instead of relying on one ping.

Account management

Turn issues into actionable tickets

Include the order ID, region, timestamps, reproduction steps, and redacted logs to reduce repeated questions.

SSH and graphical sessions

Verify the target first, then save a trusted baseline

The address, username, host fingerprint, and access status in the delivery receipt should belong to the same order. If any field differs, stop connecting and verify it through a console ticket.

Before connecting

Prepare your local SSH private key, its public-key pairing, delivery receipt, and a stable network. Never paste private keys, complete credentials, or unredacted configuration into a ticket.

Check that the local private key is readable only by the current user.
Confirm the order region is Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or the US West.
Independently verify the host fingerprint in the receipt before the first connection.
Record the first successful connection time, system version, and default disk capacity.

View the full getting-started steps

01 Prepare credentials
Read the host address, username, and fingerprint from the delivery receipt; keep the private key in a controlled local path and never transmit it through chat or tickets.
02 Verify the fingerprint
The fingerprint shown on the first SSH connection must match the receipt. If it suddenly changes after prior connections, do not simply delete the local record and retry.
03 Test key-based login
Run read-only commands first to confirm identity, Apple Silicon architecture, system time, and available disk space before entering a repository or build directory.
04 Start the graphical session
Check graphical-session credentials, display resolution, and keyboard layout; after first access, test a secure disconnect and reconnection.
05 Handle disconnects
First distinguish a local network interruption, unreachable SSH port, and interrupted graphical session. If the command line remains available, save logs and task state first.

Preserve three pieces of evidence when connection fails

Record local time, the complete error text, and port-check results from the same network. Do not repeatedly reset credentials, as this can overwrite the state at failure.

Xcode workflow

Pin the repository, toolchain, and archive parameters together

The same commit can produce different results with different Xcode versions, dependency lockfiles, or signing inputs. Pin inputs during troubleshooting; do not upgrade several dependencies at once.

Pull the repository

Record the commit hash, branch, submodule state, and dependency lockfile. Confirm the working tree has no uncommitted changes before the baseline build.

Choose the toolchain

Use xcode-select -p and xcodebuild -version to record the current developer directory and Xcode version.

Check signing inputs

Verify the project team, bundle identifier, configuration name, and signing mode. Redact certificate details before including them in logs.

Run the archive

Explicitly specify the workspace or project, scheme, configuration, and archivePath, and save the complete exit code and log.

Download the artifact

After the archive completes, verify the file size, checksum, and export directory, then copy the artifact to the team’s agreed secure location.

Build baseline command Use example placeholders for sensitive values

git rev-parse HEAD
xcode-select -p
xcodebuild -version
xcodebuild -workspace "<WORKSPACE>" \
  -scheme "<SCHEME>" \
  -configuration Release \
  -archivePath "<OUTPUT>/App.xcarchive" \
  archive | tee "<LOG_DIR>/archive.log"

Successful acceptance

The exit code is 0, the archive directory exists, the artifact size is as expected, and the logs contain no overlooked signing or script errors.

Failure routing

Determine in order whether the failure occurred during dependency resolution, compilation, linking, signing, scripting, or export instead of labeling everything an “Xcode build failure.”

Submit evidence

Provide the commit hash, Xcode version, command, exit code, failed stage, and redacted log excerpt. Do not upload private keys or complete credentials.

CI/CD automation

Give every self-hosted runner execution clear boundaries

Pipelines such as GitHub and GitLab can route macOS jobs to dedicated nodes. Nodes are not shared with other tenants, but each team must still manage concurrency, caching, and cleanup.

Concurrency

Start with a single-task baseline

Verify one pipeline completes successfully before increasing concurrency. Simultaneous writes to the same DerivedData, keychain, or output directory can cause cross-contamination.

Use a separate working directory for every task.
Add a task ID to simulator and archive paths.
Record CPU, memory, disk peaks, and queue time.

Caching

Caches must have verifiable keys

Dependency cache keys should include at least the lockfile digest, toolchain version, and architecture. Verify dependency integrity after a cache hit; never treat an old cache as proof of correctness.

Manage dependency caches and build intermediates separately.
Generate a new cache key after switching toolchains.
Record hit, fallback, and rebuild durations.

Cleanup

Reclaim temporary state when tasks finish

Run cleanup whether the task succeeds or fails. Keep logs and artifacts that must be returned, and remove temporary keys, working directories, and unused simulator state.

Use finally or an equivalent mechanism for cleanup.
Archive failure logs before deleting the working directory.
Check disk usage and stale caches regularly.

01 Register the runner
Connect the runner using short-lived registration details controlled by the team. Labels should clearly identify Apple Silicon, region, and intended workflow.
02 Create a baseline task
Run only environment checks and a minimal build to confirm repository access, Xcode path, dependency downloads, and artifact return.
03 Add caching
Measure uncached time first, then create cache keys from the lockfile and toolchain so cache effectiveness can be verified.
04 Verify cleanup
Intentionally trigger one failure to confirm logs still return, temporary data is revoked, and later tasks do not inherit the previous state.

Storage and Thunderbolt 5

Confirm add-ons in the order, then verify capacity and the path after delivery

The base configuration is Debug M4: M4, 16GB RAM, 256GB SSD. +1TB SSD, +2TB SSD, and Thunderbolt 5 linking are separate add-ons; do not infer order contents from system displays.

Extra storage

+1TB SSD

Billed per order

Daily$2.3

Weekly$6.1

Monthly$11.3

Quarterly$30.7

Before enabling, confirm the target workflow, expected peak, and data migration method; after delivery, verify total capacity, volume name, file system, and mount path.

Extra storage

+2TB SSD

Billed per order

Daily$4.6

Weekly$12.2

Monthly$22.6

Quarterly$61.4

Suitable for tasks requiring more archives, media assets, or model files. Capacity acceptance must still be based on system disk information and the actual mount result.

Billed per machine

Thunderbolt 5 linking

Calculated separately per machine

Daily$1.7

Weekly$4.6

Monthly$8.5

Quarterly$23.1

Before ordering, specify the number of linked machines, task allocation, and artifact aggregation location. This option is billed per machine; one machine’s price cannot be used to estimate a group order.

01 Check the order
Confirm the add-on name, quantity, term, and USD amount. Actual availability and the billing gateway are determined by the console’s live response.
02 Check the system
Use diskutil list and df -h to record disks, volumes, and available space instead of relying only on desktop icons.
03 Verify read/write
Run a small read/write test in the target working directory to confirm permissions, paths, and actual artifact locations; do not use one extreme test to represent long-term performance.
04 Record the mapping
When working across multiple disks or machines, record the task–volume–artifact-directory mapping so cleanup does not delete data that must be retained.

Network diagnostics guide

Four test groups separate local networks, cross-region paths, and node sessions

One latency sample or disconnect cannot prove where the problem lies. Repeat samples on the same network at similar times, retaining commands, targets, timestamps, and raw output.

Network diagnostic commands, observations, and decision boundaries
Test	Example command	What to watch	What it helps distinguish
Baseline latency	`ping -c 20 <HOST>`	Packet loss, variation, and where consecutive timeouts occur	Local access faults versus persistent path faults
Route tracing	`traceroute <HOST>`	Path changes, abnormal hops, and whether timeouts persist	Local egress, cross-region routes, and links near the destination
Port check	`nc -vz <HOST> 22`	Connection success, refusal, or timeout	A reachable host with an unreachable SSH port
Transfer test	`scp <FILE> <USER>@<HOST>:<PATH>`	Sustained rate, retries, and file checksum	Interactive latency and large-file transfer issues
Session check	`ssh -vv <USER>@<HOST>`	Resolution, handshake, key selection, and authentication stages	Network, fingerprint, key, and user-configuration issues

Local network issue

Multiple targets fail from the same device, service resumes on a controlled network, or persistent packet loss appears within the first local egress hops. Include the network type and retest results when submitting.

Cross-region path issue

Local access is normal, but a specific route shows persistent variation. Provide multiple route traces; do not equate an unresponsive intermediate hop with actual packet loss.

Node session issue

The host and port are reachable, but authentication, the shell, or the graphical session fails. Preserve verbose SSH output, session errors, and recent actions.

How to interpret results

Network results are affected by the local carrier, access method, cross-region route, and sampling period. Use them only to scope the issue, not as a performance guarantee. All nodes run normally 365 days a year; verify availability against actual service records.

Ticket preparation checklist

Turn a support request into a reproducible handoff

For active-node issues, submit a ticket through the console first. Before purchase or when login is unavailable, email support@debugmac.com; both channels use the same information checklist.

01 Order ID
Provide the order ID and Debug M4 model shown in the console. Do not send payment credentials, private keys, or the complete access password.
02 Node region
State Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or the US West, and explain whether the issue occurs only in that region.
03 Time of occurrence
Provide the first occurrence time with time zone, the latest reproduction time, and the duration; avoid writing only “just now” or “occasionally.”
04 Reproduction steps
List the inputs, commands run, expected result, and actual result. If reproduction is unstable, describe the frequency and shared conditions observed.
05 Redacted logs
Keep timestamps, exit codes, and error context; remove keys, tokens, passwords, internal repository addresses, and other sensitive values.
06 Checks already performed
List commands run, retry counts, network switches, and results so support staff do not ask you to repeat the same basic checks.

Active nodes and accounts

Log in to the console to submit a ticket

Tickets can be linked to orders, nodes, and prior handling records, making them suitable for connection, build, storage, billing, and account-access issues.

Open console

Before purchase or when login is unavailable

Send a structured support email

Put the task type and node region in the subject, and organize the body according to this page’s checklist. The only external support address is support@debugmac.com.

Send support email

Ready to get started

Need a Cloud Mac with verifiable configuration?

Choose Debug M4, a rental term, and nodes in five locations. Recheck the base configuration, add-ons, region, and USD amount due before submitting. Actual availability is determined by the console’s live response.

Rent a Cloud Mac View configuration and pricing