Dedicated physical Mac · Quickstart

From your first SSH login
to a live inference endpoint

Connect to your machine, move your projects and models, then keep your service running on the node. The commands in this guide are for a delivered Mac mini. Find the correct public IP, username, and credentials in your console instance details.

Rent a cloud Mac Open console

Already placed an order? Check the console to confirm your instance is ready, then follow the steps below.

Connection checklistSSH → MLX

XCODEOPS / RUNBOOK

Establish a trusted connection
before exposing a service.

01Get credentialsCheck the node and public IP in the console
02Set up a tunnelUse SSH for terminal and remote desktop access
03Start the endpointMLX listens on localhost by default
Access path plannedPhysical node · Single tenant

Jump to a task

New to the service? Start with Connect, Migrate, and MLX. If your environment is already up and running, go straight to Network or Troubleshooting.

01 / Get connected

Connect to your dedicated physical Mac over SSH

Get connection details from the instance page in your console. Never put initial credentials in a repository, CI logs, or team chat. Verify key-based login first, then tighten your SSH settings.

01

Check your instance

Sign in to the console, open your delivered instance, and note its location, public IP, SSH port, and login username. Confirm the instance status before connecting; availability shown in the console is the source of truth.

02

Add your public key

Generate a dedicated key locally and add the public key through the console's key management page or to the instance account's authorized keys. Upload the public key only; keep the private key on your own device.

03

Verify, then harden

Confirm that key-based login works from a second terminal before disabling password authentication over SSH, in line with your team's policy. Keep your current session open while making changes, and check the config syntax so you don't lock yourself out.

Local connection setup

After generating a key, upload the contents of the .pub file. The example address below is reserved for documentation; replace it with the IP, port, and username shown in your console before use.

ssh-keygen -t ed25519 -f ~/.ssh/xops_node

cat ~/.ssh/xops_node.pub

~/.ssh/config

Host xops-node
  HostName 192.0.2.10
  User mac-user
  Port 22
  IdentityFile ~/.ssh/xops_node
  IdentitiesOnly yes

Save the file, run chmod 600 ~/.ssh/config, then connect with ssh xops-node. On your first connection, verify the host fingerprint. If you can't connect, check the IP, port, key permissions, and instance status.

02 / Remote desktop

Use an SSH tunnel for remote desktop—never expose VNC directly

To use the Xcode GUI or inspect build output, first make sure Screen Sharing is enabled on the instance, then forward remote port 5900 to your local machine. The tunnel closes when the SSH session ends.

Run in your local terminal 
ssh -N -L 5901:127.0.0.1:5900 xops-node

Leave this terminal open. On your local Mac, connect to vnc://127.0.0.1:5901 using Screen Sharing or a compatible VNC client. Check GUI login permissions and SSH permissions separately; don't assume they use the same credentials.

Before you start

  • Use the built-in Screen Sharing app where possible. Other clients must support your chosen connection and authentication methods.
  • If the display is sluggish, lower the remote resolution and color depth first, then check the connection between your device and the node. Don't expose a public VNC port to improve performance.
  • Clipboard sync depends on both the client and the remote session. For model weights, certificates, or large projects, use a file transfer tool such as rsync.
  • When you're done on a shared computer, disconnect the remote desktop, close the SSH tunnel, and remove any sensitive files left on the local machine.
03 / Move your environment

Move from your local Mac to the cloud in three stages

Sync project files that can be recreated first, restore your toolchain next, and connect CI last. Model weights, signing assets, and build caches each need different handling. Don't copy your entire local home directory without checking what's in it.

01 / DATA

Data and models

Use rsync to sync projects and model weights incrementally. Run a test transfer first, then check the destination, file permissions, and available storage. An external drive image is suitable for offline migration only after verifying its format and capacity.

rsync -avh --progress ./project/ \
  xops-node:~/work/project/

Transfer large weights in batches; compare file sizes and checksums when done. Keep private keys and temporary tokens out of your project directory.

Estimated time15–60+ minDepends on data size and upload speed
02 / TOOLCHAIN

Toolchain and signing

Export a Brewfile with Homebrew Bundle on your local machine, then import it on the node. Check the Xcode version, command line tools, and dependency lockfiles. Transfer signing certificates separately, and restrict Keychain access after importing them.

brew bundle dump --file=./Brewfile
rsync -av ./Brewfile xops-node:~/work/
ssh xops-node 'brew bundle --file=~/work/Brewfile'

Don't copy your local Python virtual environment. Reinstall dependencies on the destination machine.

Estimated time20–45+ minDepends on packages and download speeds
03 / CI

Connect your CI pipeline

Register a self-hosted runner in your existing CI project and assign it to a specific repository or team. Keep build caches in a separate directory, and set concurrency based on available memory and build load.

  • Run a test build without release credentials first.
  • Document cache paths, disk usage, and cleanup policies.
  • Make sure the runner runs under a dedicated account.
Estimated time15–30+ minExcludes the first full build

These are planning estimates for migration tasks, not instance delivery times. Check available disk space before your first sync. If you need more capacity, review the options under Models and add-ons.

04 / MLX inference

Run your inference endpoint locally before sharing it with your team

Apple Silicon's unified memory is shared by the CPU and GPU. Whether a model fits also depends on its quantization format, context length, and other processes. Leave headroom for the system and services when choosing a model—don't treat all installed memory as space for weights.

Install, start, and verify

Create a dedicated Python environment for your service on the instance. The model path below points to a local directory already synced to that instance. After starting the service, verify its OpenAI-compatible API from the instance itself.

python3 -m venv ~/mlx-service/.venv
~/mlx-service/.venv/bin/python -m pip install mlx-lm

~/mlx-service/.venv/bin/python -m mlx_lm.server \
  --model ~/models/quantized-model \
  --host 127.0.0.1 --port 8080
curl http://127.0.0.1:8080/v1/models

Check that the model files are complete, the Python environment works, and the port isn't already in use. Options may change between mlx-lm versions, so check the command help for the version installed on your instance before deploying.

ACCESS / 01

Give your team access

By default, the service listens on 127.0.0.1 only. For a small number of internal users, each team member can create an SSH tunnel. For a shared entry point, use a reverse proxy with authentication, access controls, and TLS. Don't expose an unprotected inference endpoint to the public internet.

ssh -N -L 8080:127.0.0.1:8080 xops-node
STARTUP / 02

Keep it running after restart

Once the foreground command is stable, create a user-level launchd configuration for the service. Set the Python executable in the virtual environment, model path, working directory, and log file. Check the config before loading it into the current user session, then verify the process and endpoint after restarting the instance.

plutil -lint ~/Library/LaunchAgents/com.xcodeops.mlx.plist
launchctl bootstrap gui/$(id -u) \
  ~/Library/LaunchAgents/com.xcodeops.mlx.plist

Memory guide: 16GB is suitable for experiments with small quantized models; 24GB can support single-service testing with common 7B–8B quantized models; 64GB leaves room for larger models or multiple tasks. Actual throughput depends on the model, context, and workload—benchmark with your own requests.

05 / Development and delivery

Build with Xcode on the node; keep device testing in your controlled workflow

A dedicated physical machine works well for Xcode builds, simulator testing, and self-hosted runners. Its CPU, GPU, and unified memory aren't shared with other tenants. But a passing simulator test doesn't guarantee that camera, Bluetooth, or performance tests will pass on a physical device.

Simulator matrix

Pin your Xcode and simulator runtime versions, then build a test matrix for key device sizes and OS versions. Run xcrun simctl list devices available to check which devices are installed and available, so your pipeline doesn't reference a missing runtime.

Check: versions / devices / test reports

Archive and distribute

First, make sure the runner can produce consistent test and archive results. Then upload your TestFlight build using your team's existing signing workflow. Store certificates, provisioning profiles, and upload credentials securely—never in a repository or persistent build logs.

Check: signing / archive / upload result

Physical device testing

Test cases involving sensors, real network changes, power consumption, or accessories still need to be verified on physical devices controlled by your team. Use the cloud node for builds and distribution, then run final regression tests and reproduce issues on local devices.

Check: device logs / reproduction steps
06 / Locations and connectivity

Test all four locations before choosing where to run your workloads

Our locations include Singapore, Tokyo, Seoul, and Hong Kong. Your team's location, ISP routing, and evening congestion all affect the experience. For inference APIs, measure both request round-trip time and model generation time—not just ping.

Asia-Pacific latency samples

Values below are in milliseconds and represent a reference sample measured using a specific methodology. They aren't a real-time guarantee for any connection. Repeat the tests on your own network before choosing a location.

Reference ICMP average round-trip latency in milliseconds from eight origin cities to locations in Singapore, Tokyo, Seoul, and Hong Kong
Origin citySingaporeTokyoSeoulHong Kong
Shanghai76 ms58 ms53 ms41 ms
Shenzhen62 ms72 ms65 ms29 ms
Taipei64 ms46 ms54 ms39 ms
Bangkok43 ms109 ms98 ms66 ms
Jakarta38 ms109 ms115 ms74 ms
Sydney101 ms132 ms146 ms141 ms
Osaka75 ms32 ms47 ms65 ms
Busan85 ms44 ms24 ms71 ms

Method: average ICMP round-trip time, 100 consecutive tests per route, during weekday evening peak hours over a residential broadband connection. Use these figures only as a starting point for choosing a location. Results vary by ISP and route; test the actual instance from your workplace for a more accurate picture.

01 / LOCATION

Test from where your team works

Start by running repeated pings to the actual instance, then check packet loss and jitter. If your team is spread across multiple locations, prioritize members who use remote desktop or call the inference API most often—not just the geographically nearest city.

02 / TRANSFER

Schedule large transfers off-peak

Model weights, media assets, and build caches are good candidates for incremental sync. Schedule large transfers outside busy hours and resume them if interrupted. If interactive VNC is sluggish, check whether a background transfer is using all your upstream bandwidth.

03 / SCALE

Consider multiple machines for parallel workloads

Thunderbolt 5 clustering is suited to workloads that genuinely benefit from multiple physical machines and software that can use them. It won't automatically combine the unified memory of separate machines into one pool for a model. Check your software architecture before configuring a multi-machine setup.

07 / Troubleshooting and support

A clear reproduction is more useful than “I can't connect”

Submit a support ticket from the console for instance or order issues. Before you do, check your local network, instance status, connection method, and when the issue started. Don't include private keys, full tokens, or unredacted sensitive data in screenshots or logs.

Four details to include

  • 01Order and locationOrder number, the instance location—Singapore, Tokyo, Seoul, or Hong Kong—and the affected service.
  • 02Steps and errorThe command you ran, the full error message, the steps that led to the issue, and a redacted screenshot if available.
  • 03Timing and scopeWhen it first happened, whether it is still happening, and whether it affects only one team member.
  • 04Checks already doneWhat you've checked for the instance status, key permissions, port, tunnel, and local network.

What to do next

Sign in to the console and submit a ticket from the relevant order or instance, including your troubleshooting notes. For questions about choosing a setup before ordering, email support@xcodeops.com. For issues with an existing instance, use a support ticket so we can link it to the right order and location.

Sign in to submit a ticket Browse FAQs
Ready to deploy?

Choose a location and run your first command

Choose from three tiers of dedicated physical Mac mini, with daily, weekly, monthly, and quarterly billing. Pick your model first, then choose a location based on your own network tests. Start here for the connection steps once your instance is ready.

Rent a Mac mini Compare models and pricing