Choose for the workload

Cloud Mac, local Mac or virtualized macOS?

Need native Apple Silicon without buying another machine? OSXFlow gives you an entire physical Mac mini. The CPU, GPU and unified memory are yours alone—not a virtual machine—from $20.2/day.

Move builds, CI and MLX experiments to a dedicated node. If your work depends on peripherals at your desk or needs to run offline, a local Mac may be the more convenient choice.

Two models, five locations. Check the control panel for live availability.

Three options, three sets of responsibilities

Look beyond the price: compare resources and management

A cloud Mac changes where the device lives and how you access it remotely. A dedicated Mac determines who gets its resources. Those are separate questions. Start with your build environment and isolation needs, then consider connectivity, peripherals and hardware costs.

Compare the delivery models. Shared virtualization services can differ, so check the details of each product.
What to consider OSXFlow dedicated Mac Shared macOS virtualization Mac you own
Performance isolation An entire Mac mini is yours. Its CPU, GPU and unified memory aren’t shared with other customers. Resource allocations and scheduling depend on the provider. Check how CPU, memory and GPU resources are assigned. You control the resources, but interactive work, builds and background tasks can still compete with one another.
Native Apple Silicon environment Physical M4 or M4 Pro hardware running native macOS—not a virtual machine. Check the host hardware, virtualization method and toolchain compatibility. The macOS label alone doesn’t tell you enough. Depends on the hardware you buy; you configure the operating system and toolchain yourself.
Getting started Flow M4 starts at $20.2/day. Rent for a short period to test your workload first. Check the instance price, billing increments and resource limits—not just the advertised starting price. Pay the full hardware cost upfront, then manage power, networking and where the device is installed.
Scaling up Choose between two models; add a +1TB / +2TB SSD or Thunderbolt 5 daisy-chaining. Scale within the product’s resource limits. Check whether changes require rebuilding an instance or moving data. Limited by your device’s specifications and ports; adding compute capacity usually means buying another machine.
Management The platform provides the physical node. You manage software, keys, workloads and backups on the system. The platform manages the virtualization infrastructure. Confirm what you manage inside the system and what the platform controls. You or your team handle everything from hardware and networking to the operating system and backups.
Access and peripherals Connect over remote desktop or SSH, so you’ll need a working network. Check peripheral requirements before moving workloads. Usually accessed remotely. GUI support, network restrictions and peripheral compatibility depend on the product. Easy to use interactively and connect peripherals directly—useful for offline work and on-site tasks.
Workloads to consider first Dedicated builds, self-hosted runners, native-environment testing and MLX experiments. Workloads that can operate within resource quotas and have been tested for virtualization compatibility. Ongoing local interaction, offline work or tasks that need direct connections to devices.
A clear commitment, with a claims process

A clear uptime commitment, not a made-up track record

Nodes are available year-round, 365 days a year. We explain the service commitment and credits here; the figure isn’t presented as historical monitoring data. The estimated activation time of around 4 minutes is not a guaranteed delivery time for every order.

Uptime commitment

99.9%

Over 30 days, that allows for about 43 minutes of downtime.

30 × 24 × 60 × 0.1% = 43.2 minutes

Downtime beyond the allowance earns service-time credits

Downtime beyond the allowance is credited as additional service time. Credits are for service time, not cash refunds. When submitting a claim, include the start and end times of the incident and the node ID so we can verify which node and time period were affected.

Force majeure events and issues caused by your own actions are excluded. Shutting down the system, changing connection settings or a failed workload doesn’t by itself establish a platform outage. Record what happened first, then investigate the cause.

  1. 01

    Record the incident

    Note the node ID, start and recovery times, time zone and any connection errors. Don’t include passwords, private keys or other sensitive information in emails or screenshots.

  2. 02

    Submit on time

    Open a ticket through the control panel within 7 days after the incident ends. Describe the affected service and time period rather than simply saying “the machine didn’t work.”

  3. 03

    Confirm the credit

    Use the ticket to confirm the incident scope and service-time credit. Before continuing, check whether your workloads need to be restarted or rerun.

Dedicated means the whole machine

You get a Mac mini—not a slice of its cores

For the rental period, the entire physical machine is yours. Its CPU, GPU and unified memory aren’t shared with other customers, and you aren’t given a shared virtual instance on the node. You decide how many workloads to run on the system.

Keep builds off your local machine

Move Xcode builds, dependency installation and test runs to a dedicated node, while your local computer stays available for editing and communication. After moving a project, pin tool versions and cache paths, then compare full and incremental builds.

For dedicated builds

Give CI a consistent runner

Register the node as a self-hosted runner and assign labels by project or workload. A dedicated machine doesn’t isolate jobs automatically: your team still needs to set concurrency limits, clean working directories and manage key permissions.

For continuous integration

Choose a model for memory needs

The M4 Pro model has 64GB of unified memory and a 2TB SSD, making it a good fit for MLX experiments that need more unified memory. Test whether your model loads and how many concurrent jobs it can handle, based on quantization, context length and actual memory use.

For model experiments

Both models are dedicated physical machines. They differ in chip, memory and storage—not in whether resources are shared. See the connection guide to learn about remote access.

Your data, your backup plan

Take your work with you before the rental ends

You own the code, models and build artifacts on the node. When your rental ends, the entire drive is erased before the device is put back into service. This process clears the device; it isn’t a backup service. Export anything you need before the end date and verify that your copies work.

While using the node: know what can be rebuilt

Dependency caches and temporary build directories can usually be recreated. Unpushed code, signing materials, experiment notes and final artifacts need separate backups. Don’t keep the only copy on a rented node.

Before handing work to a teammate, check project permissions, SSH keys and workload environment variables. Sharing a node shouldn’t mean sharing every credential.

Make a backup checklist

Before the end date: export, verify, then clean up

Sync your projects and artifacts in advance. Check that files open, repositories can be cloned again and essential configuration is included. Allow time to transfer large models and caches—don’t leave it until the last minute.

After verifying your backups, remove project credentials and runner registrations you no longer need. Once the device is erased, you won’t be able to retrieve files from the original node.

Wrap up before expiry
Choose a term that fits the workload

Try it by the day, then decide how long to rent

Choose prepaid daily, weekly, monthly or quarterly billing. You can renew the same machine or switch billing periods. Before renewing or switching, check the current expiry date, next term and bill amount in the control panel. Changing the billing period doesn’t automatically add another machine.

Daily: test a key workload

Good for testing remote access, the Xcode toolchain or model memory requirements for the first time. Run a real project from start to finish before deciding whether to extend your rental.

Check compatibility

Weekly: cover a release cycle

Useful for a focused round of builds, testing and regression checks. Plan the rental around your release schedule, leaving time for reruns, artifact exports and handover.

For short-term projects

Monthly: run ongoing workloads

A good fit for persistent runners or regular builds. Add renewal checks to your team’s on-call checklist so you don’t overlook the rental expiry while monitoring pipelines.

For steady workloads

Quarterly: commit once needs are clear

For long-running workloads with a tested configuration, node and team workflow. Confirm you have enough memory and storage headroom before choosing a longer term—don’t rely on estimates instead of testing.

For validated long-term needs

Two models: choose by specs, not by name

Prices are in USD. Add-ons are billed separately. Confirm the final configuration and price at checkout.
Model and specs Daily Weekly Monthly Quarterly
Flow M4
M4 / 16GB / 256GB
$20.2 $54.4 $100.8 $274.2
Flow M4 Pro
M4 Pro / 64GB / 2TB
$61.2 $165.3 $306.1 $832.6

Both models are available in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong and the US East Coast. Choose a location based on your team and actual connection experience. Check the control panel for live availability.

Payment is available only via USDT-TRC20 or Visa / Mastercard / Amex processed through Stripe. All charges are in USD. Available payment gateways are determined by the backend response.

Need dedicated resources? Choose a model

For lighter builds, start with Flow M4. For more parallel builds or higher unified memory needs, consider Flow M4 Pro. Check the billing term and add-ons before confirming your order.