Singapore
For Southeast Asian teams, regional repositories, and mobile app testing users.
- Nodes available
- 6 nodes
- Configuration combinations
- 18 combinations
- Operating period
- 365 days
Singapore
Japan (Tokyo)
South Korea (Seoul)
Hong Kong
US East Coast
US West Coast
Available in the catalog
All nodes operate normally 365 days a year
Node Overview
The six nodes form a defined catalog—no splitting or additions.
Choosing a node does not change how your Mac mini is dedicated. Every order still maps to one independent physical node, with compute, memory, and local storage kept separate from other customers.
Japan (Tokyo)
Ideal for teams in Japan and low-latency development connections across East Asia.
South Korea (Seoul)
For Korean teams, local-user testing, and regional build workloads.
Hong Kong
Well suited to code and artifact transfers between South China and Southeast Asia.
US East Coast
Focused on East Coast teams and connectivity with Western Europe.
US West Coast
Focused on West Coast development, repositories, and testing users.
Node Selection Principles
Closer to your team does not always mean closer to your build path.
First identify where code, dependencies, artifacts, and test traffic enter the node, then compare the team’s remote-operation experience. For CI/CD, a stable path is usually more important than the lowest single ping.
Repository Location
Record the sources of your main repository, submodules, and large files. If your repositories are concentrated in the US, compare the US East and US West nodes first; if dependencies are mainly in Asia-Pacific, test the four Asia-Pacific nodes next.
Team Location
SSH input, log viewing, and graphical-interface operations are all affected by round-trip latency. For collaboration, test from each primary office network rather than drawing conclusions from one member’s home connection.
Target Test Users
The regions hosting your app APIs, test accounts, and external services affect end-to-end validation. Choose a node near the main testing path—not necessarily near the final release market.
Cross-Border Path Stability
Run continuous tests during both peak and off-peak business hours, tracking the median, jitter, and packet loss. Do not substitute the lowest value from a single ping for real network performance during sustained builds.
Configuration Availability
Three configuration tiers across six nodes, for 18 catalog combinations.
The matrix shows the fixed relationship between models and nodes. Every combination is available to order from the catalog; actual availability is returned in real time by the console when you place an order.
| Available configurations | Singapore | Japan (Tokyo) | South Korea (Seoul) | Hong Kong | US East Coast | US West Coast |
|---|---|---|---|---|---|---|
| OnceMac M4 16 M4 · 16GB · 256GB | Available | Available | Available | Available | Available | Available |
| OnceMac M4 24 M4 · 24GB · 512GB | Available | Available | Available | Available | Available | Available |
| OnceMac M4 Pro 64 M4 Pro · 64GB · 2TB | Available | Available | Available | Available | Available | Available |
Latency Testing
Compare paths by the median—not by the lowest value.
The table uses ICMP ping. Each “test city–node” combination sends 30 consecutive samples, and the round-trip latency median is reported. Use these results to narrow your options, then retest from your actual office network before ordering.
| Test city and carrier type | Singapore | Japan (Tokyo) | South Korea (Seoul) | Hong Kong | US East Coast | US West Coast |
|---|---|---|---|---|---|---|
| Hong Kong · Business internet | 35 ms | 48 ms | 42 ms | 7 ms | 196 ms | 143 ms |
| Shanghai · Fixed broadband | 82 ms | 58 ms | 66 ms | 39 ms | 214 ms | 151 ms |
| Tokyo · Business internet | 74 ms | 6 ms | 34 ms | 51 ms | 181 ms | 112 ms |
| Seoul · Business internet | 79 ms | 37 ms | 5 ms | 43 ms | 187 ms | 127 ms |
| Singapore · Business internet | 5 ms | 76 ms | 81 ms | 38 ms | 228 ms | 167 ms |
| Frankfurt · Business internet | 168 ms | 236 ms | 241 ms | 205 ms | 91 ms | 154 ms |
| Virginia · Fixed broadband | 238 ms | 176 ms | 185 ms | 209 ms | 8 ms | 73 ms |
| San Francisco · Fixed broadband | 173 ms | 109 ms | 128 ms | 146 ms | 71 ms | 9 ms |
Measure baseline round trips first
Send at least 30 samples to each candidate node, recording the median, maximum, and packet loss. Keep the network, device, and connection method consistent throughout testing.
Then run real transfers
Run a repository clone, dependency restore, and artifact upload. Small-packet pings cannot replace the throughput performance of large Git files, caches, and archives.
Finally, test during peak hours
Repeat testing during your team’s actual working hours. Public-network paths vary by carrier, routing, and time of day; the medians in the table are not a fixed-latency guarantee.
Asia-Pacific Coverage
Four Asia-Pacific nodes for four distinct work paths.
Nearby cities are shown only to explain coverage direction, not as additional available nodes. The Asia-Pacific catalog is fixed: Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong.
SG
Singapore
Southeast Asia coverage hub
For workloads where team members, code mirrors, or test services are mainly distributed across Southeast Asia. For pipelines connecting to regional APIs, downloading dependencies, and uploading build artifacts, compare actual throughput with the Hong Kong node as well.
- Check Southeast Asian repository and dependency-download paths first
- Suitable for regional mobile app testing and continuous builds
- From mainland China, retest across multiple carriers first
JP
Japan (Tokyo)
Japan and East Asia development paths
For teams in Japan, repositories near Tokyo, and testing against local services. If dependencies are mainly in South Korea or the US West Coast, include Seoul and US West in the same sample batch.
- Ideal for local SSH and graphical-interface operations in Japan
- Suitable for validating application APIs in Japan
- Measure trans-Pacific dependency-download throughput separately
KR
South Korea (Seoul)
Korean teams and local testing paths
For stable communication between Korean development teams, self-hosted runners, and local testing services. For cross-region collaboration, sample from both the Seoul office network and remote members’ networks to avoid masking path differences with a single result.
- Prioritize Korean development and testing teams
- Suitable for build queues that require a stable, repeatable toolchain
- Remote members should independently verify remote-operation latency
HK
Hong Kong
A connection point between South China and Southeast Asia
For scenarios where code, dependencies, and teams are distributed between South China and Southeast Asia. Public-network paths from mainland China can vary significantly by carrier; run peak and off-peak tests from the actual office network.
- Ideal for South China teams comparing remote-development experience
- Supports local Hong Kong APIs and testing users
- Do not replace sustained path monitoring with a single low-latency result
US Coverage
The US catalog has just two nodes: East and West.
The US West Coast is one unified node and is not split further by city. Compare repository direction, team location, external-service region, and trans-Pacific traffic when choosing.
US-E
Available
US East Coast
For East Coast teams, code and artifact services in the eastern US, and build workloads that also need access from Western Europe. If developers are mainly in Europe, compare end-to-end repository operations first before deciding whether US East outperforms US West.
- Primary coverage
- US East Coast and Western Europe
- Check first
- Repository, artifact, and external API paths
- Available configurations
- All 3 tiers supported
US-W
Available
US West Coast
For West Coast teams, trans-Pacific collaboration, and development paths with dependencies in the western US. For projects with remote Asia-Pacific members, test Japan, South Korea, and US West in the same batch.
- Primary coverage
- US West Coast and trans-Pacific paths
- Check first
- Dependency downloads and build-artifact uploads
- Available configurations
- All 3 tiers supported
Regional Order Page Structure
Every node uses the same decision information, including key pricing and connection requirements.
The console generates localized ordering information for each of the six nodes. The page structure remains consistent, while the node name, coverage area, and latency references are adapted to the relevant region to prevent conflicting specifications across nodes.
REGION ORDER SHEET
Live status
Node Ordering Information Structure
Localized title and coverage details
Clearly identify the current node, primary coverage area, catalog status, and suitable teams; do not present nearby test cities as new nodes.
$19.1/day$51.6/week$95.5/month$259.8/quarter
$40.1/day$108.3/week$200.5/month$545.4/quarter
$59.7/day$161.1/week$298.4/month$811.6/quarter
Latency and connection metrics
Show the reference range, test cities, carrier type, sample count, and median for the relevant region, along with the recommended order for checking the first SSH connection.
Common pre-order questions
Explain the three configurations, four rental periods, node selection, and delivery steps. Catalog combinations are generally available to order; actual availability is returned in real time by the console.
Choose a node and configuration
Choose a region from the six nodes, then select one of OnceMac M4 16, OnceMac M4 24, or OnceMac M4 Pro 64.
Confirm rental period and pay
Choose a daily, weekly, monthly, or quarterly rental period. Payments are limited to USDT-TRC20 and Visa / Mastercard / Amex (via Stripe), with all charges settled in USD.
Copy connection details
After delivery, view the host address, username, and key information in the console, then complete the SSH connection using the Help Center instructions.
Ready to choose a node
Retest candidate paths first, then submit your cloud Mac configuration.
All six nodes offer three dedicated physical-machine configurations and operate normally 365 days a year. Choose your configuration, node, and rental period, then pay in USD.