Locations

Five locations,
across Asia-Pacific and US East

Choose a location based on your workflow. Both configurations are available at all five locations. Every order includes a dedicated physical Apple Silicon machine—not a virtual machine.

Rent by the day from $21.2/day. Check the console for live availability.

Locations
5 nodes
Configurations
2 dedicated models
Remote access
SSH / VNC / Screen Sharing
Locations

Place your node near your main workflows

For a graphical desktop, start with where your team works. For unattended builds, consider your repository, dependency sources and artifact destination too. These suggestions can help narrow your options; they are not a ranking based on measured latency.

SG

Singapore

A good option for developers and CI teams working across Southeast Asia. If you use the graphical desktop frequently, test the interactive experience from your usual network first.

Check: VNC responsiveness, dependency downloads and artifact uploads.

Choose Singapore
TYO

Tokyo, Japan

Well suited to app teams working primarily in Japan and developers who need to inspect Xcode projects remotely. Include team members who use the desktop regularly in your initial tests.

Check: desktop responsiveness, repository access and distribution uploads.

Choose Tokyo
SEL

Seoul, South Korea

A good fit for engineers and mobile development teams based primarily in South Korea. If your build dependencies and code services are nearby too, test the full pipeline end to end.

Check: code sync, cache restores and remote troubleshooting.

Choose Seoul
HKG

Hong Kong

Worth considering for teams collaborating across southern China and Southeast Asia. Cross-network performance depends on the route, so test from the office network you use day to day.

Check: office network routes, SSH access and file transfers.

Choose Hong Kong
USE

US East

A good option for teams on the US East Coast, and one to consider for teams in Western Europe. When pairing it with an Asia-Pacific node, assign build queues based on working hours and task labels.

Check: repository access, artifact uploads and cross-time-zone handoffs.

Choose US East

Location codes are shown for reference. Check the console for the current node names and availability when placing an order.

Model availability

Both models available at all five locations

The location determines where your node runs; the model determines its compute and storage resources. The table shows catalog availability, not live capacity or a guaranteed delivery time.

ArmVNC model availability by location
Model and specs Singapore
SG
Tokyo, Japan
TYO
Seoul, South Korea
SEL
Hong Kong
HKG
US East
USE
Arm Line M4M4 / 16GB / 256GB Available Available Available Available Available
Arm Grid M4 ProM4 Pro / 64GB / 2TB Available Available Available Available Available

Catalog availability isn’t live availability

Both models can be deployed at all five locations. Before confirming your order, check the model, location, billing period and final price in the console. “Available” in this table does not guarantee a fixed provisioning time.

How to choose

Compare three routes, not just locations on a map

A build involves code, dependencies, compilation and uploads. Geography is only part of the picture. For results you can act on, compare locations using the same project and commands.

  1. 01

    Where your team works

    If you regularly use VNC to edit projects, inspect the UI or troubleshoot signing, test the interactive route from the user to the node. Use your normal office network and test during your team’s actual working hours.

    Note how input, window movement and file transfers feel. A working SSH connection only confirms that the command-line route is reachable; it doesn’t tell you how the graphical desktop will perform.

  2. 02

    Distribution uploads

    If you upload to App Store Connect, time the upload stage separately. The build node’s location doesn’t determine the route to the receiving service, so don’t assume one route is faster based on the region name alone.

    Compare uploads, retries and processing results using the same valid build artifact. Track compile time, network transfer time and server-side processing separately instead of treating them as one number.

  3. 03

    Repository and dependencies

    A persistent CI runner needs regular access to source code, package dependencies and caches. Check access to your Git repository, private package registries and artifact storage before choosing a location.

    Run builds with both cold and warm caches, keeping the commit, Xcode version and build parameters consistent. Re-test after changing locations; one download isn’t a long-term performance guarantee.

Multi-location CI

Give each runner a clear, separate job

For example, deploy one runner in Singapore and another in US East. These are two independent physical nodes and execution environments—not a cluster with automatically shared memory or storage.

runner-apac · SG

Asia-Pacific hours: validate changes

Handle PR validation and project checks. Use a separate working directory and cache key, then upload test results, build logs and the commit ID to your team’s artifact storage.

Trigger
PR / selected branch
Handoff
Commit ID and logs
runner-use · USE

US East hours: continue to release

Pick up validated commits or release tags. Check toolchain versions, then run the archive job independently. Authorize release tasks separately to prevent multiple nodes from performing the same release operation.

Trigger
Release tag / manual approval
Handoff
Version record and artifact checks

Four rules for cross-location builds

  • Schedule by label. Assign different location labels to the two runners and explicitly select where each pipeline job runs. Your CI rules handle time-zone handoffs; deploying two nodes doesn’t make that happen automatically.
  • Keep environments consistent. Record macOS, Xcode and dependency lockfile versions. Avoid generating artifacts with the same name on different toolchains when they can’t be reliably compared.
  • Pass data explicitly. Use team-managed artifact storage to transfer files. Shared working directories, cache sync and retry policies must be configured separately.
  • Manage credentials separately. Give each runner only the permissions it needs. Before ending a rental, revoke its runner registration, remove sensitive credentials and save any logs or artifacts you need to keep.

Deploying across locations won’t move jobs that are already running or provide automatic failover. For redundancy, define retry conditions, concurrency limits and release locks in your CI system, then test recovery after an interruption.

Choose a location and start your first build

Confirm the model, location and billing period in the console. Both models are available at all five locations; check the console for live availability.

Payment by USDT-TRC20 or Visa / Mastercard / Amex (via Stripe). Prices are in USD.