From Node Selection to Your First Workload

Deploy Your First MLX or CI Workload on a Cloud Mac

This guide is for developers and engineering teams preparing to rent a VMMini M4. You’ll define your workload, compare four available nodes, create an order, connect for the first time, then launch an MLX inference service or self-hosted runner.

VMMini M4 is a dedicated physical node with a Mac Mini M4, 16GB RAM, and a 256GB SSD—not a virtual machine. Nodes run continuously 365 days a year. Actual network performance, order availability, and delivery details are based on live console information.

Rent VMMini M4 Now Review Plans and Pricing

1fixed configuration

4available nodes

2first-workload paths

Deployment Runbook VMMini M4

available to order

Processor: M4
Memory: 16GB
System drive: 256GB SSD
Nodes: Singapore, Tokyo, Seoul, Hong Kong

Workload Outcomes

MLXHealth check passed

CIRunner online and accepting jobs

Before You Start

Prepare These Seven Inputs Before Creating an Order

Your node, rental term, and storage directly affect how you’ll work after delivery. Prepare a short workload card first to avoid discovering after connection that your code source is too far away, the disk is too small, or your team lacks an available public key.

Define the Use Case

Decide whether the first workload is MLX inference, Mac AI deployment, iOS/macOS builds, or remote automation. Record the runtime, concurrency model, and final artifacts.

Map Your Team’s Locations

List the regions where the primary operators are located. For distributed teams, consider not only the administrator’s location but also where members review logs and retrieve artifacts.

Confirm the Code Source Location

Record the network locations of your code repository, model files, dependency cache, and artifact storage. Where workload data enters from often matters more than where the team is based.

Choose a Rental Term

Use daily billing for short validation, weekly billing for focused sprints, and monthly or quarterly billing for stable builds or long-running services. Cover the full period for deployment, validation, and data export.

Estimate Storage Capacity

Account for model weights, dependency caches, build directories, archived artifacts, and logs together. Do not estimate system-drive needs from repository size alone.

Prepare an SSH Public Key

Use a dedicated key for this workload and ensure the private key is held by authorized personnel. Submit the public key only; never send a private key by email or in a support request.

Confirm the Notification Email

Use a work email that can continuously receive order and service notifications, and ensure the delivery owner can access it. Update internal contacts before handing over the workload.

Step 1 · Choose a Node

Choose by workload data path, not by guessing from the city name

VMMini M4 is currently available in Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. All four catalog combinations can be ordered; actual availability is shown live in the console.

SG Available

Singapore

Best for workloads whose code source, team, or service users are in Southeast Asia. Before pulling large models or dependencies across regions, test the actual download path instead of relying on ping alone.

Prioritize: Southeast Asia access routes
Validate: Model downloads, API origin access, artifact uploads

JP Available

Japan (Tokyo)

Best for build workloads whose dependencies and collaborators are in Japan or East Asia. If the pipeline downloads dependencies frequently, measure both time to first byte and sustained throughput.

Prioritize: East Asia code sources and artifact repositories
Validate: Repository cloning, cache restoration, log viewing

KR Available

South Korea (Seoul)

Best for workloads with teams or delivery paths in South Korea and Northeast Asia. If build artifacts must be uploaded continuously, include a real file-transfer test.

Prioritize: Northeast Asia team access
Validate: Remote operations, artifact uploads, service health checks

HK Available

Hong Kong

Best for workloads whose primary operators, code source, or business path is in South China or Southeast Asia. Cross-border access can still vary with local carriers and routing.

Prioritize: South China and Southeast Asia routes
Validate: SSH round trips, code synchronization, artifact downloads

Interactive WorkloadsFocus on SSH input response, log refreshes, and small-file transfers.

Build WorkloadsFocus on repository cloning, dependency downloads, cache restoration, and artifact uploads.

Inference ServicesFocus on model preparation, the real client-to-server request path, and sustained stability.

Node Latency Reference

Use medians for initial screening, then retest on your own network path

The table records ICMP round-trip times from test locations in major cities to the four available nodes. Use it to rule out clearly unsuitable paths, but do not treat it as a substitute for testing repositories, model sources, artifact stores, or end-user routes.

Test windowWeekdays 10:00–12:00 (UTC+8)

Network providerTypical local business broadband

Sample count30 per path

StatisticMedian of valid samples

Median ping from test locations in major cities to the Singapore, Tokyo, Seoul, and Hong Kong nodes
Test location	Singapore node	Tokyo node	Seoul node	Hong Kong node
Shanghai test location	79 ms	48 ms	52 ms	36 ms
Shenzhen test location	47 ms	66 ms	61 ms	24 ms
Taipei test location	58 ms	39 ms	45 ms	31 ms
Bangkok test location	33 ms	92 ms	99 ms	56 ms

How to Retest

Run multiple rounds of ping from the networks your team uses, repeating them during expected working hours. Then clone a repository of realistic size, download dependencies or a model file, and upload a representative artifact.

How to Read the Results

A low median does not guarantee sustained stability. Also check packet loss, variability, download throughput, and peak-hour changes. The table is for initial node selection only and does not guarantee ongoing performance.

Step 2 · Create an Order

Fixed configuration: choose the node and term first, then add extras

There is currently one VMMini M4 configuration. Your order must specify the physical node, rental term, and add-ons. Do not wait until submission to estimate storage or the number of interconnected devices.

Only Configuration Available

VMMini M4

Mac Mini M4 · 16GB RAM · 256GB SSD

Create a VMMini M4 Order

Daily $20.5 Best for short validation and one-off workloads

Weekly $55.4 Best for release sprints and concentrated builds

Monthly $102.6 Best for stable pipelines and ongoing experiments

Quarterly $279.1 Best for continuous projects and a fixed execution environment

Choose a Node

Choose only from Singapore, Tokyo, Seoul, and Hong Kong, and record the rationale.

Choose a Term

Create a daily, weekly, monthly, or quarterly order. Include time for deployment and data export.

Choose Add-ons

Check quantities against your model, cache, artifact, and device-interconnection requirements.

Add-ons Follow the Same Rental Term

Storage expansion and Thunderbolt 5 interconnection are not part of the base configuration. Add them only when the workload requires them, and include the price for the matching term in your budget.

+1TB SSDStorage expansion

Day: $2.4
Week: $6.4
Month: $11.8
Quarter: $32.1

+2TB SSDStorage expansion

Day: $4.8
Week: $12.8
Month: $23.6
Quarter: $64.2

Thunderbolt 5 interconnectionPer device

Day: $1.3
Week: $3.4
Month: $6.3
Quarter: $17.1

Step 3 · Complete Checkout

Check the USD total and the two available payment methods

Orders and checkout are processed in USD. Before paying, verify the base term, node, SSD expansion, and Thunderbolt 5 device count, and confirm that the total matches your workload card.

USDT-TRC20

Transfer funds using the details shown for the order, and verify the network, amount, and order status.

Visa / Mastercard / Amex

Card payments are processed by Stripe. The available gateway is determined by the console.

Step 4 · Connect for the First Time

Verify delivery details before installing your toolchain

The goal of the first connection is not to start running workloads immediately, but to establish a trusted baseline. Verify the host fingerprint, system information, disk, time, network, and account permissions before changing the environment.

01
Verify the Host Fingerprint
Compare the fingerprint shown at connection time character by character with the delivery record. If they do not match, stop connecting and submit a support request through the console.
02
Use SSH or VNC
Use SSH for command-line workloads; use VNC when you need to observe the macOS graphical interface. Open only the access points required by the workload.
03
Check the System and Disk
Record the macOS version, kernel architecture, system-drive capacity, and available space as a baseline for troubleshooting.
04
Check Time and Network
Verify the time zone, system time, DNS, access to external dependencies, and code-source connectivity to prevent certificate or build-timestamp issues.
05
Check Account Permissions
Verify that the current account has only the permissions required for the workload, and manage project credentials separately from personal login credentials.

First Connection Checklist READ ONLY FIRST

sw_vers
uname -m
df -h /
date
scutil --get TimeZone
networkQuality
whoami
id

Expected architecture arm64 Recording method Save redacted output

Step 5 · Run Your Workload

Start with a Small, Verifiable Workload

Do not run the full production workflow the first time. Start with a minimal model request or a single build to verify the environment, logs, exit code, and artifact path, then expand the workload gradually.

Path A

MLX Inference Service Health Check

Confirm the Python environment and model directory first, then have the service listen only on the local address. After the health check passes, open the required ports based on the real callers and access policy.

export MODEL_PATH="/srv/models/current"
export SERVICE_PORT="8080"

python -m mlx_lm.server \
  --model "$MODEL_PATH" \
  --host 127.0.0.1 \
  --port "$SERVICE_PORT"

curl --fail \
  "http://127.0.0.1:${SERVICE_PORT}/v1/models"

Record the model version, dependency lockfile, and startup parameters.
Confirm that the health check returns a successful status and the expected model identifier.
Store the access token in an environment variable or controlled secret store.
Save startup logs, error logs, and observed resource peaks.

Path B

Register a self-hosted runner

Create a restricted runner for a single project and configure it with a short-lived registration token. Run a minimal build without signing or release actions first, then connect it to the production pipeline.

export REPOSITORY_URL="$CI_REPOSITORY_URL"
export RUNNER_TOKEN="$CI_RUNNER_TOKEN"

./config.sh \
  --url "$REPOSITORY_URL" \
  --token "$RUNNER_TOKEN" \
  --name "vmmini-m4-runner"

./run.sh

Use separate working directories and credential scopes for different projects.
Print tool versions before the build, without exposing any token contents.
Isolate caches by project key and check for contamination after failures.
Remove the runner and clean up residual credentials when the workload ends.

0unexplained errors

The first workload should have a clear exit code and actionable logs.

1reproducible record

Save dependency versions, commands, configuration, and artifact paths.

2credential boundaries

Manage personal access and project automation credentials separately.

Post-Deployment Checks

A Successful Run Does Not Mean Deployment Is Complete

After completing these six checks, your team will have a recoverable, diagnosable, and cleanly terminable environment. Record an owner, result, and next-check condition for each item.

Verify Restart Recovery

Confirm that the service, runner, or scheduler script recovers as expected, and document any steps requiring manual intervention.

Organize Workload Logs

Separate runtime logs, error logs, and audit records; redact sensitive data and set capacity and retention policies.

Test Artifact Export

Actually download or upload a representative artifact, verifying its checksum, permissions, destination, and transfer time.

Set Up Monitoring and Alerts

At minimum, cover service health, task failures, available disk space, and critical process status, and verify that notifications reach the responsible owner.

Document the Data Cleanup Plan

List the code, models, caches, logs, artifact copies, and temporary credentials that must be deleted when the workload ends.

Save the Order ID

Include the order ID, node, incident time, reproduction steps, and redacted logs in the minimum information set for a support request.

Handoff Standard Another engineer should be able to connect, reproduce, export, and safely end the workload using only the run records.

View Support Documentation

Ready to Create Your First Order

Bring your workload card to the console and choose a node based on the real data path

Choose VMMini M4, a Singapore, Tokyo, Seoul, or Hong Kong node, and a daily, weekly, monthly, or quarterly term. All orders are billed in USD. After delivery, complete the connection baseline before running your first workload.

Rent a Cloud Mac Now Log In to the Console and Submit a Support Request