Check prerequisites and outcomes for each task

From Order to Your First Desktop Session

One practical guide for teams across Asia-Pacific and North America. Check your order and node before connecting to your dedicated physical Mac. If a task stalls, note when it happened and the error message, then troubleshoot the relevant step.

If you've already ordered, open your instance details in the console. For your first session, you'll need a modern browser and a stable internet connection.

First connection

Match your order to the node and desktop

Billing starts when your payment succeeds. Before opening the desktop, check your instance details. A payment confirmation does not mean the desktop is ready to connect.

  1. Sign in to the account you ordered with

    Prerequisites: You've placed an order and can access the email address used to place it. Open the console, sign in with that email, then go to your instance list.

    Done when: You can find the matching order and instance. If the list doesn't look right, first check the email you're signed in with, the payment status and your order records. Keep your order number and submit a support ticket; don't place another order as a workaround.

  2. Check the region and status

    Prerequisites: Your instance appears in the list. Open its details and check the instance ID, selected node and current status. The live status shown in the console is the source of truth.

    Done when: The node matches your order and the details show an available connection option. If the instance isn't ready, check the status message. If its status doesn't match the order, save the exact message and time; don't trigger multiple actions in quick succession.

  3. Open macOS in your browser

    Prerequisites: The instance details show that a connection is available. Click “Open Desktop” and allow your browser to open a new tab. Use the full macOS desktop in that tab—no desktop client needed.

    Done when: The desktop appears and responds to keyboard and mouse input. If no new tab opens, check whether your browser blocked the pop-up. If the page opens but the connection fails, note the message and follow the network troubleshooting steps below.

Terminal workflows

Use SSH for builds and scripts

Use the browser desktop for graphical work and SSH for terminal commands, build scripts and log checks. Both connect to the same dedicated physical Mac—not separate, isolated environments.

Get connection details from your instance

Sign in to the console, open the target instance and get its current connection address, username, port and authentication details. Don't use another instance's address, an old connection record or a sample command as your own settings.

Run the command format shown on the right in your local terminal, using the actual details for your instance. Replace each field inside angle brackets in full; don't type the brackets. Use the authentication method shown in your instance details.

If asked to verify the host identity on your first connection, check the instance and connection details. If saved host information suddenly changes, don't skip verification. Once you've confirmed the target, follow the terminal prompt to continue.

Done when: Your terminal opens a remote session, runs basic commands and confirms your current user and working directory. Before starting a long-running task, check how much service time remains and where its logs will be saved.

SSH command format

ssh -p <port> <username>@<host>

After logging in, check the execution environment:

whoami
pwd
sw_vers
xcode-select -p

These commands show the user, directory, system version and command-line tools path; they don't install software. If a build fails, keep the relevant output and error logs together. Don't expose passwords, private keys or other credentials in screenshots.

First, pinpoint what's slowing down

Troubleshoot distance, network access and migration in order

Desktop lag, slow file transfers and long build times are different issues. Note which operation is slow, then change one factor at a time to compare. Avoid changing the network, tools and project all at once.

  1. Check the distance between the user and the node

    Start with the location of the person using the desktop, not just where the company is registered. Choose from five nodes: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong and the US West Coast.

    For graphics-heavy work, consider a nearby node first. For builds, also consider the routes used to transfer code, dependencies and build artifacts. Node locations are a guide; actual performance depends on your network. We don't publish unmeasured latency figures.

  2. Change just one local network condition

    Pause large uploads, downloads and other bandwidth-heavy tasks. Keep the same instance, browser and operation, then check desktop responsiveness. If possible, compare with another trusted network.

    Record the network type before and after switching, whether you use a proxy, when the lag occurred, and whether SSH was affected too. If only one browser tab is misbehaving, check the browser message. If only builds are slow, check the build logs and project tasks.

  3. Test a new instance in the target region

    If the primary user has moved to another region long term, you can create an instance on a closer node, transfer the project using the migration checklist and test the desktop and builds. Changing nodes does not move an existing instance to another region in one click.

    Keep your original data and a rollback option until the new instance passes testing. Confirm that the code, tool versions and artifacts all match before arranging the handoff. Each rented instance is billed separately, so check your budget before adding one.

Move your local setup to the cloud

Transfer your data, align your tools, then connect CI

Migration isn't complete just because the files have transferred. The target machine must be able to build a verifiable artifact from a specific commit. Follow these three steps in order, moving on only when each stage passes.

01 · Data

Transfer your project and signing materials

Prerequisites: The code to migrate is committed locally, and you have permission to use the relevant signing materials. First, note the repository URL, branch, commit ID and location of any untracked assets.

  • Clone the project repository and verify the branch and commit ID.
  • Transfer project resources, signing certificates and provisioning profiles.
  • Use a controlled method to transfer sensitive materials. Don't put them in a public repository or support-ticket screenshot.

Pass criteria: The project opens, all resources are present, and the build process can access the required signing materials.

02 · Toolchain

Match versions between local and cloud environments

Prerequisites: You've recorded the versions of Xcode, command-line tools and dependency managers that work locally. Check the cloud environment first, then install or switch to the versions you need. Don't assume “latest” means “matching.”

  • Check the Xcode version and selected command-line tools path.
  • Set up the dependency manager and runtime required by the project.
  • Use the existing dependency lockfile and save a complete build log.

Pass criteria: The same commit builds manually on the target machine, and the log identifies the tool versions and artifact.

03 · CI setup

Register your verified machine as a build runner

Prerequisites: A manual build has passed, and you have permission to configure your team's CI system. Register the machine with your team's CI tool and point automated jobs to the target environment.

  • Set the execution user, working directory and required environment variables.
  • Configure credential access, job labels and artifact paths.
  • Run a test job before moving your production pipeline over.

Pass criteria: The CI job completes, and its logs, artifacts and commit ID are traceable and reproducible by the next team member.

Cross-time-zone handoffs

Leave the context the next shift needs

Each Mac mini is assigned to one customer and doesn't share its CPU or memory with other customers. Your team still needs to coordinate access: a dedicated machine doesn't prevent team members from overwriting each other's changes to the same environment.

A workspace scene showing planning and note-taking for a cross-time-zone task handoff
Keep handoff notes up to date as the task progresses; “The machine is ready” isn't enough.

Before you step away, document these four things

  • Code location: Commit completed changes and note the repository, branch and commit ID. List uncommitted files separately so the next person doesn't overwrite them by mistake.
  • Running tasks: List builds, scripts and processes still running, along with their log locations and whether they can be stopped. Closing the browser does not stop a task.
  • Environment changes: Record changes to Xcode, dependencies, environment variables and the working directory. Before changing a global tools path, make sure no other task depends on the existing path.
  • Next steps: Write down the next command, expected artifact and how to verify it. Include the time zone of the handoff.

Use a full timestamp: date, time and UTC offset. Avoid vague notes like “last night” or “this morning.” If team members span Asia-Pacific and the US West Coast and often work at the same time, consider separate nearby instances; keep environments consistent with version records.

Service periods and billing

Check renewals before expiry and costs before making changes

Choose a billing period of a day, week, month or quarter. Billing starts once payment succeeds. All five nodes have the same price. Check the plan catalog for configuration and add-on prices, then review your order before paying.

Renewals and data backups

Check the instance expiry date and available renewal options in the console. Pay before expiry and confirm that the service time has been updated. A created invoice doesn't mean the renewal is complete.

To change a future billing period, first check the options in the console. If you're unsure, submit a support ticket with the instance ID and your preferred period. Back up your code, signing materials and build artifacts before expiry; don't rely on the instance disk as your only backup.

Add-ons and configuration changes during a billing period

Available add-ons include +1TB SSD, +2TB SSD and Thunderbolt 5 daisy chaining. Add-ons are billed for the same period as the host. Check the console for currently available options and when changes take effect.

Before adding or cancelling an add-on or changing your configuration mid-cycle, check the amount and effective date in your order. Don't assume charges are prorated by the remaining days or that a cancellation request triggers an immediate refund. Back up your data before making changes that affect it.

Payments, transaction records and invoice enquiries

We accept only USDT-TRC20 and Visa, Mastercard or Amex via Stripe. All payments are settled in US dollars (USD). Available payment gateways are confirmed by the backend.

If a payment fails, keep the order number, amount, payment time and transaction record. Check the invoice status, then submit a support ticket. For an invoice or billing document, include the relevant order and requested billing details; support will confirm what can be provided. Never share your full card number or security code.

Include your troubleshooting notes

Give support enough detail to reconstruct what happened

Sign in to the console to submit a support ticket, and organize the details in the order below. Tickets are handled in the order received. We don't promise response times that haven't been confirmed.

Checklist: what to include

Instance and node
Instance ID, selected node and related order number—not just the Mac model.
When it happened
Start time, whether the issue is ongoing, and when it last occurred. Include the UTC offset.
What you did and expected
Which page or command you started with, what you expected and what actually happened.
Error and screenshots
Include the exact error, relevant logs and screenshots. Hide passwords, keys and sensitive project details.
Troubleshooting steps taken
Note whether you changed networks, checked the instance status or reran a command to reproduce the issue. This helps avoid repeating steps.

We guarantee 99.9% availability, equivalent to about 43 minutes of downtime every 30 days. To request service-time compensation, submit a console ticket with the instance ID and downtime period. Downtime beyond that allowance is compensated with service time on a pro-rata basis.

Include the instance and time period in your ticket

For existing orders, submit a ticket through the console. For pre-sales node recommendations or help signing in, see our contact details and email support@macudp.com.