Self-service guides · From connection to setup

Your next step,
to a cloud Mac that's ready to work.

Already have a node? Connect to the desktop, change the password, then set up your build or inference workload. Still deciding? Review the setup requirements before choosing a plan.

Enter a keyword to filter these instructions, or browse the page as it is.

Open portal Rent a cloud Mac

Use the connection details and credentials shown on your instance page after signing in. This guide does not display credentials or perform remote actions.

Start with these four steps

Begin with your first login

Follow these steps in order. Confirm the instance and connection details before setting up your toolchain. Keep connection issues separate from build issues as you troubleshoot.

Sign in to the portal

Sign in with the email address used for your order, then follow the prompts to log in or set up your account. In the instance list, check the plan, node and billing period associated with your order.

Payment does not mean the system is ready. Check the instance's delivery status first, and connect only after its details include connection information. If you can't find your order, make sure you're using the same email address you used to place it.

Find your VNC / SSH details

Open the details for a ready instance to find its connection address, username, password and port. Use the VNC and SSH details shown there; don't assume both connections use the same port.

Before accepting the fingerprint on your first SSH connection, verify the host details. Never post passwords, private keys or screenshots containing credentials in public repositories, chat groups or build logs.

Connection steps by platform

Check Xcode and the command line tools

Check the active path and version before deciding whether to install anything. If your project requires the full Xcode app, the command line tools alone won't be enough. Make sure the SDK, simulators and build tools match your project requirements.

xcode-select -p
xcodebuild -version
xcrun --find clang

Install or switch Xcode using an installation package approved by your organisation. After opening it for the first time, let component setup finish, then rerun the version checks in Terminal. Switching the developer directory may require administrator privileges.

Check the path, version and compiler

Change the default password

Change your current user password in macOS settings, or run passwd in Terminal and follow the prompts. Use a strong, unique password—not one you use for code hosting or email.

After changing it, keep your current session open and use a second connection to test the new password. Before switching SSH to public-key authentication, confirm that you can sign in with a new session. Don't disable your existing authentication method until you have a way back in.

Test the new connection before ending the old session

Put your node to work

Set up CI with a minimal working pipeline

Register the runner, confirm which user executes jobs and verify the toolchain before tuning concurrency. Run these steps on your node; your code hosting platform controls pipeline permissions.

GitHub Actions: Register a self-hosted runner

In your repository or organisation's Actions settings, add a self-hosted runner and choose macOS and ARM64. Use the download and registration commands generated on that page; don't put the registration token in a long-lived script.

1Register as the build user
Register the runner as the macOS user that will actually run builds. Confirm that this user can read the project directory and access the keychain needed for builds.
2Add a dedicated label
For example, label the node osxflow-m4 and target that label with a single test workflow first, so an older runner doesn't pick up the job as well.
3Test before running persistently
Start the runner interactively and confirm the workflow passes before configuring it to run persistently, following the instructions supplied with the runner. After signing in again, check the process and its connection status on the platform.

jobs:
  verify:
    runs-on: [self-hosted, macOS, ARM64, osxflow-m4]
    steps:
      - run: |
          uname -m
          xcodebuild -version
          xcrun --find clang

Don't let untrusted external contributions run on a runner with access to signing materials. Once the test workflow passes, migrate your release pipeline and secret variables.

GitLab Runner: Choose the shell executor

Register using the runner authentication details created in your project or group settings, and select the shell executor. Jobs run directly in the node user's environment, without container-level isolation.

Start with concurrency set to 1 to prevent signing jobs or cache writes from interfering with each other. Check that the runner user's PATH, developer directory and Ruby environment match your manual test setup.

concurrent = 1

[[runners]]
  executor = "shell"
  shell = "bash"

These are only the relevant fields in the configuration file after registration, not a complete registration configuration. Keep the URL, authentication details and other fields generated by the registration tool. Don't overwrite the whole file with this snippet.

Give the runner a dedicated tag, and have a test job print whoami, pwd and xcode-select -p. If a build works in Terminal but fails in CI, compare the user, paths and environment variables before reinstalling tools.

Fastlane: Keep signing materials out of your code

Import certificates, private keys and provisioning profiles through your team's authorised process. Keep them out of source control, and don't print decryption passwords in Fastlane output.

Use a dedicated keychain for CI and restrict file access. The build user must be able to unlock and read it.
Pass passwords through your code hosting platform's secret variables instead of inserting them directly into commands that may be echoed.
Store provisioning profiles as required by your current Xcode version. Run a minimal archive to check that the team, certificate and configuration match.
Remove temporary signing files after exporting the build. Before your node rental ends, revoke runner registrations and access tokens you no longer need.

A dedicated physical Mac doesn't replace project-level access controls. Anyone who can change the release pipeline may be able to read the signing environment through a job, so review repository permissions too.

Test first, then scale up

Run a repeatable inference experiment with MLX

Flow M4 Pro comes with M4 Pro / 64GB / 2TB. System processes and your workloads share unified memory, so 64GB isn't all available to the model. Leave room for weights, context and runtime caches.

Isolate your Python environment

First confirm that Python is running as ARM64, then create a virtual environment for each experiment. Avoid mixing dependencies from different model projects into the system environment.

python3 -c "import platform; print(platform.machine())"
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install mlx-lm
python -m pip freeze > requirements.lock.txt

Save the dependency list along with the Python and model versions. To reproduce an experiment, install the same environment first, then compare the output and resource usage.

Goal: isolated environment, reproducible dependencies

Start with a small model and short context

Choose a quantized model that's compatible with MLX and that you're authorised to use, and read its documentation first. Record the quantization, context length and generation length; don't compare models by file size alone.

python -m mlx_lm.generate --help

Use the installed version's help to pass in a model and prompt. Run a single inference first, then gradually increase the context. Watch memory pressure and swap in Activity Monitor, and scale the workload back if pressure keeps rising.

For meaningful comparisons, keep the prompt, generation length and concurrency fixed. Results from different models and quantization methods don't directly show differences in node performance.

No throughput assumptions or guarantee a model will fit

Keep model files separate from your projects

Need more space? Select the +2TB SSD option when configuring your order. Check the actual mount path and available capacity on your node before moving model weights and download caches. Don't assume every node uses the same volume name.

Stop any tasks reading the model before moving files. After copying, check the file count and sizes, then update the tool's model path or cache settings. Confirm the model loads before deleting the original copy.

More storage isn't a backup. Keep model versions, configuration and important results somewhere you control instead of relying on your rental node as the only copy.

Storage options and pricing

Get the terminology straight

Eight common terms, explained

These definitions apply to orders, connections and support tickets. Using consistent terms makes it easier to distinguish the machine, connection protocol and billing settings when describing an issue.

Physical node: The actual Mac assigned to your rental—not the remote desktop client.When to use it: Include the node ID from your instance details in a support ticket instead of referring to “that machine”.
Dedicated: The whole device is reserved for your workloads during the rental period. Its CPU, GPU and unified memory aren't shared with other renters.When to use it: You still need to manage resource contention between your own concurrent tasks.
Non-virtualised: You use macOS directly on a physical Mac, not a virtualised instance on a shared host.When to use it: Check that the macOS version and Apple Silicon toolchain meet your project requirements.
VNC: A remote access protocol that transmits desktop video and keyboard and mouse input, suited to working with a graphical interface.When to use it: Open Xcode for the first time, change system settings or check Activity Monitor.
Screen Sharing: A macOS remote desktop feature that connects to a node using the details provided for your instance.When to use it: On a local Mac, open Connect to Server in Finder to access the remote desktop.
Self-hosted runner: A worker that you register and manage to run pipeline jobs on your own node.When to use it: Use a dedicated label to send release pipeline jobs to this cloud Mac.
Billing period: The prepaid unit you choose when ordering—by the day, week, month or quarter. It's different from the runtime of an individual build job.When to use it: Keep track of your order's expiry date after a release, and export your data in advance.
Thunderbolt 5 clustering: An add-on for coordinating multiple Macs, priced per machine. It doesn't automatically combine them into one pool of unified memory.When to use it: Before planning a multi-node workload, check that your application supports the relevant distributed execution method.

Change one thing at a time

Common issues: troubleshoot in this order

Record the original error before changing any settings. Keep one working session open; don't disable your only working access method just to test something.

VNC connects, but the screen is blank

First check that the instance details show the system as ready, then verify the VNC address and port. Disconnect and retry with only one client open. Try lowering the resolution or disabling adaptive image quality to tell a client display issue from a node session issue.

If SSH still works, don't immediately restart a node running active tasks. Note the client name and version, what you were doing before the screen went blank, and whether SSH is available. Include a screenshot without credentials when you submit a ticket.

Desktop connection steps by platform

SSH is refused—which error should you check first?

For Connection refused, check the address, port and service status first. If the connection times out, check your local network, proxy and access restrictions. For Permission denied, check the username and authentication method; don't mistake an authentication failure for a network issue.

Use ssh -v to inspect the connection stages while debugging. Don't share the full debug log publicly. Before sharing, remove the address, username, key path and authentication details. If you're using a private key, check its file permissions and confirm that the server has the matching public key.

If you can still access the graphical desktop, check the remote login status in system settings first. If you're not sure what's wrong, submit a ticket with the exact error, node ID and port. Avoid changing multiple authentication settings at once.

Xcode is taking a long time to download or install

First check whether Xcode is downloading, verifying or extracting. Monitor network, CPU and disk activity: a quiet network connection doesn't necessarily mean a download has stalled if the disk is still busy. Don't start several identical installation jobs.

Make sure the destination disk has room for the installer, extracted files and project caches. If you need a specific version, use an installation package approved by your organisation and verify its integrity. After installation, run xcodebuild -version again to check that CI and the graphical interface use the same version.

When submitting a ticket, include the Xcode version, current installation stage, free disk space and whether you're using a proxy. “It's slow” on its own isn't enough to diagnose the issue.

Disk space is low—clear caches or add storage?

Check volume capacity first, then find the largest directories. These commands only report disk usage and won't delete files. Scanning large user directories may take a little while.

df -h
du -sh "$HOME/Library/Developer/Xcode/DerivedData"
du -sh "$HOME/Library/Caches"

Stop builds before clearing caches that can be regenerated. Don't delete entire directories containing keychains, signing materials, project source files or your only copy of a model. The first build after clearing caches will usually need to regenerate files, so account for that time in your release schedule.

If model weights and build artifacts keep growing, plan storage capacity separately. See the +1TB SSD and +2TB SSD add-ons. If you need to change an existing order, check with support through the portal first; don't assume files will move automatically after adding storage.

View SSD add-ons

For the reasoning behind the steps

Explore our technical articles

This page covers what to do next. For in-depth guidance on build workflows, choosing hardware and protecting data, browse the technical articles. Titles, summaries and publication dates reflect the articles listed there.

Technical articles

Browse all articles and latest updates

Read practical guides by publication date and make decisions based on your toolchain, data boundaries and rental period. For immediate steps, start with this page's connection, CI and troubleshooting checklists.

Give support the details they need

Still stuck? Include these three things in your ticket

If you've already rented a node, sign in to the portal to submit a ticket so it can be linked to your instance. Never include passwords, private keys, full card numbers or screenshots containing credentials.

01Identify the instance
Include the node ID, order number and approximate time and time zone when the issue occurred. For payment questions, share only the transaction reference—not authentication details.
02Explain how to reproduce it
What did you do, what did you expect to happen and what happened instead? For connection issues, include the client and version; for build issues, include the toolchain version.
03List what you've checked
Share the exact error with sensitive details removed. Say whether the graphical desktop or SSH is still working, and whether any running task must not be interrupted.

No need to start from scratch.
Send the results of your checks.

Submit a ticket through the portal and link it to your instance. For pre-sales questions, email enquiries or billing issues, see the contact information.