Technical Q&A Before You Buy
No vague promises here. Verify hardware ownership, M4 configurations, available locations, four billing cycles, remote access requirements, data responsibilities, and support boundaries before deciding whether to rent.
Hardware Format
First, confirm whether the resources are dedicated and which development workloads they can support.
No. XcodeVM provides cloud Macs on dedicated physical hardware. The device resources belong exclusively to the current order; the processor, memory, and local storage are not divided among multiple tenants. You use macOS through a remote graphical interface or command line, while the device remains at the selected physical location.
This setup suits workloads that require dedicated hardware ownership, a stable build environment, or persistent project caches. The exact chip, memory, storage, location, and rental term are determined by the order confirmation.
Common use cases include iOS and macOS development, Xcode builds, GitLab Runner, React Native builds, Unity iOS builds, automation scripts, remote development, and MLX experiments. Both the macOS graphical interface and command line are available, supporting interactive development as well as continuous integration runners.
When choosing a configuration, prioritize peak memory usage, concurrent build volume, dependency cache size, and workload duration. Create separate application-level backups for code, signing materials, and business data that must be retained long term.
All four locations are designed to operate normally 365 days a year. Service status is recorded continuously, and actual availability is determined by the status records and instance associated with the order. If access is unavailable, first record the time, location, carrier, and error details, then submit a ticket through the support process.
Hardware Configurations
Only the two configurations listed in the catalog are available; no unlisted configurations are offered.
Suitable for single-project development, scripts, low-concurrency builds, and dependency caches of a manageable size. If builds regularly approach the memory limit, evaluate the higher configuration directly.
Choose XVM M4 CoreSuitable for parallel projects, larger dependency trees, higher-concurrency builds, and MLX experiments that need more memory headroom. For model inference, verify the model size and actual memory usage first.
Choose XVM M4 PlusStart by recording peak memory usage, cache size, and concurrency during one complete task in your local or existing build environment. XVM M4 Core may suit single-project, low-concurrency workloads; for multiple simultaneous builds or workloads approaching 16GB, evaluate XVM M4 Plus instead of treating swap space as a long-term capacity solution.
The currently available host configurations are M4 / 16GB / 256GB and M4 / 24GB / 512GB. If you need more capacity, you can select separately billed SSD expansion for the order; availability is determined by the console in real time.
Locations
Geographic distance is only a reference. Actual paths are also affected by carrier egress, cross-border routing, and congestion during peak periods.
Suitable for testing Southeast Asian network paths and as a connection candidate for distributed teams.
Suitable for workflows that require Japanese network paths or a Tokyo-based build location.
Suitable for teams in South Korea and nearby regions testing real carrier paths and remote-interaction performance.
Suitable for distributed development teams evaluating connection paths, code synchronization, and continuous-build routes.
Not necessarily. Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong may use different carrier interconnections and cross-border egress routes. From your actual office network, run multiple rounds of ping and traceroutewhile recording P50, P95, packet loss, and test times instead of looking only at a single minimum value.
Yes. XVM M4 Core and XVM M4 Plus are both available in Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Actual availability for each order is shown by the console in real time.
At minimum, record your local carrier, test city, target location, test time, number of consecutive samples, P50, P95, packet loss, and route hop count. If the remote display stutters, also record the resolution, client version, connection method, and whether the issue is consistently reproducible.
Pricing & Rental Terms
Hosts, expanded storage, and Thunderbolt 5 parallel connections are priced separately and billed according to the selected period.
| Plan | Daily | Weekly | Monthly | Quarterly |
|---|---|---|---|---|
| XVM M4 Core M4 / 16GB / 256GB |
$19.1 |
$51.7 |
$95.7 |
$260.3 |
| XVM M4 Plus M4 / 24GB / 512GB |
$39.5 |
$106.6 |
$197.4 |
$536.9 |
| Add-on | Daily | Weekly | Monthly | Quarterly |
|---|---|---|---|---|
| +1TB SSD | $2.7 |
$7.3 |
$13.5 |
$36.7 |
| +2TB SSD | $5.4 |
$14.6 |
$27 |
$73.4 |
| Thunderbolt 5 parallel connection Billed per device |
$1.5 |
$4.1 |
$7.6 |
$20.7 |
For short-term validation, temporary builds, and one-off experiments, start by considering daily or weekly billing. Ongoing development, dedicated runners, and long-term projects may suit monthly or quarterly billing. Compare the total cost against the expected workload duration, environment setup cost, and number of data migrations—not just the daily rate.
No. They are separate add-ons billed on the same daily, weekly, monthly, or quarterly schedule as the host. Before ordering, verify the host configuration, expanded capacity, number of parallel devices, and final order total.
Before submitting payment, use the configuration, location, period, add-ons, and total returned by the console as the final confirmation. If anything differs from your expectations, stop checkout and verify the details before continuing.
Payment & Checkout
All orders are settled in US dollars (USD). The available payment gateway is determined by the backend response.
Before paying, verify the chain type, recipient details, order amount, and order ID. After the on-chain transfer, retain the transaction ID in case the payment status needs to be checked.
Card payments are processed by Stripe. The checkout page displays the current order amount and available gateway. XcodeVM does not ask users to send complete payment credentials through support requests.
All plans, add-ons, and orders are displayed and settled in US dollars (USD). Before paying, verify the final USD amount shown on the payment page.
Do not pay again. First save the order ID, payment time, amount, and redacted transaction details, then log in tosubmit a ticket through the console. USDT-TRC20 payments may include the transaction ID; card payments may include the order-page status, but never submit the full card number or security code.
Remote Access
First verify the credentials and port, then determine whether the issue involves the client, session, or network path.
Confirm that the order ID, location, connection address, port, and initial credentials all belong to the same instance.
From the current network, check DNS, the target port, round-trip latency, and the routing path.
Adjust the resolution, color quality, and keyboard mapping based on client capabilities, then save the connection settings.
Keep the time of occurrence, carrier, location, error text, and redacted logs to support later diagnosis.
Prepare a stable network that can reach the target location, a supported remote client, and the connection details provided by the console. Verify the address and port before entering your credentials. After connecting successfully, update the initial credentials and store the connection details in a controlled credential manager.
Wait for the current client to release the old session, then reconnect to the same instance. If it continues to fail, check the local network, target port, DNS resolution, and routing changes in that order. Do not mask the issue by repeatedly creating new sessions; record the exact failure time and error text.
First lower the display resolution and color quality and disable unnecessary animation. Then run consecutive tests of latency, jitter, and packet loss on the same network. If the issue occurs only at certain times, record normal and abnormal samples separately and compare whether the carrier route changed.
See thesupport troubleshooting guide.
Uncontrolled shared credentials are not recommended. Assign access according to least privilege, record the scope and expiration of each authorization, and revoke access promptly when responsibilities change. Passwords, private keys, and signing materials should never appear in repositories, build logs, or support attachments.
Data Handling
Dedicated hardware does not automatically mean backups. Users remain responsible for establishing their own data lifecycle.
Create separate backups for code, build configurations, artifacts, and experiment data, and regularly validate the recovery process.
Restrict access to keys and signing materials. Do not store them in repositories, logs, cached packages, or support attachments.
Copy necessary data in advance, verify that it can be read at the destination, then clean up local working directories and temporary credentials.
Users are responsible for application-level backups. Keep source code in a controlled repository, place build configurations and critical scripts under version control, and copy non-rebuildable artifacts or experiment data to separate storage. Verify backups through recovery tests rather than merely confirming that files were copied.
Only place the data required to complete the task on the instance. For example, sync only the necessary repositories and dependencies to a build node, and provide only redacted logs in support requests—not complete databases, private keys, passwords, or payment credentials.
Confirm that code has been pushed, build artifacts transferred, backups are recoverable, keys have been rotated or revoked, and caches and temporary files have been cleared. Do not schedule the final migration shortly before the rental ends; allow time for verification and retries.
Support & SLA
Availability is not a subjective experience score. It must correspond to a specific instance, time range, and verifiable status record.
target availability
If a service interruption occurs, record the order ID, instance location, start and recovery times, error text, reproduction steps, and redacted logs. The status records, measurement window, scope, exclusions, claim deadline, and service credit method are governed by theTerms of Service.
99.9% is the target availability metric used to evaluate the accessible status of the service associated with an order during the applicable measurement window. The calculation method, status records, exclusions such as force majeure and user actions, and service credit conditions are governed by the Terms of Service.
Log in to submit a ticket through the console and provide the order ID, location, time of the issue, reproduction steps, expected result, actual result, and redacted logs. If the issue is network-related, also include the local carrier, test city, latency, packet loss, and routing results.
Email support@xcodevm.com. Include the account email, order ID, location, time of occurrence, and redacted error details. Do not send passwords, private keys, complete payment credentials, or unredacted business data.
Get Started
First compare the two M4 configurations, then choose the best location based on the actual network path. Before checkout, confirm the USD amount, rental period, and add-ons.