SDKMac provides dedicated physical Cloud Macs. Each order corresponds to one physical node, not a virtual machine. Before you begin, confirm your macOS and Xcode requirements, task concurrency, region, storage capacity, and remote access method, then proceed with configuration and delivery.
Your physical node will host your builds, tests, or experimental environment on an ongoing basis. Before ordering, the goal is not to choose the biggest numbers, but to define the required system, toolchain, memory, storage, and access method.
List the project’s required macOS version, Xcode major version, command-line tools, package managers, runtimes, and build scripts. If the project uses multiple version matrices, define the environment for each task group first to avoid repeatedly overwriting dependencies in the same directory.
Record the space required for typical repository size, dependency caches, build artifacts, simulator data, models, or media assets. Leave headroom for temporary files and concurrent tasks; do not estimate disk needs from source-code size alone.
Use remote desktop for graphical workflows and SSH for automation and command-line tasks. Confirm the source network, client policy, credential custodian, and revocation process for personnel changes in advance.
Use this checklist to reduce changes after ordering. Each item maps to a configuration, region, billing, or access field on the delivery board.
Specify whether the node is for daily Xcode development, automated builds, multi-version testing, AI experiments, or audio/video batch processing, and define the first verification task.
Choose between SDKMac M4 and SDKMac M4 Pro based on memory pressure, storage capacity, and concurrent workloads.
Choose from Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong, and test connectivity based on your team’s location and dependency services.
Confirm whether you will use a daily, weekly, monthly, or quarterly cycle. Do not mix prices from different cycles in the same budget comparison.
Confirm that the base storage is sufficient, and include caches, build artifacts, models, media, and temporary files in capacity planning.
Confirm that the remote desktop or SSH client, local network policy, source restrictions, and credential management process are ready.
The catalog offers only two configurations, and both models are available in all four regions. Actual availability is determined by the console in real time; there is no need to guess between disabled options.
M4 · 16GB · 256GB SSD
Suitable for daily Xcode development, light automation, small repository validation, and single-stream tasks. Before choosing, confirm that 16GB of memory and 256GB of local storage cover your dependencies, caches, and artifacts.
M4 Pro · 64GB · 2TB SSD
Suitable for high-concurrency builds, large repositories, multi-task testing, memory-intensive experiments, and large media workloads. The 2TB SSD accommodates larger caches and working sets.
Choose based on your team’s location, dependency services, target market, and actual connectivity tests rather than unverified fixed-latency assumptions.
The billed amount consists of the selected model, rental cycle, node, and add-ons. Save the team’s confirmation before submitting to avoid leaving temporary storage needs or linked devices out of the order.
Daily $2.6 · Weekly $7 · Monthly $12.9 · Quarterly $35.1
Daily $5.2 · Weekly $14 · Monthly $25.8 · Quarterly $70.2
Daily $1.9 · Weekly $5.2 · Monthly $9.7 · Quarterly $26.4
After submitting an order, use the console to check order confirmation, node preparation, credential generation, and accessible status. Each status calls for a different action; resubmitting configuration will not move the physical node forward faster.
Verify that the model, memory, storage, node, billing cycle, and add-ons match the submitted order. If any field differs, submit an order support request before continuing to prepare the development environment.
While the physical node is being registered and prepared, organize your client, repository access, and environment checklist. Do not recreate the same configuration or repeatedly change connection parameters.
Read the host details and initial credentials, then give them to the designated custodian for storage. Do not copy unsanitized credentials into tickets, public repositories, or public team channels.
Start the first connection only after the status is complete. Verify the host, region, and configuration first, then update access security settings, and finally install or verify the project toolchain.
The goal of the first connection is not to run the full pipeline immediately. First confirm that you connected to the correct physical node and complete the access security settings required by your team.
Compare the host identifier, node region, and order identifier shown in the console with your internal records. Do not identify the connection solely by the desktop appearance.
Use remote desktop when you need a graphical interface; use SSH for automation, scripts, and file operations. Restrict sources and assign access according to your team policy.
After the first login, promptly update the initial credentials and confirm least privilege, ownership, revocation procedures for personnel changes, and the process for recording abnormal access.
Verify keyboard input, clipboard policy, SSH sessions, repository access, and dependency download paths before installing large tools or syncing assets.
Record the system baseline first, then install project dependencies. A clear sequence helps the team determine whether an issue comes from the node, toolchain, project configuration, or an external dependency.
Record the system version and available space, check the project minimum requirements and team upgrade policy, and avoid broad system changes before verification.
Confirm the Xcode major version, command-line tools path, SDK, and build target. When multiple projects share a node, define clear invocation rules for each toolchain.
Transfer and store signing materials according to your team’s access policy, restrict access to authorized personnel, and never place sensitive content in scripts, build logs, or repositories.
Verify repository access, submodules, private dependencies, and large-file policies. Run the initial clone test with read-only or least-privilege access before enabling writes.
Separate dependency caches, DerivedData, test artifacts, archives, and temporary files. Record cleanup conditions to prevent unbounded cache growth.
Do not make the first run a full release pipeline. Choose a small build or test with clear dependencies, predictable duration, and easy-to-interpret results to verify the toolchain, disk, and network dependencies first.
Once the baseline task is stable, gradually increase repository size, test scope, or concurrency. Change only one primary variable at a time so results remain comparable.
After completing the first task, use the order record to verify node ownership, configuration, region, storage, and access method. If you find a discrepancy, preserve the current evidence first rather than overwriting it with a broad reinstallation.
Verify the order identifier, SDKMac M4 or SDKMac M4 Pro, memory, and base storage, and ensure records from another node have not been mixed into the current delivery.
Check Result: Match or Record the DifferenceConfirm that the node is in the selected Singapore, Japan (Tokyo), South Korea (Seoul), or Hong Kong region, and record the remote desktop or SSH path actually used by the team.
Check Result: Region and Path RegisteredVerify the base storage, SSD expansions, and Thunderbolt 5 linking options, and check that the system-detected result matches the order details.
Check Result: Capacity and Add-ons ConfirmedSave the task inputs, duration, disk changes, network dependencies, and redacted logs. For issues, submit a support request with the order identifier, region, time, reproduction steps, and expected result.
Check Result: Baseline and Evidence SavedChoose the model, region, and billing cycle first, then read the delivery status in the console. The node is a dedicated physical machine, not a virtual machine, and runs continuously 365 days a year.