No noisy neighbors
Builds, simulators, and inference workloads use the resources of your assigned machine. Other tenants’ jobs won’t compete with yours for CPU, GPU, or unified memory on that Mac mini.
Dedicated hosts · Clear boundaries
One machine. One tenant.
XcodeOps Cloud Mac provides dedicated physical Mac mini hosts—not virtual machines sharing resources with other tenants. From system setup and connectivity to end-of-rental erasure, every step has clearly defined responsibilities.
Run MLX inference services and Xcode builds on the same machine. During your rental, your workloads have access to its CPU, GPU, unified memory, and local storage. You manage your own accounts, apps, and keys.
Host delivery seal
Dedicated hardware, separately managed credentials
Tenant isolationWhole machine
Remote accessSSH · Tunnels
End of rentalFull-disk erasure
01 / Resource boundaries
Isolation starts with the whole machine
Each rental gives you one dedicated physical Mac mini. There are no co-tenants on the same host, and its compute resources aren’t split among multiple users through virtualization.
Choose your host location
Choose the location that best fits your team’s network route: Singapore, Tokyo, Seoul, or Hong Kong. The console shows the current host list and availability when you place your order.
Choose your workloads
Set up development tools, build caches, or MLX models during your rental. A dedicated machine doesn’t secure your apps automatically—you’re still responsible for service bind addresses, dependency updates, and access permissions.
02 / Before delivery
A freshly prepared system, ready for you
Before delivery, the host’s system is reinstalled and verified, then prepared for initialization and credential delivery. Files from a previous rental should never carry over as the next tenant’s starting point.
Your connection credentials are delivered through the console after you sign in. When you receive them, save them right away in a managed password manager and configure SSH public keys according to your team’s access policies. Never put credentials in a code repository or ticket screenshot.
01Reinstall the system
Prepare a clean macOS environment for the next rental.
02Verify host readiness
Check the host and system initialization before providing connection details.
03Deliver credentials
Retrieve them from the console after signing in; they aren’t shown on public pages.
03 / Connections & services
Keep remote access in the right hands
A dedicated physical host isolates your resources from other tenants. Connections from your laptop to the host, and services exposed from the host to your team, still need access controls suited to their purpose.
Use keys wherever possible
Add a separate public key for each user instead of sharing a private key. Once key-based access works, disable password authentication according to your team’s policy. Revoke each person’s key promptly when they leave the project.
Tunnel desktop connections
For the macOS graphical interface, establish an SSH tunnel first, then connect your VNC client to the local forwarded port. Don’t expose remote desktop directly to an untrusted network for convenience.
Bind inference endpoints to localhost first
When deploying mlx_lm.server bind the service to the local loopback address first. Team members can connect through an SSH tunnel or a controlled proxy you configure. Verify the exposure scope and authentication method before going live.
Before connecting, check thateach user has their own key, remote desktop access goes through a tunnel, and inference services are exposed only to intended users. For specific commands and migration steps, see theconnection guide.
04 / End of rental
Export, release, then erase
Don’t rely on a rented host as your only backup. Before releasing it, export your code, model weights, certificates, and build artifacts. At the end of your rental, the host goes through full-disk erasure before being prepared for its next user.
- 01
Export the data you need
Check your repositories, model files, build artifacts, and configuration, and make sure they’re saved somewhere you control.
- 02
End your rental
Manage renewal or release in the console, and stop any jobs or services that depend on the host.
- 03
Erase the entire disk
After the host is reclaimed, its disk contents are erased before the next system preparation and delivery checks.
Erasure doesn’t replace your own backups or key rotation. Before your rental ends, revoke any access permissions you no longer need.
05 / Facility & network
Separate controls for facility and internet access
Our four hosts are located in data centers with physical access controls and redundant power, serving connections to Singapore, Tokyo, Seoul, and Hong Kong. Each delivered machine gets its own public IP address. This gives you a clear point of entry for remote access—and means you should review which ports are exposed to the internet.
When choosing a host, consider your team’s network route to the data center first, then how you’ll transfer large files such as model weights and build caches. The data center manages the physical environment; you configure public-facing services, including their bind addresses, authentication, and application logs.
Four Asia-Pacific locations
- SGSingaporeSoutheast Asia
- JPTokyoEast Asia
- KRSeoulNortheast Asia
- HKHong KongSouthern China & Southeast Asia
Network routes vary by carrier and time of day. Before choosing a host, check the latency table in theconnection guideand compare it with results from your own network tests.
06 / Shared responsibility
What we handle—and what you configure
Physical isolation doesn’t manage application permissions for you. Use this checklist to clarify responsibilities before launching an MLX endpoint or CI runner.
| Area | XcodeOps Cloud Mac handles | You handle |
|---|---|---|
| Hardware & facility | Physical Mac mini, data center facilities, and host delivery | Choosing a host that fits your team’s network route |
| System delivery | Reinstallation, verification, and initial credential delivery before handoff | Retrieving and securely storing credentials, and managing subsequent system configuration |
| Remote access | Providing the host and connection details | SSH keys, user permissions, VNC tunnels, and open ports |
| Apps & data | Full-disk erasure after the rental ends | App updates, model weights, build artifacts, backups, and data export |
| Service keys | Providing account and support ticket access | Storing and rotating app tokens, signing materials, and other keys |
07 / Security contact
Report a security issue with enough detail to reproduce it
If you find a security issue that could affect an account, host delivery, or service endpoint, email us at support@xcodeops.com. Signed-in users can also open a ticket from theconsole. For issues involving a current order or host, a ticket makes it easier to include the relevant context.
Include the affected page or feature, steps to reproduce, expected and actual results, and screenshots or error details you can safely share. Don’t email private keys, full credentials, model weights, or anyone else’s personal data.
How responsible disclosure works
- 01
Send the minimum information needed to reproduce the issue by email or through a ticket after signing in.
- 02
We’ll assess the impact and follow up through the same channel with updates or requests for more information.
- 03
Please don’t disclose details that could be used to exploit the issue until it’s resolved and both parties agree it’s appropriate to share them.
We’ll send our initial response by email or ticket confirmation. For an urgent issue with a host in use, include the order number and host details in your ticket so we can identify it.
Start with clear boundaries
Choose a dedicated Mac for your next build or inference workload
Choose your model, location, and access method before ordering. Availability is shown in real time in the console.