Connect first. Build next.

From your order to your first
xcodebuild

Your hands-on guide to working on a cloud Mac. In your first 10 minutes, you should be able to find your connection details, sign in over SSH, and check the environment. Dependency downloads and full builds take as long as your project requires.

Find your connection details

After setup, check these four details

Sign in to the portal and open the instance details for your order. Use the connection address, username, and port shown for that instance. Your order number is not your login username.

Example workstation details · Not real credentials

Desk M4

Mac mini M4 · 16GB memory · 256GB SSD

Public IP
View and copy it from the instance details
Login username
Use the username assigned in the portal
Initial password
View it in a private setting; never paste it into logs
SSH public key
Upload your public key in the portal

A dedicated physical Mac, all yours

Desk M4 is a cloud Mac on a dedicated physical machine, not a virtual machine. You can use both the macOS desktop and the command line. Check which node your order is on before you connect, so you don't put another workstation's address in your scripts.

For your first connection, start with SSH. It is a quick way to check the address, port, and authentication. Use the desktop for settings and Xcode configuration that require clicking around; it doesn't need to be your always-on entry point for builds.

  • Keep your private key on your own computer. Upload the public key, which starts with a type such as ssh-ed25519.
  • Never send initial passwords, private keys, or signing certificate passwords through ordinary logs.
  • If the instance details aren't available yet, check the order status in the portal. Don't guess the address or username.
Your first connection

Connect over SSH, then run a build

Replace the example IP and username below with the values shown in the portal. 203.0.113.24 is a documentation-only address and cannot connect to your workstation.

  1. 01

    Create a key

    Create a dedicated work key on your local machine and protect it with a passphrase. If you already have a suitable key, upload its public key without overwriting existing files.

    ssh-keygen -t ed25519 -f ~/.ssh/minivps_workstation
    cat ~/.ssh/minivps_workstation.pub
  2. 02

    Verify the fingerprint

    On your first connection, SSH displays the host key fingerprint. Compare it with one from a trusted source. If the portal doesn't show a fingerprint, confirm it through a support ticket. Don't accept it just because a prompt appears.

    ssh -i ~/.ssh/minivps_workstation dev@203.0.113.24
  3. 03

    Check the environment

    Run these commands remotely to check the architecture, developer tools path, and version. If your project needs a different Xcode version, align the versions before installing project dependencies.

    uname -m
    xcode-select -p
    xcodebuild -version
    sw_vers

Reading a complete session

This is an excerpt showing the format, not live output. Fingerprints, timings, and build logs vary by instance and project. A successful upload also requires your own signing assets and valid publishing credentials.

dev@desk-m4-tokyo
$ ssh -i ~/.ssh/minivps_workstation dev@203.0.113.24
The authenticity of host '203.0.113.24' can't be established.
ED25519 key fingerprint is SHA256:…
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Warning: Permanently added '203.0.113.24' to the list of known hosts.

$ cd ~/work/App
$ xcodebuild -scheme App -destination 'generic/platform=iOS' archive
…
** ARCHIVE SUCCEEDED **

$ bundle exec fastlane beta
…
Successfully uploaded the new binary to App Store Connect
Successfully finished processing the build

Enter yes only after verifying the fingerprint. If SSH reports that the host key has changed, first check whether the system was reinstalled or the instance replaced. Don't bypass the check by deleting your entire known_hosts file.

Identify the failing layer before changing configuration
MessageCheck firstNext step
Connection timed outIP, SSH port, local network, and firewallTry another local network. If it still fails, open a support ticket with the connection time and node.
Permission deniedUsername, uploaded public key, and selected private keyUse ssh -v to inspect authentication. Remove sensitive information before sharing logs.
Scheme not foundProject directory, workspace, and shared SchemeRun xcodebuild -list first. Projects using CocoaPods usually need a workspace specified.
Signing failedCertificate and private key, provisioning profile, and Keychain accessVerify signing in an interactive session before moving it into unattended CI.
When you need a desktop

Tunnel remote desktop traffic through SSH

Use SSH for commands and automation, and VNC for graphical settings and interactive work. Get SSH working first, then forward the screen-sharing port. Don't expose the VNC service directly to the public internet.

Check remote sharing settings

In System Settings, check that Screen Sharing is enabled and which users can access it. Grant access only to the users who need it. The settings location may vary between macOS versions.

A working tunnel won't show a desktop if the service is off or your account isn't authorised.

Set up local port forwarding

Keep the SSH session below running. This example forwards local port 15900 to remote port 5900 and listens only on the local loopback address.

If your instance uses a different SSH port, add -p and the port shown in the portal.

Connect to the local endpoint

Use Screen Sharing on a local Mac or a compatible VNC client on another system. Enter the local address and forwarded port, not the remote public IP.

You still need to authenticate with an authorised remote account.

ssh -N -L 127.0.0.1:15900:127.0.0.1:5900 \
  -o ExitOnForwardFailure=yes \
  -i ~/.ssh/minivps_workstation dev@203.0.113.24

Client address: vnc://127.0.0.1:15900. Ending the forwarding session closes this access path. Don't treat it as a permanent public service.

Reduce display load before troubleshooting the network

Start with a 1440 × 900 resolution and a single display. This is a client-side troubleshooting suggestion, not a plan limit. Turn off dynamic desktops and previews you don't need, and transfer files over SSH. More bandwidth doesn't necessarily mean lower input latency: round-trip time, packet loss, and your local Wi-Fi matter too.

If the command line responds normally but the desktop is slow, lower the client image quality or resolution. If SSH and the desktop both disconnect, note the time, local network type, and client message before opening a connection support ticket.

Let your workstation handle repetitive jobs

Run one job before adding it to your main pipeline

Register the workstation with your own CI project. Get the registration details from the relevant project or admin page. Never reuse someone else's token or commit a registration token to your repository.

GitHub Actions

In your repository or organisation's Runner settings, select macOS and ARM64. Download and configure the self-hosted Runner using the current installation commands shown on the page.

Add labels such as desk-m4 for its intended use. Run a diagnostic job interactively first, then register it as a background service for the current user as described in the installation instructions.

Use self-hosted, macOS, ARM64, and a custom use-case label to target the Runner.

GitLab Runner

After installing Runner, create one in your project or group and retrieve its authentication token. Choose an executor suited to the machine. For native macOS builds, shell executor is a good place to start.

Accept jobs only from trusted projects, and set macos-arm64 plus a use-case label. Explicitly configure whether it should accept untagged jobs.

Run gitlab-runner verify to verify registration, then review the first job log.

Jenkins Agent

Create a permanent node in your Jenkins controller and set its remote working directory, executor count, and labels. Connect over SSH or use the Agent launch command shown on the node page.

Check that the runtime user, Java version, and command-line environment are consistent. For the first job, print tool versions rather than using a release workflow to test connectivity.

Start with one executor, then adjust concurrency after checking peak memory and disk usage.

Use labels for capabilities, not temporary status

We recommend macos-arm64 for the architecture, ios-build for the job, and desk-m4 to identify this type of workstation. Add node or version labels only when you need to target a specific environment. Too many labels can leave jobs with no matching machine.

name: workstation-check
on: workflow_dispatch
jobs:
  check:
    runs-on: [self-hosted, macOS, ARM64, desk-m4]
    steps:
      - name: Check toolchain
        run: |
          uname -m
          xcodebuild -version
          df -h

A self-hosted Runner executes code from your repository. Don't let untrusted external contributions access a workstation with signing assets. Separate build and release permissions, inject secrets through CI secret variables, and restrict which branches can access them.

Bring your local workflow with you

Move data, toolchains, and CI in three steps

Don't copy your entire home directory. Migrate one project first and record its reproducible dependencies before switching CI labels. Each step can be checked and rolled back independently.

01 · Data

Sync the project, then import signing assets

Use rsync to sync your working directory from your local machine, excluding build outputs. Export certificates with their private keys to a password-protected file, and migrate provisioning profiles separately. After importing and verifying them, delete temporary transfer copies.

rsync -av \
  --exclude DerivedData \
  --exclude build \
  -e "ssh -i ~/.ssh/minivps_workstation" \
  ./App/ dev@203.0.113.24:~/work/App/

Check: Project files are in place, and the certificate and private key needed for signing are both available.

02 · Toolchain

Use a manifest to align dependencies

Export a Brewfile locally, review it on the remote machine, then install its packages. Set up the Xcode version your project requires and use xcodes to select an installed version. Then check Ruby, Bundler, and the project's lockfile.

brew bundle dump --file=Brewfile
brew bundle --file=Brewfile
xcodes installed
xcodes select
xcodebuild -version

Check: Developer tools match the project requirements, and dependencies can be installed again reliably.

03 · CI setup

Switch the runner label last

Keep your existing pipeline and add a manually triggered validation job. Confirm it can check out the project, sign the build, and upload the artefact before pointing the production job's runs-on or node label to the new workstation.

cd ~/work/App
bundle install
xcodebuild -list
bundle exec fastlane beta

Check: A full job completes, its artefact can be retrieved, and failures are traceable in the logs.

This is a migration sequence, not a promise about how long it will take. Installing dependencies, downloading SDKs, and working with a large project usually take longer than signing in over SSH. Start by validating a build without a release step.

Experiments beyond builds

Isolate the environment before downloading model weights

Desk M4 has 16GB of unified memory, shared by the system, desktop, and model. Quantisation, context length, and concurrency all affect whether a model will run. An extra SSD adds storage, not memory.

MLX: use a separate Python environment

Install MLX and your inference tools in a virtual environment instead of changing the system Python. First check that the module imports, then choose a compatible model and quantisation.

python3 -m venv ~/venvs/mlx
source ~/venvs/mlx/bin/activate
python -m pip install -U pip
python -m pip install mlx mlx-lm
python -c "import mlx.core as mx; print(mx.default_device())"

Start with a small model, short context, and one request. Check memory pressure before increasing the load.

llama.cpp: specify the model file

Install the tool with Homebrew, then launch it with a local GGUF file. Create the example path and add your model file first. Check the help output for the options supported by your installed version.

brew install llama.cpp
llama-cli --help
llama-cli \
  -m /Volumes/WorkSSD/models/model.gguf \
  -p "Hello" -n 64

The GGUF file must match your model architecture and chosen quantisation format.

Ollama: restrict access to localhost

After installation, bind the service to the local address and download weights as directed by their source. To call it from your own computer, use SSH port forwarding rather than exposing the inference API directly.

brew install ollama
OLLAMA_HOST=127.0.0.1:11434 \
OLLAMA_MODELS=/Volumes/WorkSSD/models/ollama \
ollama serve

Use models in line with their respective licences. Starting the service doesn't mean the weights are ready.

Keep model weights in one place

In the examples below, /Volumes/WorkSSD is a correctly mounted extra SSD, with models for weights and cache for regenerable caches. These are example paths; the system won't use this volume name automatically. Confirm the disk is mounted and writable before creating directories. Don't accidentally write large files to the system disk when the SSD isn't mounted.

diskutil info /Volumes/WorkSSD
test -d /Volumes/WorkSSD && test -w /Volumes/WorkSSD
mkdir -p /Volumes/WorkSSD/models /Volumes/WorkSSD/cache
export HF_HOME=/Volumes/WorkSSD/cache/huggingface
Identify the disk before writing to it

Add storage for capacity; linking machines won't pool memory

Available add-ons include +1TB SSD, +2TB SSD, and Thunderbolt 5 multi-machine linking. Disk names, device IDs, and link details depend on what your instance reports. Don't copy someone else's disk ID.

Identify the extra SSD

List the external physical disks first, then check the volume name, capacity, and available space. These commands only read information; they won't format a disk.

diskutil list external physical
ls /Volumes
df -h
diskutil info /Volumes/WorkSSD

After confirming the disk is mounted, move models, build caches, or projects to it. Stop build processes that write to the relevant directories first, and keep a separate backup.

Don't run eraseDisk or other erase commands blindly. If the disk isn't visible, send the read-only check results in a support ticket.

Know what multi-machine linking can do

Thunderbolt 5 multi-machine linking is for workflows with a clear need for communication or data transfer between machines. Each machine remains an independent host with its own system, jobs, and memory.

system_profiler SPThunderboltDataType
networksetup -listallhardwareports
ifconfig

Detecting an interface doesn't mean an application can run in a distributed setup. You'll need to configure the network, transfer protocol, and job allocation. Contact us before ordering to confirm the available connection options and combinations.

Linking machines won't automatically turn them into one Mac with more memory or guarantee faster builds.

Separate rebuildable caches from irreplaceable data

DerivedData and downloaded dependency caches can be regenerated. Uncommitted source changes, signing private keys, and experiment results can't be recovered from a cache. Manage these separately and back up anything irreplaceable first. Before renewing or reaching the end of your term, export any projects, artefacts, and settings you need to keep. Don't use your workstation disk as your only backup.

Give us the details we need

If you're stuck, send us these four things

For instance issues, sign in to the portal and open a support ticket so we can link it to your order. If you can't sign in, are choosing a plan, or need to add context, email us at support@macminivps.com.

  • Order number and node: tell us which workstation is affected. Don't send passwords or private keys.
  • Time and time zone: include when the issue first appeared and whether you can reproduce it consistently.
  • Original error excerpt: include the command, exit code, and relevant logs. Remove tokens, certificate contents, and personal information.
  • Checks you've tried: for example, switching local networks, checking the SSH port, or running a build on its own.

Response times

We don't quote an unverified average response time or fixed support hours here. Check the contact page and the replies to your ticket for the latest information. Add details to your existing ticket rather than opening duplicates; it makes the issue easier to track.

If the issue affects your connection, tell us whether SSH and VNC both fail. If it affects only builds, say whether the same command works in an interactive session. This helps us narrow it down to the network, authentication, environment, or project.

Know the steps?
Find a workstation for your project

Desk M4 is a dedicated physical Mac mini, not a virtual machine. Check your project's Xcode version, billing period, and storage needs, then configure your order. Availability is based on the latest information returned by the portal.

Payment is available only by USDT-TRC20 or Visa / Mastercard / Amex (via Stripe). All prices are in USD; available payment gateways are confirmed by the backend.