Start with your first connection

Get connected,
then make your workflow reliable.

These guides walk you through using a dedicated physical Mac mini in the order you’ll need. Check your access details, connect to macOS, set up your tools, then plan your builds, backups and renewals. No need to read everything at once—find the steps for what you’re working on now.

Rent a cloud Mac Open console

Already have an instance? Check its delivery details and order status in the console. Need help? Sign in and submit a ticket. Never share passwords, private keys or signing materials in public.

Connect first, then configure

Four checks for your first session

Each step has a clear success check. Test your setup in an interactive session before using the same configuration in automated jobs.

01Check delivery details

First login with your access details

Match the order, machine and connection details. Test one machine first so you don’t enter another node’s address in your client.

Show steps
  1. Sign in to the console and open the instance details for the relevant order. Check the model, node, rental term and delivery status.
  2. Save the connection address, username and actual port. Use the credentials provided in the console; don’t piece them together from forwarded emails or chat history.
  3. After your first connection, change the login password. Run sw_vers to check the macOS version, then run df -h to check available disk space.
  4. Note your project and artifact directories and who owns them. For team use, don’t commit shared credentials to a code repository.

Done when: You can reconnect, the system details match your order, and you know where build outputs are saved. If you’ve paid but haven’t received your credentials, submit a ticket on the order instead of placing duplicate orders.

02Remote access

Set up screen sharing and SSH keys

Use the graphical interface for initial setup and interactive debugging. SSH is ideal for commands, file transfers and automation.

Show steps
  1. Connect to screen sharing with the details provided. In System Settings, check “General → Sharing” and allow access only for the accounts that need it.
  2. For command-line access, check “Remote Login”. Generate an SSH key locally or use an existing one, and upload only the public key to the remote machine.
  3. Add the public key to the target user’s ~/.ssh/authorized_keys. Set the directory permissions to 700 and the file permissions to 600.
  4. Keep your current session open. Open another terminal to verify that public-key login works before changing authentication settings. Keep private keys on your local machine or in your team’s key management system.

Done when: You can connect through the graphical session and authenticate with your SSH key in a new session. Check the port and firewall settings against the details provided for your instance.

Read the connection guides
03Check your tools

Install and verify Xcode Command Line Tools

Check that your current environment meets the project’s requirements before making changes. Don’t upgrade just because Xcode is already installed.

Show steps
  1. Run xcodebuild -version and xcode-select -p to check the version and developer tools path.
  2. If the command-line tools are missing, run xcode-select --install. Full builds require a version of Xcode that matches your project; the command-line tools don’t include every SDK.
  3. If you have multiple Xcode versions, set DEVELOPER_DIR for a single job or use xcode-select to change the system-wide selection.
  4. Accept the tool licence, install any components required on first launch, then build and test a small project.

Done when: The Xcode version shown in your terminal matches the one in your CI logs, and the target SDK is available. Record the version in your project configuration or runner environment rather than relying on someone to remember it.

04Connect your CI

Register a self-hosted runner on your Mac mini

Get a manual build working before handing jobs to a runner. Use your CI platform’s project settings for the correct registration command.

Show steps
  1. Create a dedicated build user and working directory. In your CI project settings, get a runner package for macOS and Apple silicon.
  2. Register the runner with a short-lived token. Use labels for the OS, chip, node and purpose; don’t store long-lived access tokens in your repository.
  3. Run a small job in the foreground first. Check PATH, the Xcode path, keychain access and artifact uploads.
  4. Once you’ve confirmed the permissions needed for unattended runs, configure the service using your CI platform’s instructions. Test session requirements separately for jobs that use the graphical interface.

Done when: A test change triggers a job, the logs identify the instance, and artifacts are saved somewhere other than the machine. A dedicated machine doesn’t mean jobs can run with unlimited concurrency. Start with serial runs, then adjust concurrency based on memory and disk use.

Build repeatability into your workflow

Builds, signing and caches

For Unity, Flutter and native projects, keep track of tool versions, dependency lockfiles and build commands. Manage signing materials separately from rebuildable caches.

Build Unity apps for iOS in the cloud

Split the Unity export and Xcode archive into two independently verifiable steps. That way, you’ll know where a failure happened.

Show steps
  1. Pin the Unity Editor version, package dependencies and iOS Build Support module. Check your project’s licence requirements first so you don’t mistake a licensing issue for a machine problem.
  2. Sync the project and export an Xcode project. Keep the generated files separate from the source, and save the export log and commit identifier.
  3. Install the native dependencies required by the project. Check the scheme, target device type, Bundle Identifier and signing settings.
  4. Run an archive and verify the exported build before uploading it through your team’s usual distribution process. A successful compile doesn’t mean distribution is complete.

Keep a record of: The commit identifier, tool versions, export log, archive log and artifact checksum. Before retrying a failed build, address the first error instead of relying on the generic failure message at the end of the log.

Move Xcode certificates and provisioning profiles

Code signing requires a certificate, its matching private key and a valid provisioning profile. Copying the certificate alone usually isn’t enough.

Show steps
  1. Get signing materials that include the private key from a controlled team location, and transfer them securely. Send the export password through a separate secure channel.
  2. Import them into a keychain accessible to the build user. Check the certificate’s expiry date and confirm that the private key matches. Run security find-identity -v -p codesigning to list available identities.
  3. Import the provisioning profile for the target app, team and distribution method. Check the Bundle Identifier, expiry date and required capabilities.
  4. Test signing with the same user and execution method as the runner. Confirm that unattended jobs won’t get stuck on a permissions prompt.

Security: Never print export passwords, private keys or complete signing files to logs. Update your build configuration when rotating or revoking signing materials. Before your rental ends, remove sensitive materials from the machine and keep a secure copy with your team.

Put build caches on the additional SSD

The +1TB SSD is useful for rebuildable caches and intermediate artifacts. Confirm its mount path before updating your build scripts.

Show steps
  1. Run df -h to find the additional SSD’s mount point and available space. Create a separate directory for each project so jobs don’t share a writable cache.
  2. Point Xcode DerivedData to a dedicated cache directory. Keep Unity Library caches separate by project, Editor version and dependency state.
  3. Use separate directories for caches, archives and exported packages. After transferring artifacts over SFTP or to team storage, clean them up according to your retention policy.
  4. Check the mount after restarting or reconnecting. If the path is unavailable, make the job fail clearly instead of silently writing to the system disk until it fills up.

Plan for: Working copies, dependencies, caches, parallel jobs and artifacts. The additional SSD is wiped when the machine is returned; it isn’t a backup drive you can access after your rental ends.

Check memory first, then measure speed

Getting started with local inference on the 24GB tier

GNU Studio M4 comes with an M4 chip, 24GB RAM and a 512GB SSD. Model file size doesn’t tell you the total memory needed for inference. Quantisation, context length and concurrent requests all affect memory use.

Set up a reproducible MLX environment

Start by loading a small model and checking its output. Adjust the context or concurrency afterwards; don’t begin by sending the service its maximum workload.

Show steps
  1. Check that your dependencies support the current macOS, Python and Apple silicon environment. Create a separate virtual environment for each experiment.
  2. Install the required dependencies and record their versions. Keep a lockfile and pin the model version and quantisation format so successive tests use the same weights.
  3. Load the model with a single request and a short context. Record process memory, memory pressure and swap use, then gradually increase the input length.
  4. For comparable results, keep the prompt, generation length and warm-up conditions constant. Record the initial load separately from subsequent generation.

Done when: The same configuration can load the model and generate output repeatedly. Before increasing concurrency, check resource use—don’t estimate request capacity from the size of the model files.

Plan disk space for models

Keep model weights, download caches, converted copies and experiment output in separate directories. Multiple quantised versions add up quickly.

Show steps
  1. Check the actual file sizes in the model repository before downloading. Allow for the original files, quantised or converted output, temporary download files and logs.
  2. Keep model files separate from your Python environments. If you use the additional SSD, set the model cache path explicitly in your launch configuration.
  3. Run du -sh to check directory sizes and df -h to check free space on the volume. Each command answers a different question.
  4. Allow temporary space for failed downloads and conversions. Before deleting an old model, make sure no running job still uses its directory.

Keep in mind: A +1TB or +2TB SSD adds storage, not unified memory. Before returning the machine, export your experiment configuration, results and any weights you need to keep. Don’t leave your only copy on the instance.

Add the expiry date to your schedule

Renewals, configuration changes and payments

Use the billing period, expiry date and payment status shown on your console order as the source of truth. Instances run normally year-round, 365 days a year, with no scheduled downtime. Still allow time in your project schedule for backups and migration.

Renewal and pre-expiry checks

Choose a rental term by the day, week, month or quarter. A payment in progress doesn’t mean your renewal is complete.

Show steps
  1. Open the relevant order in the console. Check the instance and expiry date, and make sure the remaining term covers any running builds or experiments.
  2. Use the renewal option provided in the console to confirm the term and amount. If there’s no available option for your order, submit a ticket to confirm what to do.
  3. After paying, check the order status and new expiry date. If they haven’t changed, keep your order number and payment receipt and follow up through a ticket.
  4. If you plan to end your rental, stop new jobs and export your artifacts and configuration first. Then check that the copies in local or team storage open correctly.

Note: Don’t assume that automatic renewal or a standard grace period after expiry is available. Data is erased when the machine is returned, including from the additional SSD. Move any important data before your rental ends.

Change tiers and add storage

Assess memory and disk requirements separately. Plan how you’ll migrate your data and build environment before changing machines.

Show steps
  1. Record memory pressure, free disk space and any failures under your current workload. A large cache doesn’t necessarily mean you need a higher-memory tier.
  2. To change tiers, submit a console ticket with your current order number, target tier and migration requirements. Confirm the process and charges first.
  3. For a +1TB SSD, +2TB SSD or Thunderbolt 5 setup with multiple machines, check the options and quote in the console. For a multi-machine setup, specify the number of machines, software use and data exchange method.
  4. After a configuration change, verify mount paths, permissions, runner labels and job routing before resuming production jobs.

Keep in mind: Additional storage doesn’t increase memory. A Thunderbolt 5 setup with multiple machines doesn’t combine their memory or guarantee that software will distribute jobs across them automatically.

Compare both Mac tiers and add-on prices

Pay and check your order status

We accept USDT-TRC20 and Visa / Mastercard / Amex via Stripe. All payments are charged in USD.

Show steps
  1. Check the model, node, term, add-ons and amount due on your order. The payment gateways available to you are determined by the response from the payment interface.
  2. For USDT-TRC20, use only the network, payment details and amount shown on the current checkout page. Don’t reuse an address from an old screenshot.
  3. For a card payment, complete the card verification in the Stripe checkout flow, then return to the console to check your order status.
  4. If the status hasn’t been confirmed, note the payment time, order number and transaction ID, then submit a ticket. Don’t pay again without knowing why the first payment hasn’t been confirmed.

Payment proof: For an on-chain payment, you can provide the transaction hash. For a card payment, provide the receipt. Never send a full card number, security code, password or private key.

Get billing records and request documents

Start with the payment record for the relevant order, then tell us what documents you need. This is easier to verify than sending a charge screenshot on its own.

Show steps
  1. Find the payment in the console’s billing and order history. Check the amount, currency, billing period and order number.
  2. Save the available bill or payment receipt. If you need an invoice or other billing documents, say what they’re for and which details you need in a console ticket.
  3. Check the spelling of any billing details before submitting them. Don’t include unrelated personal information in ticket attachments.
  4. Our team will confirm which documents are available, how they can be issued and what happens next. A payment gateway receipt isn’t an invoice for every purpose.

General enquiries: Email support@gnumac.com. For billing questions about an existing order, use a support ticket so the full case history is kept together.

Workflows in practice

Go further: from setup steps to real projects

Use these quick guides to find the step you need now. Our blog brings together project walkthroughs and technical notes, with new posts available from the article index.

Browse all articles
Keep the evidence and troubleshoot step by step

Can’t connect or seeing a disk warning? Check these three things

First, work out whether it’s a network issue, an authentication failure or an application error. Record the original error, when it happened and what you’ve tried so you don’t repeat configuration changes.

Can’t connect to screen sharing

An unreachable address, rejected credentials and a black screen after connecting are different problems. Don’t keep restarting the instance before you know why it’s happening.

Show troubleshooting steps
  1. Recheck the address, port and username in the console. Make sure your client hasn’t kept old settings for another instance.
  2. Check whether your local network allows outbound connections. If possible, test from another permitted network to see whether a local policy is blocking access.
  3. If SSH works, check screen sharing settings and the users allowed to connect. If neither method works, note the error from each and submit a ticket.
  4. If you connect but the display looks wrong, lower the resolution and image quality. Note the client name and version, and take a screenshot of the issue.

Include in your ticket: Your order number, the time and time zone of the error, client, exact error text and whether SSH works. Redact credentials from screenshots.

SSH timeout or authentication failure

A timeout is usually related to the address, port or network path. For authentication failures, check the username, public key and permissions first.

Show troubleshooting steps
  1. Connect using the actual port in your delivery details; don’t assume it’s the default. Run ssh -vv to see whether the failure occurs during connection, negotiation or authentication.
  2. For a timeout, check local outbound restrictions and the instance status. For “Connection refused”, check whether Remote Login is enabled.
  3. For Permission denied, check the target username, public key and file permissions, and confirm that your local client selected the correct private key.
  4. If the host fingerprint has changed, check in the console whether the machine was reinstalled or replaced. Confirm the reason before updating your local record; don’t ignore a security warning.

Include in your ticket: A redacted connection command, the end of the error output, and the time and time zone. Never send private key contents or passwords.

Disk space warning

Stop large jobs that are still writing, then find what’s using the space. Don’t delete system directories or files another job is using.

Show troubleshooting steps
  1. Run df -h to find the volume that’s running out of space. Distinguish the system disk from the additional SSD rather than relying on the total shown in Finder.
  2. Use du -sh to check project, build cache, model download and artifact directories. Confirm whether any jobs are still writing to them.
  3. Move artifacts you need to keep, then remove rebuildable caches and temporary files from failed downloads. Check that log rotation is working as expected.
  4. Check free space again after cleanup, then resume one job and monitor disk use. If space remains tight, consider an additional SSD rather than repeatedly deleting data you need.

Include in your ticket: Your order number, capacity output for the relevant volume, the largest directories and recent job changes. Don’t upload a full directory listing if it contains sensitive file names.

Before submitting a ticket, prepare steps to reproduce the issue

  • Details: Order number, instance, node, and the time and time zone when the issue occurred.
  • What happened: Expected result, actual result, and whether this happened once or every time.
  • Evidence: Minimal steps to reproduce, redacted logs and troubleshooting steps you’ve already tried.

For issues with an existing order, submit a ticket in the console. For pre-sales questions or if you can’t access your account, email support@gnumac.com. Never include passwords, private keys, full card details or signing materials.

Sign in and submit a ticket Contact details

Know your workflow? Start your rental.

Choose a model, node and rental term, and have your project configuration and backup plan ready. For an existing instance, continue from its order in the console.

Rent a cloud Mac Open the console