Console account
Confirm that the person placing the order can sign in to the console and view orders, billing, nodes and device status. The technical owner should know who submits tickets and handles renewals.
From order to first build
Put a Cloud Mac
into your development workflow
This onboarding guide covers the required materials, choosing between two dedicated physical machine tiers, confirming four nodes, your first SSH login and Xcode build verification. Follow the steps in order and complete each one before moving on.
2 machine tiers
4 nodes
SSH and GUI
Singapore
Tokyo
Seoul
Hong Kong
Prepare
Account, SSH public key and toolchain requirements
Delivery
Based on the time confirmed in the console
Acceptance
Connection, system and build checks
Step 01 · Before you start
Prepare your connection materials and toolchain requirements
Clarifying who owns access, builds and permissions before ordering reduces back-and-forth after delivery. Each of the five items below should have a clear owner.
SSH public key
Prepare an Ed25519 public key approved by your team and submit only the public key. Keep the private key on a controlled device or in a key-management system; never send it by email, ticket or repository.
Xcode version
Confirm the target Xcode version from the project, CI configuration and dependencies, and record the minimum macOS requirement. Do not write only “latest”; keep a version number that can be checked.
Repository access
Confirm that the node can access the required repositories using restricted deploy keys or short-lived tokens. Define the minimum permission scope first, then decide whether artifact writes or status updates are allowed.
Remote desktop client
For graphical tasks, prepare a VNC or macOS Screen Sharing client in advance. Prefer SSH for automation, diagnostics and file operations to reduce reliance on graphical sessions.
Step 02 · Choose a plan and node
Choose between two configurations based on concurrency, workload and term
Both machine tiers use Apple Silicon physical nodes and dedicated physical machines, not virtual machines. Singapore, Tokyo, Seoul and Hong Kong are all in the catalogue; availability is based on the real-time response from the console when you place the order.
Core builds
ZoomMini M4 Core
M4 · 16GB RAM · 256GB SSD
$20.7
per day
Day $20.7
Week $56
Month $103.7
Quarter $282.1
Ideal for a single iOS build pipeline, everyday macOS compilation, dependency checks and a lightweight self-hosted runner that stays online.
How to choose: Measure peak memory and disk working-set usage during one clean build, then reserve space for dependency caches, logs and artifacts.
Concurrent workloads
ZoomMini M4 Plus
M4 · 24GB RAM · 512GB SSD
$39.2
per day
Day $39.2
Week $105.9
Month $196.2
Quarter $533.7
Built for larger Xcode workspaces, parallel tests, container workloads and teams that need more build cache and artifact storage.
How to choose: When a runner compiles, runs simulator tests and processes dependencies at the same time, check peak memory and cache growth first.
Node coverage
Evaluate all four nodes for latency and collaboration
Choose a node close to your main developers, code source or automation entry point. Do not compare a single ping alone; also observe stability during working hours and the remote desktop experience.
- SingaporeFor Southeast Asian collaboration and build access
- TokyoFor teams in Japan and nearby markets
- SeoulFor Korean and Northeast Asian workflows
- Hong KongFor collaboration across South China and Southeast Asia
Terms and add-ons
Review the complete configuration before payment
Rent by the day, week, month or quarter. For short-term validation, choose a term that matches the expected test duration; for a stable pipeline, align the term with your release cadence and renewal owner.
- +1TB SSD
- $2.9 per day · $7.7 per week · $14.3 per month · $38.9 per quarter
- +2TB SSD
- $5.8 per day · $15.4 per week · $28.6 per month · $77.8 per quarter
- Thunderbolt 5 link
- $1.9 per machine per day · $5.2 per week · $9.6 per month · $26.1 per quarter
Step 03 · Complete payment
Settle the order using the USD breakdown
The order lists the base machine, term, node and add-ons separately. All prices and settlement use USD; the person placing the order should review the details once before submitting payment.
USDT-TRC20
Check the network, amount and order identifier against the payment details returned by the console. Confirm that you are using the TRC20 network before transferring, then retain the transaction record for reconciliation.
Visa / Mastercard / Amex
Card payments are processed by Stripe. After returning from the payment page, check the order status and billing amount in the console; the browser return page is not proof that the device has been delivered.
01Check the machine
The plan name, M4 chip, memory and base SSD must match your selection.
02Check the term
Confirm day, week, month or quarter; do not mistake a short test rental for a long-term commitment.
03Check the node
Confirm that Singapore, Tokyo, Seoul or Hong Kong matches your connection plan.
04Check the add-ons
Confirm the SSD expansion and Thunderbolt 5 link quantity before submitting payment.
The payment gateway available for your order is determined by the console. Payment completion does not mean the device is ready to connect; continue by checking the order status and delivery details.
Step 04 · Read the delivery details
Use the device record in the console as your connection source
Once the device status shows that it is ready to connect, read the address, account instructions and rental term. Do not use chat messages, old screenshots or connection details from another order.
Delivery record
Six fields to verify before your first connection
Every field should come from the same order. If the node, address or term does not match expectations, stop and submit a ticket through the console before connecting.
- Device status
- Confirm that the record clearly says the device is ready to connect before starting an SSH or graphical session.
- Node
- Check that Singapore, Tokyo, Seoul or Hong Kong is the node selected when ordering.
- Connection address
- Copy the assigned host address and port to avoid character errors from manual entry.
- Account details
- Confirm the assigned username, how initial credentials are handled and which connection protocols are allowed.
- Term start
- Use this to confirm when the service begins and ensure it matches the order record.
- Term end
- Use this to plan renewal, artifact archiving, data migration and access removal.
Not ready to connect yet
Continue checking the order status in the console. Delivery timing follows the time confirmed in the console; do not repeatedly try an address that has not been provided.
Something needs checking
When submitting a ticket, include the order identifier, expected node, current device status and the time the issue was found. Do not include passwords, private keys or complete payment credentials.
Step 05 · First connection
Verify the host fingerprint before reading system information
On your first SSH connection, do not rush to install dependencies. Confirm that the target address, host fingerprint, login user and hardware details all belong to the current order.
$ export ZOOMMINI_HOST=assigned-host
$ ssh-keyscan -t ed25519 "$ZOOMMINI_HOST" | ssh-keygen -lf -
256 SHA256:7qV3mL9kR2nF4cX8 assigned-host (ED25519)
$ ssh build@"$ZOOMMINI_HOST"
Last login: remote session
build@zoommini-node ~ %
$ sw_vers
ProductName: macOS
ProductVersion: 15.2
BuildVersion: 24C101
$ system_profiler SPHardwareDataType
Hardware:
Model Name: Mac mini
Chip: Apple M4
Memory: 16 GB
$ uname -m
arm64Copy the address from the console
Put the assigned address in a temporary environment variable or SSH config to avoid an incorrect address entering your command history. Record the port parameter too if it is not the default.
Verify the host fingerprint separately
Compare the locally retrieved Ed25519 fingerprint with the delivery record character by character. If they differ, stop connecting and do not accept the changed record automatically.
Confirm the system and hardware
sw_vers confirms the macOS version, system_profiler confirms the chip and memory, and uname -m should return arm64.
Step 06 · Build verification
Use three commands to verify that the toolchain is pipeline-ready
First verify the selected Xcode, then build the project and finally run the automated tests. Keep the exit code and key logs from every step instead of judging success from the interface alone.
Check 01
Confirm the Xcode version
$ xcodebuild -version
Xcode 16.2
Build version 16C5032a
Success criteria
The Xcode and build versions match the project matrix, and the command exits with code 0.
Check 02
Build the project
$ xcodebuild -scheme App build
Prepare packages
CompileSwiftSources normal arm64
Ld App normal arm64
** BUILD SUCCEEDED **
Success criteria
The output ends with BUILD SUCCEEDED and contains no signing, dependency or disk-space errors.
Check 03
Run the automated tests
$ fastlane ios test
Resolving Swift Package Manager dependencies
Test Suite 'All tests' passed
Executed 48 tests, with 0 failures
fastlane.tools finished successfully
Success criteria
The test count matches expectations, failures are 0, fastlane finishes normally and the process exits with code 0.
Version mismatch
Run xcode-select -p to check the current developer directory, then switch it to match the team version matrix. Do not modify project files to work around a version issue.
Dependency resolution failed
Check repository access, package-manager paths and network access scope. Save the error log before clearing caches so the original failure evidence is not lost.
Signing step failed
Check how certificates, provisioning profiles and runner permissions are loaded. Inject secrets through a controlled key-management system rather than writing them into scripts or build logs.
Step 07 · Harden after delivery
Once the build passes, turn temporary access into a lasting configuration
A successful acceptance check only proves that the toolchain works. Before connecting it to CI/CD, update credentials, manage public keys, remove unnecessary access and apply least privilege to the runner.
Update account credentials
Replace any initial credentials that the delivery instructions require you to change. Use a unique, controlled password and never reuse it on a local development machine, repository or another node.
How to verify
Sign out and log in again to confirm that the old credentials no longer work.
Configure SSH public keys
Configure separate public keys for each person and automation identity that needs access. Do not share one private key among multiple people; key comments should trace back to a specific purpose.
How to verify
Test each authorised key separately and record its owner and rotation plan.
Remove unnecessary access
Delete public keys, repository tokens, administrator permissions and remote desktop access added temporarily during testing. Revoke access immediately for people who leave the team and runners that are decommissioned.
How to verify
Review authorised keys, user groups, startup items and runner registration records.
Restrict CI runner permissions
Allow the runner to read only the required repositories, run approved scripts and write to designated artifact locations. Do not grant system administrator access or cross-project tokens by default.
How to verify
Run one build with a least-privilege identity and confirm that unauthorised actions are denied.
Ready to use
Final acceptance checklist
Add the node to production scheduling only after all five conditions are met: order fields match, the SSH fingerprint matches, system specifications match, build and test exit codes are 0, and temporary permissions have been removed.
- Node and term recorded
- Host fingerprint verified
- Xcode version confirmed
- Build and tests passed
- Least privilege enforced
Ready to connect your first build pipeline?
Choose your machine, node and term first. Once the device is ready, follow this page to verify the fingerprint, check the system, validate the build and harden access.