Four physical nodes

Check latency first, then choose a node for your cloud Mac

GPUMini currently offers 4 regularly orderable nodes: Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Each instance runs on one dedicated physical Mac mini—not a virtual machine—and supports remote development, continuous builds, and long-running experiments.

4 nodes available
2 standard configurations
365 days of normal operation
GPUMini four-node routing map A Mac mini hardware outline connected to four nodes in Singapore, Tokyo, Seoul, and Hong Kong. Singapore SG Tokyo JP Seoul KR Hong Kong HK
PHYSICAL NODE ROUTE 1 instance = 1 physical Mac
Node directory

Four nodes, each with a clearly defined coverage area

Node selection does not change the hardware specifications or billing period. Measure latency from your everyday work network first, then choose a region based on team locations and code-source proximity. Actual availability for every combination is returned in real time by the console.

SG Southeast Asia

Singapore node

Ideal for developers primarily located in Southeast Asia, and suitable as a centralized build node for distributed teams. For graphics desktop tasks that are sensitive to connection quality, measure continuously from your actual office network before deciding.

Reference latency
20–50 ms
Test time
Weekdays 10:00–12:00, UTC+8
Listed configurations
Core and Plus
View Singapore node
JP East Asia

Japan (Tokyo) node

Ideal for development work accessed mainly from Japan and East Asia. If you frequently use the Xcode graphical interface, transfer build artifacts, or reconnect to a remote desktop session, compare jitter and packet loss on the Tokyo node first.

Reference latency
30–60 ms
Test time
Weekdays 10:00–12:00, UTC+9
Listed configurations
Core and Plus
View Tokyo node
KR Northeast Asia

South Korea (Seoul) node

Suitable for users in South Korea and Northeast Asia, as well as teams running automated tasks in a nearby region. If team members are spread across multiple locations, measure SSH and remote desktop paths separately before selecting one region.

Reference latency
30–50 ms
Test time
Weekdays 10:00–12:00, UTC+9
Listed configurations
Core and Plus
View Seoul node
HK South China & Southeast Asia

Hong Kong node

Suitable for teams whose main access locations are in South China and Southeast Asia. For highly interactive remote Mac desktops, compare it with the Singapore node under the same resolution and network conditions instead of judging by a single ping.

Reference latency
20–40 ms
Test time
Weekdays 10:00–12:00, UTC+8
Listed configurations
Core and Plus
View Hong Kong node
Network measurements

Put every access point on the same latency chart

The table below uses a standard office broadband connection and 50 ICMP pings to each node over the public internet, recording the median. Tests were conducted on August 29, 2026. Use these figures for initial screening only; they do not represent fixed results for any provider or time of day.

Median ping from primary access regions to the four GPUMini nodes
Test location Network type Singapore Tokyo Seoul Hong Kong
Southeast Asia office network Wired broadband, 50 samples 24 ms 71 ms 76 ms 39 ms
South China office network Wired broadband, 50 samples 47 ms 55 ms 49 ms 23 ms
Japan office network Wired broadband, 50 samples 74 ms 18 ms 34 ms 51 ms
South Korea office network Wired broadband, 50 samples 79 ms 36 ms 16 ms 53 ms
Don’t compare the lowest number alone.

Remote desktops are also affected by jitter, packet loss, bandwidth, and local Wi-Fi. Run three consecutive test rounds during actual working hours, and validate SSH, file transfers, and the graphical desktop separately.

Configuration matrix

Both configurations are listed across all four nodes

GPUMini M4 Core and GPUMini M4 Plus are available in Singapore, Tokyo, Seoul, and Hong Kong. Combinations in the directory are generally orderable; the console returns real-time availability when you place an order.

Orderable configurations by model and node
Configuration Singapore Tokyo Seoul Hong Kong
GPUMini M4 Core M4 · 16GB · 256GB Available Available Available Available
GPUMini M4 Plus M4 · 24GB · 512GB Available Available Available Available
How to choose a region

Choose a node using four types of evidence—not city names

A reliable region-selection process should account for interactive latency, team locations, dependency resources, and operating hours. A node close to one team member may not be the best fit for the overall workflow.

  1. 01

    Measure from your everyday network

    From your real office network and usual working hours, run multiple ping rounds to each node. Record the median, peak, jitter, and packet loss, then rule out unstable paths first.

  2. 02

    Check your primary access methods

    Graphical desktops are more sensitive to latency and jitter, while SSH builds and background tasks depend more on connection stability. If you use both, test them separately rather than relying on one metric.

  3. 03

    Account for your team and code sources

    Map frequent users, code repositories, and artifact transfer directions. For collaboration, choose the node that minimizes total waiting time instead of optimizing for just one person’s connection.

  4. 04

    Validate with a test build

    On each candidate node, complete code synchronization, dependency downloads, an Xcode build, log upload, and remote desktop reconnection. Record end-to-end time and failure points before choosing a long-term region.

Regional access

Review deployment details by node

Every regional page uses the same configurations and service boundaries. The only differences are node location, recommended access coverage, and reference network performance. On each regional page, you can still compare both configurations and all four rental periods.

Compare all options first
Status and diagnostics

When a connection fails, preserve reproducible details first

After signing in to the console, open instance details to view the node, configuration, service status, and linked order information. All four nodes operate normally 365 days a year; when a connection issue occurs, first determine whether it originates in your local network, authentication, remote desktop, or a task running on the node.

Instance information Node, model, instance ID, and time of occurrence
Connection path SSH or graphical desktop, client type, and local network
Error evidence Complete error text, reproduction steps, and redacted logs
Checks performed Ping results, port checks, disk space, and retry results

Instance and order status

When you need to verify an instance, order, or bill, sign in to the console and review the real-time information returned by the backend.

Open console

Troubleshoot connection issues

Check your network, credentials, disk, and build logs in that order. If the cause is still unclear, submit a support ticket with the relevant context.

Visit Help Center
Get started

Choose a node, then confirm the model and rental period

Singapore, Tokyo, Seoul, and Hong Kong all offer GPUMini M4 Core and GPUMini M4 Plus. Compare actual network latency before ordering, then manage your orders and instances centrally in the console after submitting the configuration.