From first login to first delivery

Connect, build, ship

First, check in the portal that your instance is ready. Then connect to your dedicated physical Mac mini. Build from the command line, inspect the environment in the remote desktop, and let CI handle repeatable tasks.

Already have an instance? Check its connection details. If you haven't rented one yet, start with an order. Connection credentials are never displayed on public pages.

Check your instance first

Choose how to connect

Open the instance details in the portal and check the instance ID, node, and status. Use the public address, username, port, and initial credentials returned for that instance. Don't reuse connection details from another machine.

SSH

Use SSH to run build commands, transfer files, and inspect logs. The default SSH port is 22. If your instance uses a different port, use the value shown in its details.

Get the host address and username from the instance details. On your first connection, verify the host fingerprint before adding your public key. Keep your private key on your device; never include it in a support ticket.

See a first-build example

VNC remote desktop

Use VNC to open Xcode, check the Simulator, and adjust settings in the graphical interface. The default VNC port is 5900. Find the connection address, password, and actual port in the instance details.

Once connected, check that the desktop responds. Don't reuse your VNC password in a code repository. Where supported, connect through a controlled access path or an SSH tunnel.

Troubleshoot desktop access

Portal web terminal

Log in to the portal and open the connection option shown in your instance details. If a web terminal is available, connect over HTTPS in your browser. It usually uses 443, so you don't need to enter a separate terminal port.

Access is tied to your logged-in account session; it's not a public link. If the option isn't shown for your instance, use SSH or VNC instead. Don't guess the terminal address.

View instance connection options
Get one build working, then automate it

Verify your connection and build separately

First confirm that you can log in, then check the Xcode path and version. The output below is an example, not a live instance log. Session names, build numbers, and timings are included only to show where to look.

merge@tokyo-m4pro-07 Example build output
$ ssh -p <SSH_PORT> <USER>@<HOST>
Welcome to MergeMac
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
$ cd <PROJECT_DIRECTORY>
$ xcodebuild -scheme App archive
** ARCHIVE SUCCEEDED **
$ fastlane pilot upload
Successfully uploaded Build 214

Replace the placeholders before running

Replace the values in angle brackets with the details for your instance. App is an example scheme. For a workspace project, pass your own -workspace and make sure the scheme is shared.

A successful archive doesn't mean the upload is done

Uploading also requires valid signing, an export configuration, and upload credentials. This example assumes fastlane is configured for the project. Build 214 isn't proof of your delivery; rely on the output from your upload tool.

Give the machine a clear job

Set up a self-hosted runner

MergeMac provides a dedicated physical node. You manage your CI repository permissions, job configuration, and credentials. First run the archive successfully in a terminal as the same user your runner will use. Then register the runner, so environment issues aren't mistaken for scheduling issues.

GitHub Actions

  1. Open the Actions runner settings for your repository or organization, then select macOS and the matching Apple Silicon architecture.
  2. On your rented node, download, verify, and register the runner using the commands on the current setup page. Registration tokens are sensitive; don't add them to a repository or screenshot.
  3. Add labels such as mergemac, macos, and m4. Use runs-on in your workflow to match them.
  4. Start with a job that checks only the Xcode version. Confirm that the right node picks it up, then add dependency installation, archiving, and upload steps.

Don't let untrusted external pull requests run directly on a runner that has access to signing materials. Authorize release jobs separately from routine checks.

GitLab Runner

  1. Create a runner in your project or group and get the service address and authentication token required by the current registration flow.
  2. Install the GitLab Runner version that matches your architecture, then register it using the generated instructions. If you need the local Xcode toolchain, choose the appropriate Shell executor.
  3. Set labels such as macos and xcode, and declare them explicitly in your jobs. Restrict release runners to protected branches or tags.
  4. Run an environment check first. Verify the working directory, execution user, and Keychain access before enabling production builds.

Revoke the runner's authorization in your CI platform when rotating its token or ending the rental. Deleting files from the node won't revoke platform access.

Understand the terms in the portal

Eight terms, explained

These terms describe resources and connection methods. They don't include extra software licenses or combine multiple machines into one larger Mac.

Physical node
An independently assigned Mac mini in a data center, running a real macOS development environment.
Dedicated
For the duration of your rental, the machine's CPU, GPU, unified memory, and local storage are allocated to one tenant.
Not a virtual machine
You use macOS directly on a physical Mac, not a virtual instance carved out of a shared host.
VNC
A protocol for viewing and controlling the macOS graphical desktop remotely.
SSH
An encrypted protocol for command-line access, running commands, and transferring files.
Self-hosted runner
A CI runner installed on your rented node. Your pipeline configuration assigns build jobs to it.
Unified memory
Memory shared by the CPU and GPU in Apple silicon. The space available to your apps is reduced by macOS and other running processes.
Thunderbolt 5 multi-machine setup
Connect multiple devices directly over Thunderbolt 5 for multi-machine experiments. Your application still needs to support distributing work.
Save evidence before changing the environment

Troubleshoot by symptom

Record the time and time zone, instance ID, full error, and most recent change. Change one thing at a time, then repeat the same check. Reinstalling should not be your first step.

  1. 01

    VNC shows a black screen or stops responding

    First check that the instance is ready in the portal, then test the SSH connection. If SSH works but the desktop doesn't, check whether a user is logging in, logging out, or switching graphical sessions. Quit the client and reconnect.

    If the screen is still black, note the client version and save a screenshot, then open a support ticket. Don't disable the firewall or repeatedly force-restart the machine to troubleshoot; doing so could interrupt a running build.

  2. 02

    Xcode versions don't match

    Run xcode-select -p and xcodebuild -version. Check both your interactive session and the runner. Having multiple versions installed doesn't mean the command line is using the one you expect.

    For a single job, set DEVELOPER_DIR to the target Xcode Developer directory instead of changing the machine-wide default and affecting other jobs. If the directory doesn't exist, check the installation path rather than copying an example path.

  3. 03

    Simulator data fills the disk

    Check available space with df -h, then inspect DerivedData, archives, device data, and simulator runtimes. Export any build artifacts you need to keep and stop jobs that are using simulators.

    xcrun simctl delete unavailable removes records for unavailable simulator devices; it doesn't remove every runtime. Check what you're deleting first. Don't recursively delete project directories or Keychains.

  4. 04

    Signing certificate is invalid

    Work out whether the certificate has expired, the provisioning profile is invalid, the private key is missing, or the Keychain is locked. Check the certificate's validity period, team, and bundle identifier, then confirm that the CI user can access the corresponding private key.

    After renewing a certificate, update the provisioning profile and protected variables, then test again with the same scheme. Include only error codes and redacted logs in your ticket; never send private keys, certificate export passwords, or complete signing materials.

Back up first, then confirm the reinstall

A reinstall changes the environment and doesn't keep your workspace

Reinstalling the system and clearing data after a rental ends are separate processes. Don't use your rented node as the only place to store source code, signing materials, or build artifacts.

Reinstall during your rental

Open your instance details in the portal. Before reinstalling the system, stop CI jobs, export your projects, artifacts, and required configuration, and make sure you can open the backup somewhere else.

Initialization usually takes a few minutes. Check the portal for the actual status and completion time. Don't submit the task repeatedly while it's running. Once it's complete, retrieve your connection credentials again, verify the host fingerprint, and rebuild your development environment.

After reinstalling, verify SSH, Xcode, dependencies, and your runner again. Don't assume the previous service configuration is still there.

Disk cleanup after your rental

After your rental ends, the node goes through data cleanup and a system reset before it's prepared for another customer. Export anything you need to keep before the end of your rental; don't rely on being able to connect afterward as a backup plan.

Also revoke repository deploy keys, CI runner tokens, and upload credentials. Disk erasure removes data from the node, but it doesn't revoke access to external systems on your behalf.

For questions about data handling or security boundaries, review the security information first, then ask about your specific instance in a portal ticket.

Help us get straight to troubleshooting

Contact support

For issues with a rented instance, submit a portal ticket so we can link it to your order and node. If you can't log in, have a pre-sales question, or need to report a security issue, email our support team. Please don't open multiple tickets about the same issue.

Portal tickets

Log in and open the support area. Include your instance ID, the impact, and steps to reproduce the issue. To escalate an existing issue, add details to the original ticket so troubleshooting stays in one thread.

Suggested format: time and time zone → expected result → actual error → steps already tried. Attach the shortest relevant redacted log excerpt; don't upload your entire source tree.

Log in and submit a ticket

Support email

If you can't access your account, explain the issue in the subject line and include your registered email address and an order number we can use to verify your account. Never send your account password or payment card number.

Our team works across Asia-Pacific and US Eastern time zones. Response times depend on the issue's priority and the current queue. We'll share updates by ticket or email; we don't promise an unpublished average response time here.

support@mergemac.com

Set up your environment, then hand off the build

Already have a machine? Check its status in the portal. Need another build node? Choose a rental plan. Every machine is a dedicated physical Mac mini, not a virtual machine.