- Service region
- East Asia
- Latency reference
- 30~60ms
- Resource type
- Dedicated physical machine
- Available configurations
- 3 tiers
Tokyo Mac mini M4
Always-on Xcode builds
Built for developers and CI/CD teams in East Asia, with a complete Apple Silicon physical machine available by the day, week, month, or quarter. Resources are never shared with other tenants, and you get full access to the macOS GUI, command line, and self-hosted runner.
- One order gives you one dedicated physical node—not a shared virtual machine
- Three fixed configurations, starting at $20.7/day
- Supports Xcode, Fastlane, VNC, SSH, and popular CI runners
Actual availability for each model and node is shown in real time in the control panel.
Choose your workload, then your billing period
All three tiers use dedicated Apple Silicon physical machines. Daily billing suits one-off archives and failover needs, weekly billing fits sprint cycles, monthly billing is ideal for stable CI, and quarterly billing suits sustained build capacity. All prices are in USD.
Go M4 Core
Ideal for single-project development, ad hoc signing, low-frequency archiving, and self-hosted runners with modest concurrency requirements.
Go M4 Plus
Ideal for multi-project development, mobile apps with large dependency caches, and everyday CI that requires parallel testing and archiving.
Go M4 Pro
Ideal for high-concurrency builds, larger caches, multiple runner queues, and AI inference workloads that need more unified memory.
Average latency to East Asia: 30~60ms
Use this figure to compare locations during planning. It reflects a reference range across typical public-internet routes, not a fixed guarantee for every connection. Actual performance depends on the developer’s network, inter-network routing, time-of-day congestion, VNC quality settings, repository location, and dependency sources.
If you mainly use the graphical interface over VNC, assess input response, screen refresh, and session stability together. For CI-focused workflows, prioritize code checkout, dependency-cache hit rate, and artifact upload paths. For automated tasks, SSH and runners typically use less bandwidth than continuously streaming a high-quality desktop.
Connection Quality Checklist
Use your team’s everyday network to test VNC input, SSH handshakes, and repository cloning—not just a single ping.
Reuse dependencies and DerivedData to reduce fluctuations from repeated downloads across the network.
Use VNC for desktop operations, and prefer SSH or a runner for batch processing and build commands.
When switching nodes, first record the repository location, developer network, and primary service targets, then contact support at support@macvpsgo.com or through a control-panel ticket.
From host selection to your first build
Estimated times cover the user-action steps. Payment confirmation, order processing, and node availability are shown in real time in the control panel, so you do not need to repeatedly enter the same information across pages.
-
01 About 3–5 minutes
Choose the primary configuration
Select one of the three fixed configurations based on project count, concurrent tasks, cache size, and memory needs. Cover your steady workload first, then account for temporary peaks.
- Confirm the chip and memory
- Estimate your working-directory size
- Choose a daily, weekly, monthly, or quarterly term
-
02 About 2–3 minutes
Add a node and optional extras
Choose your order node, then decide whether to add SSD capacity or Thunderbolt 5 parallel connectivity based on your data volume. Add-ons must use the same term as the host.
- Verify the target node
- Choose a storage expansion
- Review the order details
-
03 About 2–5 minutes
Complete payment in USD
Pay with USDT-TRC20 or with a Visa, Mastercard, or Amex card processed by Stripe. The checkout page will show which gateways are currently available.
- Confirm the order total
- Choose a supported payment method
- Keep your payment record
-
04 About 10–20 minutes
Complete the initial environment check
Once delivery details appear, connect through VNC or SSH and check disk space, the Xcode version, command-line tools, and the runner working directory.
- Verify desktop and command-line access
- Clone your code and restore dependencies
- Run a test archive
Three things to confirm about Tokyo nodes
These answers focus on node selection, latency metrics, and order configuration to help you complete your final checks before placing an order.
Which teams are Tokyo nodes best suited for?
They are primarily designed for developers and teams whose repositories or business collaboration are centered in East Asia. When choosing a location, consider not only where team members are based, but also the locations of repositories, dependency sources, artifact storage, and remote-desktop users. For distributed teams, start with the most frequent interaction path.
Does 30~60ms mean every connection will have the same latency?
No. 30~60ms is an average latency reference for East Asia, intended to compare node directions. Public-internet routing, carrier interconnection, usage time, and local networks all affect actual results. We recommend evaluating VNC input, SSH command response, code checkout, and artifact upload in the same test.
Can I change the configuration directly after submitting a Tokyo node order?
You can change the host, term, and add-ons before confirming the order. After the order is created, review the current order in the control panel and submit a ticket if you need to adjust the configuration or node; the support team will explain the available path based on the existing order and target configuration. Do not delete your only data copy before migration.
Put your next build queue on a dedicated Mac mini
Choose a configuration first, then confirm the term, node, and add-ons. The order price and actual availability are clearly shown before submission.