Workflows in practice

Four workflows. One physical Mac mini.

Keep your work on a dedicated cloud Mac: build remotely, run tests continuously, deploy an MLX inference service, or work with video and audio. Explore each workflow step by step, then use the recommendations to choose the right setup.

Rent a cloud Mac Compare models & pricing

The entire physical machine is yours—not a VM. Choose a daily, weekly, monthly or quarterly term. Check the portal for real-time availability.

VMR / WORKBOOK Choose a setup based on the work
01Build & releaseXcode → TestFlight
02Continuous integrationPR → self-hosted runner
03Model servingMLX → SSH tunnel
04Media productionFootage → transcode & review
Explore by workflow

Start with the task. Then choose a model.

These are reusable workflow examples, not customer testimonials or benchmark results. Each card explains how work reaches the node, what comes out, and where each setup makes sense.

01 / DEVIndie developer

Build by day. Ship at night.

Connect to the same cloud Mac over SSH or its graphical interface. Use Xcode and the simulator for daytime development and testing. Before release, check your signing assets, then run fastlane beta in the evening to submit the build to TestFlight.

For a short release sprint, consider a daily or weekly term. Project files, build caches and release scripts stay on the node, so you can pick up where you left off next time without rebuilding your environment.

Key toolsXcode · fastlane
02 / CICI team

Run every PR in the same test environment

Register a self-hosted runner on a monthly node. When the repository receives a PR, trigger xcodebuild test and feed the results into your existing CI pipeline. Build caches stay on the same machine, making recurring issues easier to investigate.

First, check how many jobs will run in parallel and how much memory your project needs. A dedicated node avoids resource fluctuations from sharing a VM with other tenants, but your team still needs to manage the job queue on a single machine.

Key toolsRunner · xcodebuild
03 / MLXAI research

Keep quantised models in a running service

Prepare your model files on a VMR Lab Pro with an M4 Pro, 64GB of unified memory and a 2TB SSD, then start mlx_lm.server. The service runs on the physical node, and team members can connect through their own SSH tunnels without exposing the inference port directly to the public internet.

Before choosing a setup, estimate the combined memory used by model weights, context and other processes. The machine has 64GB of memory; that does not mean all 64GB are available to a single model.

Key toolsMLX · SSH tunnel
04 / MEDIAMedia production

Keep footage and transcodes on the node

Store your footage on the cloud Mac and add the +2TB SSD option if you need more space. Organise proxy files, batch transcode and render on the node, then review your work through the remote desktop. Before delivery, check the output format and download the final files.

Work out how much space your source files, caches and exports will need at the same time. Remote viewing works well for review; check the exported original files to assess final image quality.

Key toolsRemote desktop · +2TB SSD
Workflow 03 / AI research

Load models and run services on the same Mac

Apple silicon uses unified memory shared by the CPU and GPU. When planning an MLX service, you don't need separate memory budgets for dedicated video memory and system memory. You still need headroom for context, caches, the operating system and concurrent requests.

Start with the model files: check the format and licence, install mlx-lm, then start the service on the node and connect only through SSH local port forwarding. Whether a model fits, and how many requests you can run concurrently, depends on the model and runtime settings—not just the Mac model.

  1. PrepareCheck model file size, quantisation and available storage.
  2. LaunchRun the service on the physical node and track actual memory use.
  3. ConnectSet up an SSH tunnel, then call the API from your local machine.
MLX deployment quick guide
Workflow illustration only. It does not show measured memory usage, throughput or a public-facing service.
Workflow 01 / Release readiness

Take a release from simulator coverage to TestFlight

Adapting a release means more than getting the project to compile. List the device sizes and OS versions your project actually supports, run the corresponding simulator tests on your cloud Mac, then review failures, fix issues and build again.

Automate tests with xcodebuild test. For layout, permission prompts or interaction flows, switch to the graphical interface for a manual check. Once testing is complete, use your existing signing assets and release scripts to submit a TestFlight build, then check its processing status in the build list.

  1. Set the matrixCover only the OS and screen combinations your product supports.
  2. Run testsKeep failure logs and separate environment issues from code regressions.
  3. Check deliveryVerify the archive, upload and TestFlight build status.
First connection: step by step
An illustration of the simulator matrix and build list. The devices and OS versions depend on your project's support range.
Release / Workflow walkthrough

How a week on a node could support a release

This is an illustrative walkthrough from a developer's perspective, not a real user interview or customer review. A one-week term provides a focused window to set up the environment, run regression tests, upload a build and check the release. Whether weekly billing works for you depends on your project schedule.

01

Prepare the environmentSecurely transfer the project and required signing assets to the node, then check the Xcode toolchain.

02

Run regression testsAutomate the tests and review pages that need a manual check over a remote connection.

03

Submit the releaseArchive and upload the build, then check its processing status in TestFlight.

04

Wrap upExport any logs and files you need to keep, then decide whether to continue using the node.

This workflow card doesn't contain a playable video. It breaks a release into four checkable steps so the illustration isn't mistaken for a customer testimonial.

Compare setups

Choose by workload, duration and team location

Use this table as a starting point, not a performance guarantee. Both models are available in Singapore, Tokyo, Seoul, Hong Kong and the US West Coast. Start with the location closest to your main users, then check how it works for your team in practice.

Recommended model, term and location for each of the four workflows
Workflow Recommended model Suggested term Choosing a location Check before ordering
Indie development & releases VMR Lab M4
M4 · 16GB · 256GB		 Daily or weekly for a short sprint Near your main developer for easier remote access Storage for the project, build cache and signing assets
Continuous integration VMR Lab M4
M4 · 16GB · 256GB		 Monthly for a persistent runner Consider where your repository and team connect from Single-machine job queue, peak project memory and cache storage
MLX inference experiments VMR Lab Pro
M4 Pro · 64GB · 2TB		 Weekly to evaluate; monthly for ongoing use Near the main clients, with access over an SSH tunnel Model weights, context, concurrent requests and memory headroom
Media production VMR Lab Pro
M4 Pro · 64GB · 2TB		 Weekly or monthly, based on the project schedule Near the teams uploading and reviewing footage Source files, caches, exports and whether you need the +2TB SSD

These recommendations don't limit other available combinations. See rental plans for pricing, add-ons and terms. Check the portal for real-time availability.

Next step / Configure your node

Find your workflow, then compare your options

Start with the memory and storage your work needs, then choose a term and location. Both options give you an entire physical Mac mini to yourself. Not sure where to start? Compare prices and specifications.

Configure a cloud Mac View rental plans