Dedicated Apple Silicon physical nodes

Tokyo Mac mini M4
Move your build environment to the cloud

For developers across East Asia, run Xcode builds, simulator tests, and persistent CI on a dedicated cloud Mac. This isn’t a VM: CPU, GPU, and unified memory are yours alone, with no sharing between tenants.

Base rental from $21.3/day. Choose a model and rental term, then confirm the node in your order configuration. Availability is shown in real time in the control panel.

Allocation
1 physical node per order
Development environment
macOS desktop and command line
Billing terms
Daily / weekly / monthly / quarterly
Choose a setup for your workload

Two models, four rental terms

Check your project’s memory and storage requirements before choosing a rental term. Prices below are for the base models and exclude storage expansion and Thunderbolt 5 daisy-chaining. All prices are in US dollars.

Showing base daily rates. Confirm your billing term when placing your order.

Solo development and sequential builds

Node Core M4

Ideal for everyday Xcode builds, a single automated packaging pipeline, and TestFlight distribution. Start by running a representative project, then decide whether to upgrade based on the actual memory use of your simulators and build processes.

$21.3/day
Chip
M4
Unified memory
16GB
SSD
256GB
Daily
$21.3
Weekly
$57.6
Monthly
$106.7
Quarterly
$290.2

Allow for source code, dependency caches, DerivedData, and archived builds when estimating storage. Clearing reproducible caches is usually an easier way to manage usage than adding storage upfront.

Parallel testing and memory-intensive workloads

Node Pro M4

Built for large Swift projects, testing across multiple simulators, and local model experiments with tools such as MLX. 64GB of unified memory gives parallel workloads more headroom, but sensible concurrency and cache management still matter.

$59.1/day
Chip
M4 Pro
Unified memory
64GB
SSD
2TB
Daily
$59.1
Weekly
$159.6
Monthly
$295.6
Quarterly
$804

For persistent CI, start with one concurrent job and track peak memory use and build times before increasing concurrency. Avoid having multiple jobs write to the same build directory.

Choosing a rental term

For a test environment or a one-off release, start with daily billing. If you’ll be iterating continuously for a while, consider weekly billing. For persistent runners, ongoing testing, or long-term model experiments, compare monthly and quarterly billing. Changing the period here only updates the prices shown; it won’t create an order or start billing.

Payment is accepted via USDT-TRC20 and Visa / Mastercard / Amex (through Stripe), with charges in US dollars (USD). Available payment gateways and the order total are confirmed at checkout.

Consider distance and workload separately

Tokyo network reference

The average latency reference for connections from East Asia is 30~60ms. Use this as a guide when choosing a location, not as a fixed measurement for every route or a promise of desktop frame rate or file transfer speed.

Coverage reference
East Asia
Round-trip latency
30~60ms
Factors that affect results
Local ISP, inter-network routing, congestion, and VPN routing

Connection quality to the same node can vary between team members. SSH command-line interaction is mainly affected by round-trip latency. A graphical desktop is also affected by resolution, on-screen activity, and available bandwidth. Builds run on the physical node, so a slower local connection won’t move the workload to your computer.

Test your actual work network in three ways: run a series of SSH commands, open a desktop app you use regularly, and sync a representative project. Track the initial dependency fetch separately from subsequent incremental builds so that cold-cache download time isn’t mistaken for machine performance.

Test your connection after delivery

Replace the hostname in the commands with the connection address in your order details. Some networks restrict ICMP, so no ping response doesn’t necessarily mean SSH is unavailable. Check the connection using the relevant port and your client logs.

ping -c 20 NODE_HOST
ssh -o ConnectTimeout=10 USER@NODE_HOST 'uname -m'
Check the details, then connect

Four steps from order to ready

The times below are estimates for the actions you’ll take, not payment confirmation or delivery timeframes. Actual payment confirmation, node delivery, and project sync progress depend on the status shown in the control panel and your network connection.

  1. 01

    Choose your configuration

    Estimated time: 2–5 min

    Choose a model, billing term, and node, then check whether you need additional SSD storage or Thunderbolt 5 daisy-chaining. Review the base rental, add-ons, and total in the order summary before checking out.

  2. 02

    Complete payment

    Estimated time: 2–5 min

    Use the payment gateway presented at checkout. Blockchain confirmations and card verification aren’t included in this estimate. Keep your order number and transaction ID, then check the order status after paying; a transfer screenshot doesn’t confirm delivery.

  3. 03

    Check your connection details

    After delivery: 1–3 min

    Find the connection address, credentials, and instance status in your order details in the control panel. Confirm that the chip, memory, and storage match your order. Delivery progress is shown in the order status; don’t share your connection credentials publicly.

  4. 04

    Run your first job

    Initial setup: 5–15 min

    Test SSH or the graphical desktop, check the Xcode version, then sync your project and run a build. The estimate doesn’t include large repositories, first-time dependency downloads, or a full test suite. Start with a small job before moving persistent pipelines over.

Three questions to consider before choosing a location

About Tokyo nodes

Model specifications and term pricing are consistent across the catalogue. Location mainly affects connection routes and workflows, not the hardware configuration of a model with the same name.

Our team isn’t all in East Asia. Is this node still a good choice?

Choose based on who operates the machine most often and what they need to do. Team members who regularly use the graphical desktop should test their own connection routes first. Those who only trigger builds, check logs, and download artifacts are generally less sensitive to desktop latency. The latency reference for Tokyo from East Asia won’t necessarily apply to everyone on your team, so test from each person’s actual work network.

If we change nodes later, will our projects and caches move automatically?

Don’t assume files will move automatically when you change nodes. Back up your source code, essential configuration, and build artifacts, and record your toolchain versions and runner registration steps. Before leaving a Tokyo node, confirm order changes through a control panel support ticket, then plan your data sync and pipeline switch. Any available options and associated charges depend on the outcome of your order request.

If I choose Tokyo, will all pipeline data stay on this node?

No. The node location determines where your rented physical machine is hosted, but you may configure your code repositories, dependency mirrors, artifact storage, and release services separately. If data location matters to you, review each of these external services individually rather than treating the physical machine’s location as the boundary for your entire pipeline. For enterprise procurement questions, email support@xcodenode.com.

Run one project first, then choose a longer term

Start with one dedicated physical node, check your toolchain and connection, and run your first build. Choose a model based on your actual workload; there’s no need to configure multiple machines for the whole team upfront.