A nearby cloud Mac for users in East Asia: handle remote development, Xcode builds, and app releases on your own dedicated physical server.
Not a virtual machine. Choose from two M4 configurations and pay in advance by the day, week, month, or quarter, starting at $20.8/day. Get started the same day; service stops at term end unless renewed.
Choose a node and confirm the end date when ordering. Check the console for the latest availability status.
Both plans run on dedicated Mac mini M4 servers. Choose memory and SSD capacity for your project, then select a term to match your workload. Extra nodes for busy periods can have separate end dates.
Daily pricing is shown. All term prices are listed on each plan card.
Mac mini M4 / 16GB RAM / 256GB SSD
$20.8 /day
Ideal for individual remote development, a single build pipeline, or occasional packaging. Check your project dependencies and local cache requirements before deciding whether you need more storage.
Mac mini M4 / 24GB RAM / 512GB SSD
$41.2 /day
Room for more developer tools, project dependencies, and build caches. If sharing with a team, schedule build jobs to avoid resource contention from heavy workloads running at the same time.
The estimated round-trip latency range for East Asia is 30~60ms. Use this as a guide when choosing a node—not as a measured average for your network or a guarantee for every connection.
| Item | Reference and limitations |
|---|---|
| Node and service area | Tokyo, serving users in East Asia. |
| Estimated round-trip range | 30~60ms |
| Connection quality | Your actual experience depends on your network. ISP routing, cross-region links, packet loss, and local Wi-Fi can all affect performance. |
| Availability | Physical nodes run 365 days a year. If an issue arises, sign in to the console and submit a support ticket. |
Interactive remote desktops are more sensitive to latency and jitter. Build times also depend on project size and toolchain, while file transfers depend on bandwidth. Test editing, building, and transferring artifacts on your team's actual network before choosing a longer billing term; don't decide based on one latency figure alone.
Get started the same day. The process takes about 4 minutes in total. These are estimates for the steps and setup time, not a countdown or guarantee of payment confirmation or order completion. Track progress in the console.
Confirm memory, SSD, rental term, and end date. If you need extra capacity temporarily, order another server without changing the node you're already using.
Pay with USDT-TRC20 or a card via Stripe. Check the amount in USD and the payment method, and keep your order number. For on-chain payments, also save the transaction hash.
Check your order and instance status in the console. Don't place duplicate orders while the node is being prepared. If something goes wrong, open a support ticket from your existing order.
Once the node is ready, find connection details in the instance page in the console. Log in with your SSH public key. Check disk space and developer tools before pulling your project.
Estimated total: about 4 minutes
Have your SSH public key ready before you start. Back up your code, build artifacts, and any configuration you need before the end date. At term end, service stops and the node enters the recovery process; no deactivation fee applies.
Consider your team's network, ongoing workloads, and end-of-term handoff before choosing how long to rent the server.
It may be a good node to evaluate first, but geographic distance isn't the only factor. 30~60ms is an estimated round-trip range; actual performance depends on each team member's network. Start with a daily rental and test real development tasks, checking responsiveness, file transfers, and build wait times before choosing a longer term.
Use a real repository to install dependencies, create a full archive, and download the build artifacts. Note memory usage, available disk space, and build time. Also check required tool versions and how signing materials are managed. Both plans use M4; the main differences are memory and SSD capacity. More storage does not guarantee faster builds.
Use the temporary node only for a separate job queue. When finished, back up artifacts, essential logs, and configuration to storage you manage. Confirm no more jobs are being sent to the node before letting it stop at the end of its term. Treat a newly ordered node as a new instance; don't rely on it inheriting the old node's address, credentials, or local files.
Choose a daily rental to test things out, then move to a longer term for steady workloads. Confirm the configuration, node, and end date before paying.