A console account that can receive notifications
Confirm that your email works and that you can access the console to view orders, host details, and support tickets. Store post-delivery connection details only in controlled environments.
This step-by-step path follows the order of execution. Prepare your account, SSH public key, and tool versions first, then choose a dedicated physical machine, node, and rental term. Once the device is delivered, verify, connect, and build.
Every workflow runs on a Cloud Mac physical node. Each order is assigned a dedicated physical machine, not a virtual machine. It is suitable for iOS/macOS development, CI/CD queues, and experiments that require a macOS environment.
These details affect your configuration, node, and rental-term decisions. Confirming them in advance reduces environment changes after delivery.
Confirm that your email works and that you can access the console to view orders, host details, and support tickets. Store post-delivery connection details only in controlled environments.
Create a dedicated key pair for your Cloud Mac. Submit only the public key, keep the private key on a locally protected device, and never send it by email or ticket.
Consider the developer locations, code repository, signing workflow, and artifact storage together. Do not choose a node based only on the lowest result from a single ping.
Decide whether you need an emergency fix, short-term validation, continuous iteration, or a quarterly pipeline, then choose the matching daily, weekly, monthly, or quarterly term.
Record the Xcode major version, target SDK, minimum deployment version, Ruby and fastlane dependencies, and the execution method required by your CI runner.
Both tiers are dedicated physical Mac mini M4 machines. Start with the workload, then check memory and the local working set; there is no need to reserve capacity a short task cannot use.
Suitable for single-project archives, emergency fixes, certificate checks, lightweight automated testing, and tasks that do not need multiple large simulators or build processes kept open at once.
Suitable for daily development, parallel builds, larger dependency caches, continuous CI runners, and model-inference validation within available memory.
If your project consistently completes a single build with 16GB of memory, choose DeployMini M4 16. If builds, tests, simulators, or inference workloads run concurrently, choose DeployMini M4 24 and assess additional storage based on your project data volume.
You can currently choose Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or the US West. Both configurations are available to order on all five nodes; actual availability is returned live in the console.
Suitable for workflows where teams, code repositories, or artifact services are primarily located in Southeast Asia.
Both configurations availableSuitable for development and build workloads that need coverage across Japan and surrounding East Asian routes.
Both configurations availableSuitable for teams whose developers, repositories, or delivery targets are concentrated in South Korea and Northeast Asia.
Both configurations availableSuitable for project workflows that need to balance network paths to South China and Southeast Asia.
Both configurations availableSuitable for projects whose code, artifacts, and final service paths are primarily located on the North American West Coast.
Both configurations availableDaily rentals suit emergency fixes and short-term validation; weekly rentals suit focused development and testing; monthly rentals suit ongoing iteration; quarterly rentals suit stable CI/CD or team workflows. Before submitting, recheck the model, node, storage expansion, and rental term.
Only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) are supported. All charges are billed in US dollars (USD); the payment gateway available to you is determined by the console.
Open the relevant order in the console and confirm each delivery detail. If anything is inconsistent, keep the order number and a redacted screenshot, then submit a support ticket through the console.
Confirm that the selected device is DeployMini M4 16 or DeployMini M4 24, and verify the M4 chip details.
Verify 16GB / 256GB SSD or 24GB / 512GB SSD, along with any additional storage listed in the order.
Confirm that Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or US West matches the order.
Save the host address, username, and fingerprint verification details. Never place connection credentials in a public repository.
Confirm the start time, rental term, and next steps, allowing time to export and clean up your data.
Test SSH, DNS, and basic tools before pulling the code. This makes it easier to distinguish connection issues from environment or project issues.
Include the order number, node, time of occurrence, expected result, and redacted details. Do not submit passwords, private keys, or complete payment credentials.
The example below uses the documentation address to demonstrate the connection sequence. Use the actual address, username, and host fingerprint supplied in the console; do not connect by copying the example values.
$ chmod 600 ~/.ssh/deploymini_ed25519
$ ssh -i ~/.ssh/deploymini_ed25519 deploy@203.0.113.24
The authenticity of host '203.0.113.24' can't be established.
ED25519 key fingerprint is SHA256:EXAMPLE-FINGERPRINT.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '203.0.113.24' to known hosts.
Last login: current session
deploymini-m4:~ deploy$ connection ready
Run read-only checks first, then install project dependencies and build. Keep a version record and output summary for every step so you can reuse the process when integrating CI.
Run xcodebuild -version and xcode-select -p, then verify the Xcode major version required by the project and the current developer directory.
xcodebuild -version
xcode-select -p
After entering the project directory, list the workspace, project, and scheme to avoid carrying local defaults into the remote build script.
xcodebuild -list \
-workspace Example.xcworkspace
Set the workspace, scheme, and configuration explicitly. Save the log and exit status in the task directory to help pinpoint dependency or signing-stage issues.
xcodebuild \
-workspace Example.xcworkspace \
-scheme Example \
-configuration Release build
Pin Ruby and dependency versions, run the target lane manually first, then organize non-sensitive parameters as reusable variables. Store secret values in a controlled secrets-management location.
bundle install
bundle exec fastlane build
A dedicated physical machine should not be the only place your project data exists. Put migration and credential revocation in the task plan instead of waiting until your final login.
Copy archives, logs, test results, and any caches that need to be retained. After transfer, verify file sizes or checksums and confirm that the local copy is readable.
Move the project working directory, configuration templates, and essential records to a team-managed location. Encrypt sensitive materials before adding them to the backup process.
Remove temporary SSH public keys, project tokens, runner registrations, and short-lived environment variables, then confirm in the relevant systems that the credentials are no longer valid.
Check the current rental term and future usage plan in the console. If you still need ongoing builds, first confirm that the data, node, and configuration continue to meet the task requirements.
Choose one of the two dedicated physical machine tiers, select a region from five nodes, and confirm a daily, weekly, monthly, or quarterly rental term.