Singapore, Tokyo, Seoul, Hong Kong, the US East, and US West each offer three tiers of dedicated Apple Silicon physical nodes. Narrow your options by team, repository, and dependency location, then test with real workloads. Directory combinations are generally available to order; confirm live availability in the console.
3 tiers · 6 nodes · Dedicated physical machines · No virtualization · USD billing
Node names indicate optional regional delivery locations and do not guarantee fixed latency. Every node includes VPSGit M4 Core, VPSGit M4 Plus, and VPSGit M4 Pro configurations.
A strong fit for workflows with team members, artifact storage, and business dependencies across Southeast Asia, and a candidate starting point for collaboration across Asia.
A strong fit for development work centered on repositories, package mirrors, or team collaboration in Japan and nearby regions, with local remote desktop performance worth evaluating.
A strong fit for teams with developers, repository services, or collaborators in South Korea and Northeast Asia. Focus on dependency downloads and interaction stability.
A strong fit for development workflows connecting teams in South China, Hong Kong, and Southeast Asia. Evaluate remote desktops, asset transfers, and regional dependencies.
A strong fit for build and automation workloads whose repositories, artifact platforms, team members, or end-user services are concentrated in Eastern North America and Western Europe.
A strong fit for West Coast teams, regional repositories, and service dependencies, and a US-side candidate for collaboration with Asia-Pacific teams.
A single build may traverse the developer network, code repository, package mirror, artifact storage, and final test environment. The best node makes the critical path more reliable—not necessarily the one closest on a map.
Remote desktops and interactive debugging are more sensitive to round-trip latency and jitter. Start by testing a node near primary operators, then check stability during peak hours.
Frequent pulls of large repositories, submodules, or large files can directly affect job startup time. Compare full clones with incremental pulls rather than testing only the homepage response.
Validate Swift Package Manager, Homebrew, RubyGems, npm, and private caches separately. If critical dependencies are concentrated in one region, prioritize proximity to them.
Multiregional teams should identify who operates during each handoff window and who handles failed jobs. Choose a node that works well for both shifts.
If the Cloud Mac also serves previews, tests, or lightweight inference APIs, consider where results are consumed and include the return path in testing.
The table shows the current directory relationship. All listed combinations are marked available; actual availability is returned live by the console when you place an order.
| Configuration | Singapore | Japan (Tokyo) | South Korea (Seoul) | Hong Kong | US East | US West |
|---|---|---|---|---|---|---|
| VPSGit M4 Core M4 · 16GB · 256GB | Available | Available | Available | Available | Available | Available |
| VPSGit M4 Plus M4 · 24GB · 512GB | Available | Available | Available | Available | Available | Available |
| VPSGit M4 Pro M4 Pro · 64GB · 2TB | Available | Available | Available | Available | Available | Available |
Singapore, Tokyo, Seoul, Hong Kong, US East, and US West support builds, inference, media processing, and remote collaboration. The main difference is the actual path between operators and external services.
When developers, object storage, package mirrors, or business test environments are concentrated in Southeast Asia, Singapore is often worth prioritizing. Remote desktop teams should check input response during normal work hours, while CI teams should track full dependency restoration, cache hits, and artifact upload times.
When primary operators, code repositories, or test services are in Japan, Tokyo can reduce cross-region hops in the workflow. For frequent GUI use, test keyboard and mouse response, screen updates, and large-file transfers—not just SSH connectivity.
Seoul suits workflows whose primary members or external dependencies are in South Korea and Northeast Asia. Self-hosted Runners should execute representative jobs covering dependency installation, compilation, testing, and artifact uploads, with each stage recorded.
Hong Kong can serve as a candidate handoff point for teams in South China, Hong Kong, and Southeast Asia. Media workflows should test proxy asset sync, timeline operations, and export transfers; development workflows should verify that repositories, dependencies, and test services follow a sensible path.
US nodes are not split into additional cities. Choose based on the main distribution of repositories, CI services, team members, and end users rather than office address alone.
A strong fit for tasks involving repositories, artifact services, team members, or test targets in Eastern North America and Western Europe. For CI, compare cold-cache pulls, concurrent job startup, and artifact uploads; for remote collaboration, cover core work and handoff hours.
A strong fit for West Coast teams, regional repositories, and service dependencies, and for US-side workflows connecting to Asia-Pacific collaborators. Measure operator-to-node, node-to-repository, and node-to-artifact-storage paths separately rather than averaging them together.
Tests should be repeatable, recorded, and cover the operations you actually care about. Keep command output, job timing by stage, and experience notes so the team can evaluate results together.
From your primary office network, record round-trip latency, packet loss, and route changes. Cover both normal work hours and peak periods; do not conclude from a single minimum value.
Monitor latency variation over time and watch for intermittent pauses in remote desktop input. When average latency is similar, the steadier path is usually better for interactive work.
Perform window switching, code editing, simulator operations, and file drag-and-drop. Record screen updates, input response, and stability during sustained use.
Run cold-start and cache-hit jobs on a representative repository, recording repository pulls, dependency restoration, compilation, testing, and artifact uploads separately.
Every node page uses the same fields, changing only regional facts, recommended scenarios, and preselected order parameters. This makes nodes directly comparable without losing key criteria to different page structures.
Clearly state the node name, coverage direction, available configurations, and paths worth validating. Do not add cities outside the directory or promise fixed network latency.
Explain fit based on developer location, repositories, dependencies, team time zones, and end users instead of replacing real testing with generic labels.
A regional entry point only carries the selected node into configuration. The user still confirms the configuration, term, and add-ons; live availability comes from the console.
Moving between nodes requires reconfirming target availability, scheduling data transfer, and updating access controls and automation. Reserve time for validation and rollback before migrating.
Confirm that the target node supports your current configuration and add-ons, then use the console’s live result to schedule delivery of the new node.
Inventory repositories, caches, models, assets, build artifacts, and service configuration. Prefer restoring from independent backups and verify file integrity.
Adjust SSH host records, firewall allowlists, Runner labels, artifact upload targets, and team handoff documentation. Revoke access to the old node.
Before the old term ends, test builds, connections, dependency downloads, and result transfers. Complete the switch only after confirming the new node meets requirements.
All three dedicated Apple Silicon physical node tiers are available across six regions. In configuration, choose the machine, a daily-to-quarterly term, and add-ons. Confirm live availability in the console.