Get answers before you order

Each rental provides one physical Mac mini assigned to a single tenant—not a virtual machine carved out of a shared host. The machine’s CPU, GPU, and unified memory are available to your workloads. It’s a good fit for MLX model serving that needs consistent access to unified memory, and for CI pipelines where you don’t want builds competing with other tenants for resources.

That doesn’t mean every workload will run at the same speed: model size, quantization, build cache, and network conditions all affect performance. When choosing a model, estimate memory needs based on its weights and peak usage, then check the actual specs for the three Mac mini models.

No. Once delivered, the Mac mini’s local CPU, GPU, unified memory, and selected storage are for the current tenant’s use. The data center network is shared infrastructure; that doesn’t mean the machine’s computing resources are shared. If you’re running builds alongside a continuously available inference endpoint, reserve enough memory for both processes rather than allocating the entire unified memory budget to model weights.

You can install development tools, package managers, and runtime dependencies that comply with their license terms in the supplied macOS environment, including Xcode Command Line Tools, Homebrew, Python environments, and MLX software. Before changing remote login, network proxy, or service startup settings, note how to roll them back. In particular, don’t disable your existing access method until you’ve confirmed key-based login works.

Choose a model, then select a prepaid billing period. Each of the four periods has its own listed price, so don’t calculate weekly or monthly pricing by multiplying the daily rate. For example, XOps 16 costs $19.4/day, $52.3/week, $96.8/month, or $263.3/quarter. Storage upgrades and Thunderbolt 5 clustering are charged separately for the selected period. Review the full breakdown before placing your order.

For a short-term model test, consider daily rental. If you need an inference endpoint to stay available, compare the weekly, monthly, and quarterly rates. Thefull pricing and add-onspage lists all four billing periods for each of the three configurations.

We accept USDT-TRC20 and Visa, Mastercard, and Amex processed through Stripe. All listed prices and charges are in US dollars (USD). The payment gateways available at checkout are confirmed by the console in real time. Before paying, make sure the network, amount, and order details are correct.

Check your order’s expiry date in the console and renew before it expires. Don’t assume the rental period will extend automatically just because a task is still running. Machines that aren’t renewed by expiry are released according to the order terms. After release, local files, model weights, and build caches are no longer available as online data. Export anything you need and verify the copy before expiry. If you have questions about your order status,sign in to the console and submit a support ticket.

Before ordering, check the configuration breakdown for add-ons, billing period, and total in USD. After ordering, view your order and billing records in the console. Before changing or stopping an add-on, check which actions are available for your order. Deleting files from the disk does not cancel an add-on. For payment-related support tickets, include your order number and transaction ID—never send full card details or private keys.

Choose from Singapore, Tokyo, Seoul, and Hong Kong. All three models—XOps 16, XOps 24, and XOps Pro 64—are listed in all four locations. Actual availability at checkout is confirmed by the console in real time. When choosing a location, consider not only where your team is, but also the network paths used to upload model weights, sync code repositories, and access remote desktops.

Test from the places where people will call the inference API or use the remote desktop, rather than relying on map distance alone. Measure round-trip latency to each location you’re considering, then test an upload using the same file size. If CI builds are your main workload, compare the network paths for fetching code and dependencies too. Start with thelocation latency table in the connection guide, then retest from your own network.

The guide’s table shows the average of 100 ICMP tests over home broadband during weekday evening peak hours. It’s for an initial comparison only—not a guarantee of SSH response times, VNC frame rates, or large-file transfer speeds. ISP routing, packet loss, file size, and client settings all affect performance. If you plan to use a remote desktop long term, test it from your own network.

16 GB is a good starting point for small quantized models and individual experiments. 24 GB can suit always-on serving for commonly used 7B–8B models quantized to 4-bit. 64 GB is better for larger models, running multiple models in parallel, or keeping build workloads on the machine at the same time. These are planning guidelines, not a promise that a model of a given parameter count will fit.

Include model weights, KV cache, context length, concurrent requests, and macOS itself in your estimate, and leave some headroom. Being able to load a model doesn’t mean you’ll meet your throughput target. Before choosing a model, stress-test it with real requests on the configuration you’re considering.

Yes. You can install and run both, but their model weights, caches, and concurrent requests all use the same machine resources. First check peak usage for each service on its own, then test them together. If you run into memory pressure or noticeably slower responses, reduce concurrency, stagger startup, or choose a higher-memory model. Changing the listening port alone won’t help.

When you use mlx_lm.server to start an OpenAI-compatible endpoint, configure it to listen only on the local loopback address, then use an SSH tunnel to connect approved clients on your team. If you need access through a reverse proxy, configure authentication, encryption in transit, and access controls separately. Never expose an unprotected inference port directly to the public internet.

Quick-start MLX deployment guidecovers the steps for installation, startup, and connection. Before going live, test memory use and throughput with your team’s actual models and request volumes.

You can install and keep multiple versions as needed, subject to available storage, compatibility with the installed macOS version, and software license terms. Before automation starts, specify the required version and record the path used by the command-line tools. This helps prevent a runner from using the previous job’s toolchain when building a different branch. When moving signing assets, use only export and import procedures approved by your team.

First, use SSH to confirm that your code repository, Xcode, and build dependencies are ready. Then add the machine to your team using your CI platform’s runner registration process. Give the runner its own working directory and only the permissions it needs, and set clear limits for cache cleanup and concurrent jobs. For the first pipeline run, check the environment only. Once the toolchain and signing setup are verified, add your production archiving tasks.

For the full environment migration and CI setup sequence, see thegetting started guide.

A cloud Mac can run Xcode simulators, automated builds and tests, and prepare build artifacts for distribution. It is not a substitute for a physical iOS device. Scenarios that depend on hardware—such as cameras, Bluetooth, sensors, or cellular networks—still need to be tested by your team on physical devices. You can run simulator regression tests in CI and reserve hardware checks for your device testing workflow.

Once released, the machine’s entire disk is erased before it is prepared for future delivery. Don’t rely on a released machine as the only copy of model weights, project files, keys, or build artifacts. Before release, export the data you need to a location you control and verify that the archive can be opened. Starting a sync is not the same as completing a backup.

While your rental is active, you can use SSH and a transfer method suited to your file sizes to export data you manage. For large files, check available storage and the destination path first, then sync in batches and verify the results. Build caches can usually be recreated, so prioritize project files, configuration, and model weights that can’t be regenerated. For the specific rsync migration sequence, see theconnection and migration guide.

Use a unique, strong password for the console. For machine access, use SSH keys where possible, and restrict where private keys are stored and who can access them. Connect to the VNC remote desktop through an SSH tunnel; don’t expose its service port directly. When team membership changes, review existing access permissions, runner credentials, and deployment keys. If you notice signs of unusual access,sign in to the console and submit a support ticket.