Each Mac mini is assigned to one user and is not a virtual machine. We keep the physical resources separate; you decide who can access your cloud workstation using keys, least-privilege permissions and separate backups.
This page explains isolation and operational boundaries. A dedicated machine is not an automatic backup, and disk encryption is not the same as access authorization.
Desk M4 is a dedicated physical Mac mini with an M4, 16 GB of memory and a 256 GB SSD. For the duration of your rental, its memory and storage are not assigned to other tenants. You get the full macOS graphical interface and command line, and manage your own projects, build cache and signing environment.
Resources are not divided among multiple users on the same machine, and builds for different tenants are not run in alternating time slices. Your own simulators, indexing and background processes still compete for resources, so check the machine’s load when troubleshooting.
A dedicated physical machine still has resource limits.
Xcode versions, dependencies, certificates and provisioning profiles are part of your working environment. Record versions before upgrading and include important settings in your own recovery checklist. Don’t keep your only copy of signing materials on the cloud workstation.
Rebuild the environment; keep copies of critical materials.
Physical isolation is not a network access policy. If you enable SSH, Screen Sharing or development services, check listening addresses, authentication and allowed sources. Expose only the services you need.
The machine is dedicated to you; that doesn’t mean every port should be open.
Your console account, macOS user and SSH private key are three different credentials. Don’t reuse your console password as your system password. Give each collaborator their own key, and remove their public key when access is revoked—never share one private key across the team.
Generate a key on your own computer and protect it with a passphrase. Upload only the public key file. Never upload the private key, which has no file extension, or put it in a code repository, chat or build artifact.
ssh-keygen -t ed25519Check the connection details in the console and add your public key to the target user’s authorized keys. Verify the host fingerprint on first connection. Keep your working session open, then use a second terminal to test key-based login before changing the authentication settings.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysCheck the SSH configuration entry point and included files for your macOS version, then set the authentication options below. Validate the syntax and apply the configuration using the service management method for your system. Test a new session and exit the old one only after the test succeeds.
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication nosudo /usr/sbin/sshd -tAfter receiving your instance, check the connection port provided in the console against the actual listening services in macOS. This page doesn’t present unverified provisioning details as fixed defaults. Your security baseline should be to keep essential management access and disable unused services. If source restrictions are available, limit access to trusted networks.
| Entry point | Recommended policy | What to verify |
|---|---|---|
| SSH | Keep only the remote login entry points you actually need, and prefer key-based authentication. | Connection port, authorized users, host fingerprint and connectivity from your local network. |
| VNC / Screen Sharing | Use an SSH tunnel; don’t expose it directly to the public internet. | Whether the service is enabled, its remote listening port, and whether direct access is restricted to what you need. |
| Development previews and debugging services | Prefer binding to localhost; close temporary access promptly. | Whether authentication is enabled, whether debugging endpoints are exposed, and whether environment variables or sensitive logs could be disclosed. |
| Other inbound connections | Don’t enable services without a clear purpose or open every port to troubleshoot. | Check the active host firewall and upstream rules; don’t check just one layer. |
This example applies only when the remote service listens on port 5900. Replace the username and IP with the actual values shown in the console. If the service uses a different port, update the command too. Then connect your local client to 127.0.0.1:15900.
ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 USER@HOSTThe tunnel encrypts traffic, but it doesn’t automatically close an existing public entry point. Check the remote access scope separately, and close the tunnel session when you’re done with the remote desktop.
At the end of your rental, the process covers the system disk and any assigned additional SSD. Erasure is not a backup or a substitute for extending your rental. Before expiry, export your projects, certificates, build artifacts and configuration copies to a location you control, then verify that the copies open correctly.
Use the expiry time shown in the console and plan your move in advance. Stop Runners and tasks that continue writing to disk, then export one final, consistent copy. If you need to keep using the machine, confirm your renewal in the console.
Don’t rely on access remaining available after expiry.
After service ends, the original user environment is handled through the cleanup process, including disk erasure and reinitialization. Any additional SSD is included. Deleting project folders alone does not complete device cleanup.
To confirm what’s included, contact us through a support ticket for your order.
Cleanup and environment initialization checks must be completed before the machine is reassigned. If your compliance process requires a specific erasure deadline or record, submit your order details first and confirm whether we can meet the requirement before moving sensitive materials onto the machine.
Confirm the specific timeline through the service terms and your order support ticket.
This page does not promise a data-retention grace period after expiry or recovery after erasure. Destruction, recovery and migration serve different purposes—confirm which one you need before proceeding.
Routine support is not intended to access your project code, signing certificates or business files. For hardware issues, connection problems, system changes you request or security incident response, we’ll clarify the scope of investigation and any potential impact. If access to your user environment is needed, confirm the authorized scope through an order support ticket.
| Scenario | Confirm first | How you can help |
|---|---|---|
| Can’t connect | Check instance status, network connectivity and the status of essential services; don’t assume a reinstall is needed. | Provide your order number, relevant error excerpts and reproduction steps. State whether a restart is permitted. |
| Troubleshooting within macOS | Confirm which logs, directories and account permissions are needed, and whether the task will interrupt your work. | Redact sensitive information from logs first. If temporary access is needed, limit permissions and revoke them when the work is done. |
| Reinstallation or disk operations | Confirm the target device, data impact, backup status and scope of the operation. | Explicitly authorize any destructive operation. “Please fix it” is not a substitute for clear authorization. |
| Anomaly or security incident | Identify affected entry points, access that needs to be restricted and any evidence that must be preserved. | Disable exposed credentials first, preserve essential logs, then agree on the next recovery steps. |
Never send SSH private keys, certificate private keys, Keychain passwords or recovery keys in support tickets or email. If you need help investigating an issue, share redacted information first. Support is available only through console tickets and support@macminivps.com.
Security isn’t a one-time checklist. Review these items when you first set up, add collaborators, upgrade your toolchain and end your rental. Verify your recovery path before tightening access, so you don’t lock yourself out.
Disk encryption protects data at rest, but remote services may need to be unlocked after a restart. First confirm how startup and unlocking work in your environment. Store the recovery key somewhere else under your control, then decide whether to enable encryption.
Back up only what you need and restrict access to the copy. Don’t store a Keychain backup and its password in the same project directory or build artifact. Test that the backup works.
Use password-protected export files, and check expiry, intended use and recovery requirements. A certificate file may not include a usable private key; verify the import and signing process in a controlled environment.
Give each Runner its own identity, with tokens limited to the required projects and actions. Avoid printing environment variables in logs. Revoke public keys and tokens when collaborators leave or tasks end.
Commit code to a repository you control, and back up large assets and build artifacts separately. Record Xcode versions, dependencies and build commands. Caches can be rebuilt; they can’t recover signing materials or uncommitted code.
After moving your data, deregister CI Runners, revoke temporary tokens and remove server-side authorizations you no longer need. Don’t just clear the local project directory while external systems still trust the workstation.
Need a dedicated physical Mac? Choose a workstation. For sensitive signing materials or team security requirements, confirm access, recovery and erasure scope through a support ticket first.