SG
Singapore
For teams across Southeast and South Asia. A good place to start comparing when most of your developers are based in the region.
- MiniSSH M4 Core
- Available
- MiniSSH M4 Plus
- Available
Choose a location for your distributed team
4 Locations. Choose the One Closest to You.
Singapore, Tokyo, Seoul and Hong Kong. Every location runs on a dedicated physical machine, not a virtual machine, and stays online 365 days a year. Start with where your team connects from, then choose where to run your Mac mini.
Choose a daily, weekly, monthly or quarterly term. Add capacity during busy periods; service stops when the term ends unless you renew.
Start with where your team connects from
All four locations offer two M4 models. “Available” is a directory listing; check the console for real-time availability. Select a city to open the order configuration with that location preselected.
JP
Tokyo
For teams in Japan and North American teams connecting across the Pacific. North American team members should test from their own ISP and network route before choosing.
- MiniSSH M4 Core
- Available
- MiniSSH M4 Plus
- Available
KR
Seoul
For teams in Korea and Northeast Asia. A strong candidate when team members in Korea handle day-to-day interactive development.
- MiniSSH M4 Core
- Available
- MiniSSH M4 Plus
- Available
HK
Hong Kong
For teams in Hong Kong, Macao, Taiwan and southern China. Compare real-world connection quality for developers and delivery teams working across these areas.
- MiniSSH M4 Core
- Available
- MiniSSH M4 Plus
- Available
Indicative ranges, not measurements for every route
Check the coverage area, then compare latency
Use these ranges to narrow down your options. They are not guaranteed latency figures from your city to a location, nor a promise for trans-Pacific routes from North America. Your ISP, inter-region routing and local network all affect the experience.
| Location | Coverage area | Typical round-trip latency | Best suited to |
|---|---|---|---|
| Singapore | Southeast and South Asia | 20~50ms | Remote desktop, builds, file transfers |
| Tokyo | Japan and North American teams connecting across the Pacific | 30~60ms | Remote desktop, builds, file transfers |
| Seoul | Korea and Northeast Asia | 30~50ms | Remote desktop, builds, file transfers |
| Hong Kong | Hong Kong, Macao, Taiwan and southern China | 20~40ms | Remote desktop, builds, file transfers |
These are indicative ranges; actual results depend on your network. Hong Kong may also suit teams connecting from southern China and Southeast Asia. Choose based on your team's own experience.
The closest location on a map isn’t always the best fit
Shortlist a few options, then have the people who use the machines every day test them. Check how responsive the remote desktop feels, whether the toolchain suits your build work, and how well file transfers perform over time.
-
01
Start with your team
For Southeast Asia, start with Singapore. If most users are in Japan or Korea, compare Tokyo or Seoul. For teams in southern China, Hong Kong or Taiwan, start with Hong Kong. Ask regular users to test—not just the person handling procurement.
-
02
Test your actual workflow
From your usual network, try an SSH login, a remote desktop session and a project file transfer. If builds are a key workload, run your own build process too. A single latency figure can’t tell you how these tasks will feel.
-
03
Test from North America
North American colleagues can add Tokyo to the shortlist, but shouldn’t rely on the East Asia ranges in the table. Test the trans-Pacific connection from your actual office network during your usual working hours before choosing a long-term location.
-
04
Give us the details
If you run into connection issues, submit a ticket through the console with the node ID, city, time of the issue and your time zone. Note whether the issue affects SSH, desktop interaction or file transfers. Don’t include passwords or private keys.
Choose a term that fits your project
Keep one year-round; add capacity when you need it
A multi-location setup means renting separate physical machines; it does not move a machine between cities automatically. Plan for your regular workload and short-term peaks separately, and confirm the location, configuration, term and end date for each machine.
Plan your regular setup by the quarter
Keep a day-to-day development environment in the city that works well for most of your team. MiniSSH M4 Core is M4 / 16GB RAM / 256GB SSD, $282.6 per quarter; MiniSSH M4 Plus is M4 / 24GB RAM / 512GB SSD, $559.8 per quarter.
Choose a model based on your toolchain, file sizes and workload—not the location.
Add a second city for peak periods
If colleagues in another region need an interactive development environment or you need to split up work for a release, add a machine in another city. Test the connection by the day first, then choose a weekly term once you know how long you’ll need it. Keep temporary work separate from your regular environment.
This is a separate machine. You’re responsible for syncing project files, developer accounts and tool settings.
Back up before the term ends
When an event or release is over, a machine stops running at the end of its term if you don’t renew. There’s no separate deactivation fee. Export your code, build artifacts and any settings you need before the end date; don’t rely on a temporary machine as your only backup.
Manage any machines you keep according to their individual terms. Check end dates and renewal details in the console.
Pick a city and get started
Already know which city you need? Select it from the cards above to preselect your location. Still comparing? Head to the configuration page to choose a model, location and term. Prices start at $20.8/day; service stops at the end of the term unless you renew.