From delivery to development

Can't connect to your Mac?
Start troubleshooting here

This guide covers connectivity and development setup for your dedicated cloud Mac. First, check the details in your console, then review your toolchain and task configuration. Your node is a dedicated physical machine, not a virtual machine, with both a graphical interface and command-line access.

Log in to the console for connection details New here? Rent a Mac now

Already placed an order? Open your instance details. Use the host address, username, port, and delivery status currently shown in the console.

First connection

Get your connection details, then choose how to connect

Remote desktop is useful for checking the system, setting up Xcode, and debugging the graphical interface. SSH is ideal for cloning code, running builds, and reading logs. Both connect to the same machine, so there’s no need to keep two copies of your project.

Graphical interface

Screen Sharing / VNC

Find the remote desktop address and credentials in your instance details in the console. On macOS, use Screen Sharing; on other systems, use a VNC-compatible client. Don’t confuse your SSH password with your separate VNC credentials.

  1. Copy the host address, remote desktop port, and username, checking for any extra spaces.
  2. Enter the address and port in your client. VNC commonly uses port 5900, but always use the port shown in the console.
  3. Authenticate as instructed in your delivery details. If authentication fails, check the username and credential type before trying again.
  4. Once connected, change the initial system password. If you have separate remote desktop credentials, update and store them securely as instructed for your instance.

If the desktop is laggy, lower the image quality and turn off unnecessary animations. Keep an SSH session open so you can tell network issues from graphical session issues.

Command line

SSH

Use your system terminal or a trusted SSH client. SSH commonly uses port 22; if your connection details specify a different port, include the corresponding -p option in your command.

  1. Get the host address, SSH port, and username from your instance details. Don’t guess the default account.
  2. Run ssh -p PORT USER@HOST to connect, replacing the uppercase fields with the values provided for your instance.
  3. The first time you see a host fingerprint prompt, verify it against trusted instance details. If the fingerprint changes unexpectedly, stop and submit a support ticket.
  4. After your first login, run passwd to change the initial password, then add your own SSH public key.

Once you’ve confirmed public key authentication works, you can adjust password login settings. Keep your current session open while making changes to avoid locking yourself out.

Start with the error—don’t keep resetting your machine
What you see What to check first Include in your support ticket
Connection timed out Check whether the instance has been delivered, the address and port are correct, and your local network or firewall allows outbound connections. Try from another network for comparison. Node, machine ID, connection method, and the time and time zone when the error occurred.
Authentication failed Check the username, credential type, and whether the password has changed. Never share passwords in logs or screenshots. The full error message, client, and authentication method. Do not include passwords or private keys.
SSH works, but the desktop is black Disconnect and reconnect the graphical session, and check client compatibility. Don’t stop any builds or tests that are running. Client version, a screenshot of the black screen, whether SSH works, and any recent system setting changes.
Host fingerprint changed Check whether there’s a confirmed machine replacement or system reset. Don’t delete the local fingerprint entry until the change is verified. Old and new fingerprints, machine ID, and the latest delivery notice.
Getting started

Spend about 4 minutes on these essential checks

These time estimates assume the environment is ready, the repository is small, and the network is working. They exclude large project downloads, Xcode installation, and dependency builds. Check first, then proceed—don’t trade away security for speed.

  1. 01

    Change your password and check the firewall

    About 1 minute

    Change the initial password and store your credentials securely. Enable or review macOS firewall rules, making sure your remote access service is allowed. Don’t disable all access controls before verifying your connection.

  2. 02

    Check Xcode and the command-line tools

    About 2 minutes

    Check the Xcode version in the graphical interface, then run xcode-select -p and xcodebuild -version. If your project requires a specific version, switch to the matching toolchain before building.

  3. 03

    Clone the repository and run a small task

    About 1 minute

    Set up repository credentials with the minimum permissions needed, then clone the code. Start with a small build or test to check dependencies, paths, and write permissions before launching the full pipeline.

You’re ready when you can log in again, the toolchain meets your project’s requirements, the code is readable, and the build output directory is writable. If any check fails, stop and fix it before moving on.

Migration & CI

Move your data, then your toolchain, then your tasks

Migrate in three stages to make issues easier to pinpoint. Don’t copy local caches, binaries built for an older architecture, and active signing credentials all at once. Your machine can keep a stable development environment, but you’ll need to configure task permissions yourself.

01 / DATA

Data

Use rsync or an external cloud drive to migrate projects and assets. Check available disk space first, then copy projects, assets, and archives in batches. Skip build outputs and caches that can be regenerated.

For the first rsync run, add --dry-run to preview the changes. Note that a trailing slash on the source path affects the destination directory structure. Don’t use options that delete destination files until you’ve checked the target contents.

Success looks like this: the project directory structure is intact, key assets are readable, and file counts or checksums match expectations.

02 / TOOLS

Toolchain

Check the versions of Homebrew, Xcode, the SDK, and your project dependencies. On Apple Silicon, Homebrew is commonly installed at /opt/homebrew. Don’t reuse absolute paths from your local machine.

Reinstall dependencies from your project’s lockfiles. Check signing certificates, their private keys, and provisioning profiles separately. Having a graphical interface available doesn’t mean a headless CI process has signing permissions.

Success looks like this: version checks work, a local build passes, and the certificate and provisioning profile match the project.

03 / CI

CI setup

Register a self-hosted GitHub Actions or GitLab Runner. Use a dedicated system user and a least-privilege token, and match runner labels to the right project jobs.

Start with a validation job that reads code but doesn’t sign it, then add tests and releases. Check the runner process’s PATH, working directory, and Keychain access. Don’t rely on tests from an interactive terminal alone.

Success looks like this: jobs are picked up, logs are complete, and the runner reconnects as expected after a restart.

An executor can access every repository it’s configured to use—and the code in them. Don’t run untrusted jobs in the same environment as release signing. A shared project doesn’t mean everyone should use the same system account.

Xcode & signing

The certificate is on the machine—but the process needs access too

For signing errors, check four things first: the certificate, private key, provisioning profile, and process permissions. Don’t keep importing the same file, and never put private keys in a repository or support ticket attachment.

Imported a certificate but still can’t find a signing identity?

In Keychain Access, check whether the certificate has its associated private key. A certificate file without its private key can’t sign builds. If you’re importing a file that includes a private key, check the export password and destination Keychain, then verify the certificate hasn’t expired.

Then run security find-identity -v -p codesigning to see the signing identities available to the current user. If the command output doesn’t match the graphical interface, check the running user and Keychain search list first—not the machine model.

Certificate is valid, but the build says the provisioning profile doesn’t match?

Check the project’s Bundle Identifier, team ID, build type, and provisioning profile expiration date. Development and distribution builds may use different profiles. For device testing, make sure the target device is included in the relevant profile.

Choose one specific build configuration and use it to verify your setup. In projects with multiple targets, check signing settings for each one so the app and its extensions don’t use different teams or expired profiles.

Signing works in Terminal but fails in CI?

CI may run as a different user, with different environment variables, or in a headless session. Check which Keychain it uses, whether it’s unlocked and contains the signing identity, and whether the signing tool is allowed to access the private key.

Store required credentials in your CI’s protected secrets—not in scripts. Run a minimal signing test as the runner user and note where it fails. For support, share only redacted errors; never send Keychain or export passwords, or private keys.

How do we manage permissions when multiple people share one physical node?

Create a separate system user for each person and assign directory and Keychain permissions by role. Run automated jobs under a dedicated runner user. When handing off, make clear who is using the graphical session; don’t switch toolchains or clean shared directories while someone else is building.

These steps reduce accidental changes, but users on the same machine still share its CPU, memory, and disk. For strong isolation, untrusted workloads, or reliable parallel releases, use separate nodes.

Performance & storage

Find the bottleneck before upgrading

Slow builds don’t always mean the chip is the problem. Check memory pressure and CPU usage in Activity Monitor, then review disk space, dependency downloads, and concurrent tasks. Compare results using the same project and build configuration.

Simulators and build caches are filling the disk. What should I clean up first?

First run df -h to check available space. In Xcode, review simulator runtimes and build archives you no longer use. DerivedData can be regenerated, but the next build will need to rebuild its caches. Pause any active project tasks before cleaning up.

Run xcrun simctl list devices to check your devices. Once you’ve confirmed you no longer need them, run xcrun simctl delete unavailable to remove unavailable devices. Deleting a device may also delete its simulator test data, so export anything important first.

When should I consider a +1TB SSD or +2TB SSD?

Consider an upgrade if projects, multiple simulator runtimes, container images, and assets need to stay on disk, and storage remains close to capacity even after clearing regenerable caches. A +1TB SSD costs $2.2/day and a +2TB SSD costs $4.4/day. Check the order configuration for other billing periods.

More disk space solves capacity issues, but doesn’t replace memory. If you run many tasks at once and memory pressure stays high, reduce concurrency or consider a more suitable tier.

Which of the three tiers should I choose for builds or ML workloads?

Hold 16 comes with an M4, 16GB memory, and a 256GB SSD—ideal for light builds and single-project CI. Hold 24 has an M4, 24GB memory, and a 512GB SSD, with more room for everyday Xcode development, multiple simulators, and UI testing.

Hold Pro 64 comes with an M4 Pro, 64GB memory, and a 2TB SSD for large projects and MLX experiments. Whether a model runs depends on its size, quantization, and context requirements—always benchmark rather than relying on the machine’s name.

What workloads benefit from Thunderbolt 5 clustering?

It’s suited to workflows that use multiple nodes and support cross-machine collaboration. This add-on costs $1.5/day per machine. Before ordering, share the number of nodes, data transfer method, and application requirements so support can confirm compatibility.

Clustering doesn’t combine multiple machines into one Mac with more memory, or automatically split ordinary build tasks across them. Confirm that your application supports distributed work before adding it.

Billing & renewals

Check your order and billing period before renewing

Rent by the day, week, month, or quarter; all charges are in USD. Check your order, expiration date, add-ons, and payment status in the console. After paying, verify the renewal there rather than relying only on a message from your client.

Where can I check my expiration date and renewal status?

Log in to the console to check your subscription’s expiration date, invoices, and renewal options. Also make sure your account email can receive messages and watch for expiration reminders. Reminder timing may vary, so don’t rely on a single alert to renew at the last minute.

After payment, return to the original subscription and check the new expiration date. If the invoice is paid but the subscription dates haven’t changed, submit the invoice number and payment record. Don’t pay the same invoice twice.

Will my connection details change after renewal?

For a routine renewal of the same instance, keep using the current connection details in your instance information. A renewal doesn’t reset the system. If your machine is replaced, rebuilt, or otherwise changed, use the new connection details and service notices in the console.

If your rental has ended and the instance is being reclaimed, renewal won’t recover your data. Export projects, certificate backups, and other irreplaceable files before expiration. You can’t undo a disk wipe after reclaim by placing a new order.

What payment methods do you accept?

We accept only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe), with all charges in USD. Available payment gateways are determined by the response from our backend.

With USDT-TRC20, check the network, address, and amount shown on the payment page. For card payments, complete any verification required by the payment gateway. For payment inquiries, provide the transaction hash or invoice number—never your full card number, security code, or wallet private key.

Need a higher tier or extra storage? Should I place a new order?

First note your current instance ID, the configuration you want, and when your tasks can be paused. Then submit a support ticket in the console. Confirm before proceeding whether migration is needed, whether your existing connection details can be retained, and when the changes will take effect.

An add-on disk affects data paths, so move your data and check your app configuration before canceling it. Don’t assume changes happen immediately, preserve all data automatically, or trigger an automatic refund. The order terms and confirmed outcome will determine how your request is handled.

Still stuck? Hand over the details

For an issue with an existing instance, log in to the console and submit a support ticket. Include your machine ID, node, the time and time zone of the error, when it last worked, and the steps you’ve already tried. Redacted logs are much more useful than “I can’t connect.”

Check your support ticket in the console for updates. Response times depend on the issue and the scope of troubleshooting; we don’t promise a fixed number of minutes on this page. For presales, team setups, or login issues, contact support@vpshold.com.

Log in to the console to submit a ticket Contact & support details