From acceptance to stable operation

Connect your Cloud Mac to your build workflow

After receiving your device details, verify the order and physical node, then complete connectivity, toolchain reproduction, and CI runner registration. Every step includes verification commands, completion criteria, and the evidence to retain when something goes wrong.

Rent a Cloud Mac now View configurations & pricing

Available nodes: 5physical nodes
Available configurations: 2dedicated physical machines
Workflow: 9verification steps

First-connection handoff board Verify in order

Verify delivery records

The node, configuration, system version, rental term, and access credentials must match the order confirmation.

Acceptance

Establish your first session

Verify CLI access first, then establish a graphical session and test reconnection as needed.

Connection

Reproduce the development environment

Pin Xcode, dependency tools, and working directories instead of copying every file from the old machine.

Setup

Run a real build

Run an archive or test task from the actual repository and record duration, logs, and artifact verification results.

Verification

Prepare before you start

Confirm which device and node you have—and for how long

Do not start migrating the environment before verifying the details. Sign in to the console and compare each order field with the device details; if anything differs, retain the page information and submit a ticket.

Node and network path

Confirm that the node is in Singapore, Tokyo, Seoul, Hong Kong, or the Eastern United States. Record the node code and test the connection path from your primary office network.

Confirm the team's primary access location and the node's time zone
Test from both the office network and a backup network
Record latency, jitter, and packet loss—not just a single ping

Device configuration

The catalog includes two tiers. Verify the chip, memory, and storage field by field after receiving the details.

Base tier: M4, 16GB, 256GB
Higher tier: M4 Pro, 64GB, 2TB
Use the order confirmation for any additional storage

System and access details

Verify the system version, hostname, connection address, port, and temporary credentials. Rotate the credentials immediately after the first login according to your team policy.

Do not paste passwords or private keys into public logs
Store credentials in a controlled secrets-management tool
Confirm what information CLI and graphical access require separately

Rental term and exit time

Whether you rent by the day, week, month, or quarter, define the data-export time and task stop point before starting so cleanup is not left until the end.

Record the rental start and end details
Allow time for artifact export and cache cleanup
Confirm the internal owner for renewal or change requests

First-connection guide

Verify reachability with the CLI first, then establish a graphical session

The CLI is suited to basic acceptance checks and automation; graphical sessions are suited to Xcode, simulators, and tasks that require a visual interface. Verify both separately—success with one does not mean all connectivity is working.

CLI connection

Establish the smallest verifiable session

1
Check the target details
Copy the host address, port, and username from the console. Verify characters and capitalization, and do not reuse expired details from an old ticket.
2
Verify the host fingerprint
Compare it with the delivery information on the first connection. If the fingerprint changes, stop and confirm the reason instead of deleting the local record and retrying.
3
Run read-only checks
Confirm the current user, hostname, system version, disk, and Xcode path. Do not immediately install or remove software.
4
Verify reconnection
Disconnect deliberately and reconnect to confirm the session recovery method, long-running task strategy, and log directory.

Remote graphical access

Verify image quality and task stability separately

1
Start with conservative image settings
Begin with lower resolution and color quality to confirm session stability, then increase the settings gradually. Do not mistake visual lag for a device-performance issue.
2
Protect credentials and the clipboard
Never expose passwords, private keys, or certificate passphrases through screen sharing, recordings, or an uncontrolled clipboard.
3
Lock unattended sessions
Lock the graphical session before leaving the device. During collaboration, designate the person operating at each moment to avoid concurrent environment changes.
4
Verify the state after reconnecting
After reconnecting, check whether foreground apps, build processes, and disk writes are still running. Do not assume a task failed because the display paused.

Quick terminal checks

Establish a device baseline with read-only commands

The commands below cover the chip, memory, disk, system version, network, and development-tool paths. Save the output, but remove usernames, internal repository addresses, and other sensitive fields before submitting a ticket.

DPLYMAC / FIRST-RUN CHECK

printf '\n== CHIP ==\n'
system_profiler SPHardwareDataType | grep -E "Chip|Memory"

printf '\n== DISK ==\n'
diskutil info / | grep -E "Device Node|File System|Disk Size|Free Space"

printf '\n== SYSTEM ==\n'
sw_vers
uname -m

printf '\n== NETWORK ==\n'
route -n get default | grep interface
ping -c 5 1.1.1.1

printf '\n== XCODE ==\n'
xcodebuild -version
xcode-select -p
swift --version

printf '\n== TOOL PATHS ==\n'
command -v git
command -v ruby
command -v fastlane

How to determine whether it passes

The chip and memory match the ordered configuration
The root volume is readable and writable, with enough free space for the task
The system architecture output is arm64
A default network interface exists, with no significant packet loss in consecutive tests
Xcode and command-line tool paths point to the expected versions

What to retain

Command execution time and node
The complete command, not just the final line
The raw output and a redacted ticket version
Expected result, actual result, and reproduction count

Xcode and signing environment

Pin the toolchain before importing build materials

Environment consistency comes from explicit versions and repeatable steps—not from copying the old machine's entire user directory. Import only the signing materials required, and clean them up before the rental term ends.

Check Action Completion criteria

Xcode version

Run xcodebuild -version, record the major version and build number; if the project requires a fixed version, document it in the repository.

Matches the version required by the project

Command-line tools

Run xcode-select -p, switch to a team-approved path if necessary, and do not upgrade mid-task.

Path points to the target Xcode

Certificate import

Import only the certificates required by the current project, use controlled transfer, and restrict keychain access.

The target signing identity is identifiable

Provisioning profiles

Verify the app identifier, team details, capabilities, and validity. Do not mix in files left over from other projects.

The archive target matches the project configuration

Keychain unlock

Unlock it in the build script for the shortest necessary window, then lock it again when the task ends. Never write the passphrase to the repository or ordinary logs.

Required items are readable by non-interactive builds

Pre-build verification

Run dependency resolution, project-list, and signing-settings checks before starting a full archive.

Failures occur before the production build

Migration workflow

Split the migration into three handoffs: data, toolchain, and runner

Change only one variable at a time and keep a rollback point. If build results differ, you can identify whether the cause is data, dependencies, or CI registration.

Handoff 01

Data synchronization

Input: Source code, required assets, dependency lockfiles, and build scripts
Action: Pull from the repository first; verify large files separately, and do not copy unrelated caches or old artifacts
Verification: The commit, file count, and checksums match expectations, and no sensitive files entered the repository
Common failures: Files missed by ignore rules, case-sensitive path differences, changed line endings, or lost permission bits
Rollback point: Keep a clean working directory so the synchronized content can be removed and pulled again

Handoff 02

Toolchain reproduction

Input: Xcode requirements, dependency list, package-manager lockfiles, and script runtime versions
Action: Install the minimum toolset from the documentation, pin versions, and declare paths and environment variables in the task configuration
Verification: Dependencies resolve successfully, and the same commit produces consistent results from local commands and automation scripts
Common failures: Implicit global dependencies, a different default Ruby, an incorrect Xcode path, or cache contamination
Rollback point: Keep the version list and installation logs; clear tool caches and reproduce if needed

Handoff 03

CI integration

Input: Runner registration details, queue labels, working directory, cache rules, and concurrency limit
Action: Register one runner, run a read-only check first, then submit a complete pipeline for a real repository
Verification: The task is scheduled correctly, and its exit code, logs, test results, and artifacts are traceable
Common failures: Mismatched labels, reused working directories, overly broad cache keys, or multiple tasks competing for one resource
Rollback point: Deregister the runner and return to manual builds without affecting verified data or the toolchain

CI/CD integration

A registered runner does not mean the pipeline is reliable

After registration, validate at least one cold-cache task, one warm-cache task, and one failed retry. The pipeline must explicitly manage working directories, caches, and concurrency.

Common CI runner integration checks
Platform	Registration check	Working directory	Cache strategy	Concurrency guidance
GitHub Actions	Confirm the self-hosted Runner labels and target repository or organization scope	Use an isolated workspace for each task and clean temporary files afterward	Include lockfile summaries, Xcode, and architecture information in the cache key	Validate one task first, then increase concurrency based on memory and disk pressure
GitLab CI	Verify Runner labels, protected-branch permissions, and runner status	Do not let multiple projects share writable directories or artifact paths with the same name	Scope caches by project, branch, and dependency summary	Use separate queues for archives, tests, and lightweight checks
Jenkins	Confirm node labels, the remote root directory, and credential scope	Clean the workspace after the pipeline ends while retaining necessary logs	Manage dependency caches separately from build artifacts	Limit the number of heavy archive tasks using the same device
Self-hosted Runner	Record the service start method, runtime user, and task-claim conditions	Create a directory per task and perform deterministic cleanup on exit	Define cache ownership, capacity limits, and invalidation conditions	Use a queue to control resources instead of relying on scripts to win a lock race

Registration complete

The runner is online, labels match, the runtime user is correct, and it can read only authorized repositories and credentials.

Tasks are reproducible

The same commit produces consistent artifacts with both cold and warm caches, and failures retain a clear exit code.

Directories are reclaimable

Temporary signing files, derived data, and build intermediates have deterministic cleanup rules and do not depend on manual deletion.

Concurrency is capped

Set queue limits based on CPU, memory, and SSD pressure so archive tasks do not compete for resources.

Performance troubleshooting

Identify the bottleneck layer before adjusting parameters

Record the time, node, submitted task version, reproduction steps, and comparison result for every performance issue. Saying only “it is slow” does not distinguish resource pressure, network path, and graphical-session issues.

CPU

Determine whether the load is sustained computation or a short-lived spike

Record high-usage processes, thread counts, and task stages. Compare single-task and concurrent runs, checking for duplicate builds, runaway tests, or background indexing.

Process sampling

Memory

Check memory pressure and swap activity

Record peak memory, compressed memory, and swap changes. If a task fails only under concurrency, reduce concurrency first and compare again rather than immediately blaming the network.

Pressure comparison

SSD

Distinguish insufficient capacity from random I/O contention

Check free space, derived data, dependency caches, and historical artifacts. Record directory sizes before cleanup so evidence is not lost.

Capacity & I/O

Network

Compare latency, jitter, packet loss, and throughput

Run consecutive tests from a fixed local network and compare with a backup network. When repository pulls are slow, also distinguish the node path from dependency-service response time.

Continuous sampling

Graphical session

Display lag does not mean the build process is slow

Retest after lowering resolution and color quality, while using the CLI to observe whether the task continues. Record foreground and background states after reconnecting.

Session separation

Security and exit

Prepare the final handoff from the first login

Credentials, signing materials, build artifacts, and caches must each have a clear owner. Before the rental ends, export, verify, remove, and review them in order instead of relying on memory for cleanup.

Continuous execution

Credentials and permissions

Rotate temporary credentials after the first connection
Apply least privilege by repository and task
Regularly review runner and automation-key scopes
Never put passphrases in scripts, repositories, or ordinary logs

Before export

Artifacts and data

Export archives, test reports, and required logs
Verify file counts and checksums at the destination
Confirm repository commits and remote branches are synchronized
Record the build baselines that still need to be retained

Before the rental ends

Environment cleanup

Deregister the CI runner and revoke associated credentials
Remove certificates, provisioning profiles, private keys, and recovery codes
Delete working directories, temporary files, and sensitive caches
Check the Downloads folder, desktop, and shell history again

Support escalation

Make your ticket reproducible from the first reply

For issues with existing orders, sign in to the console and submit a ticket. If you cannot sign in, email support@deploymac.com. Remove passwords, private keys, certificate passphrases, and other sensitive credentials before submitting.

Incident report template Copy fields, not sensitive information

Order identifier

Enter the identifier from the console that can be used to locate the order

Node

Singapore, Tokyo, Seoul, Hong Kong, or the Eastern United States

Time of occurrence

Specify the time zone and provide the first occurrence and most recent reproduction times

Device configuration

Base or higher tier, including additional storage details

Reproduction steps

Start from a clean state and list each step in the order actually performed

Command output

Attach the complete command, exit code, and redacted output—not just a screenshot

Expected result

Describe the state, file, or return value expected under normal conditions

Actual result

Describe the deviation, reproduction count, and whether all tasks are affected

Actions attempted

List retries, reconnections, reduced concurrency, cache clears, and their results

Existing orders and connection issues

Console tickets can be linked to order, node, and device information, making them suitable for delivery verification, connection anomalies, and runtime issues.

Not yet ordered or unable to sign in

State the purpose, target node, expected rental term, and impact in the email. Do not send any passwords, private keys, or certificate passphrases.

Send a support email

Next step

Choose a configuration for your workload, then begin the first connection

The base tier suits lightweight builds and everyday development; the higher tier suits memory-intensive experiments, multi-project concurrency, and heavier builds. Both tiers are dedicated physical machines, not virtual machines.

Rent a Cloud Mac now Compare the two tiers