Support Center

Something wrong with your cloud Mac? Try the fix, then call in the team

Most issues — can't connect, need a reinstall, CI job failing — you can solve yourself in five minutes by following the steps below. When you do need a human, ticket and email support are open year-round, with 24/7 response for critical issues.

Open a Ticket — Priority Handling for Critical Issues Check the FAQ First
Four Channels

Pick the fastest route for how urgent it is

Self-serve docs are the fastest option, tickets cover everything, email is good for keeping a record, and the status page helps you first rule out "is this on our end?"

Documentation

Setup, reinstall, CI/CD, and troubleshooting guides all on this page — copy the commands and go.

Scroll down →

Ticketing System

Log in to the console to open a ticket — your instance details are attached automatically, and critical issues can be flagged as urgent.

Open a ticket in the console →

Email Support

support@hirevps.com — best for issues where you need to attach screenshots, logs, or other records.

Send us an email →

Status Page

Real-time availability for every region at a glance — check it before you report an issue and save yourself a round trip.

View live status →
Quick Start

Your first ten minutes with credentials in hand

Within 2 minutes of provisioning, you'll get SSH/VNC credentials in the console and by email. Follow these three steps and you'll be at the desktop and working within ten minutes.

1. First SSH Login

Your credentials include a hostname like jp1-1024.hirevps.com. Connect using your system's built-in terminal:

# replace host and user with your credentials
ssh omac@jp1-1024.hirevps.com
# first login: change your password
passwd

We recommend changing your password right after login, then uploading an SSH public key in the console and disabling password login for better security and convenience.

2. Enable VNC / Screen Sharing

Screen sharing is enabled by default at delivery. If you turned it off manually, one command over SSH turns it back on:

# enable macOS remote management (screen sharing)
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
  -activate -configure -access -on -restart -agent

On Mac, use the built-in Screen Sharing app; on Windows/Linux, any VNC client works — enter the hostname with port 5900.

3. Dev Environment Checklist

  • The delivered image comes with Homebrew, Git, and Xcode Command Line Tools preinstalled — run xcodebuild -version and brew --version in the terminal to confirm versions.
  • For CI/CD, run one full build first to establish a baseline — note cold-start and incremental build times, so you have something to compare against later.
  • Keep certificates and keys in a dedicated keychain and explicitly unlock it in your build scripts, so a locked graphical session doesn't break code signing.
  • Before decommissioning, sync your code and build artifacts back to your own repo or object storage — data is unrecoverable after a wipe (see the data boundaries in our Terms of Service).
Common Operations

Reinstalls, version switches, data migration — all a few clicks in the console

All three of these are fully self-service, no ticket needed. Reinstalls and version switches are free, with no limit on how many times you do them.

Reinstall macOS

Console → Your Instance → "Reinstall System," pick a version, confirm. The whole process takes about 15–25 minutes (actual time may vary).

Reinstalling wipes the entire SSD — push your code to a remote repo and copy off any build artifacts before you confirm.

Switch macOS Version

Choose between the current release and the previous major version (e.g., Sequoia / Sonoma); some regions also offer beta images — check the console listing for what's available.

Switching versions runs through the same reinstall flow and also wipes the disk. If you're doing multi-version compatibility testing, we'd suggest spinning up a separate day-rate instance instead and tearing it down when you're done.

Snapshots & Data Migration

Take a local APFS snapshot before a reinstall as a safety net; for moving data between machines, rsync is the way to go:

# create a local snapshot before risky changes
tmutil localsnapshot
# sync your workspace to the new machine
rsync -avz ~/work/ omac@new-host:~/work/

We don't access or back up any data on your machine (see our Privacy Policy), so make sure to sync anything important to a remote repo or object storage on your own — local snapshots are wiped along with everything else on reinstall.

CI/CD Integration

Turn this Mac into your build node

With dedicated hardware and root access, hooking into any major CI platform is just the standard official process — no proprietary workarounds needed. Pick the one you use:

Set Up a Self-Hosted Runner

On your repo's or organization's Actions settings page, choose "New self-hosted runner (macOS / ARM64)," then paste the download and setup commands it gives you into your cloud Mac's terminal:

# run these on your cloud Mac (values come from your Actions settings page)
./config.sh --url <your-repo-url> --token <runner-token> \
  --labels macos,arm64,hirevps
# install as a service so it survives reboots
./svc.sh install && ./svc.sh start

Then set runs-on in your workflow to [self-hosted, macos, arm64]. Dedicated hardware M4 hardware typically runs xcodebuild noticeably faster than hosted runners — actual gains depend on your project.

Troubleshooting

Three common issues — check these first

Spend two minutes running through the relevant checklist before opening a ticket — over half of all reported issues get resolved by step 2.

Can't connect to the machine (SSH timeout / VNC black screen)
  1. Check the status page to see if your region is operating normally — if it is, the issue is most likely on your end.
  2. Try ping on the hostname locally to check reachability, then try again on a phone hotspot to rule out your office network or ISP blocking ports 22/5900.
  3. Check the instance status in the console: if it shows "Running," try "Remote Restart" from the console first. If it's stuck starting up, wait 3 minutes and refresh.
  4. Check whether you've changed the SSH port or firewall rules (pfctl) — this is the most common way to lock yourself out. The console's "Rescue Terminal" lets you bypass the network and get back in to fix it directly.
  5. Still stuck after trying all of the above? Open a ticket, check "Can't connect," and we'll handle it as P1.
Builds getting slower (xcodebuild times climbing)
  1. First rule out changes on your end: after a dependency upgrade or a major Xcode update, the first build has to rebuild the index and cache from scratch — a one-time slowdown is normal.
  2. Run top -o cpu to check for a runaway process — Spotlight's initial indexing can max out CPU, which you can disable with mdutil -a -i off.
  3. Check whether CI is wiping DerivedData on every run — keeping the cache directory around usually cuts incremental build times significantly.
  4. Run df -h to check free disk space: write performance drops once SSD usage passes 90%, so free up space and compare again.
  5. Your machine is dedicated hardware, so there's no noisy-neighbor contention. If it's still slowing down after ruling out everything above, open a ticket with logs from two builds (before and after) and we'll dig into the hardware.
Disk full (No space left on device)
  1. Find the biggest offenders first: du -sh ~/Library/Developer/* — Xcode's DerivedData, old simulator runtimes, and Archives are usually the biggest culprits.
  2. Safe to clean up: rm -rf ~/Library/Developer/Xcode/DerivedData; remove unused simulator runtimes with xcrun simctl runtime delete.
  3. Local APFS snapshots also take up space — check with tmutil listlocalsnapshots / and remove old ones with tmutil deletelocalsnapshots.
  4. For CI machines, add a regular cleanup step to your pipeline instead of waiting until the disk fills up.
  5. Still tight on space after cleanup? Time to upgrade — you only pay the price difference for a bigger SSD. See the migration steps above, or just pick a larger tier on the plans page.
SLA & Response Times

Response commitments in writing

Tickets are ranked into three priority levels based on impact. You select the priority when you open the ticket, and we confirm it on our end. We only commit to what we can actually deliver.

Ticket priority levels and response time table
Priority Typical Scenario First Response Coverage
P1 Critical Machine unreachable, hardware failure, region outage ≤ 30 minutes 24/7, year-round
P2 Degraded Performance issues, stuck reinstall, intermittent network glitches ≤ 4 hours 24/7, year-round
P3 General Usage questions, billing inquiries, configuration advice ≤ 12 hours Business days

Uptime & Credit Policy

  • We commit to 99.9% monthly uptime per instance, with every region running 365 days a year and no scheduled downtime windows.
  • For every 0.1% actual uptime falls below our commitment, you get a service credit equal to 5% of that month's fee, capped at 100% of that month's fee for the affected instance.
  • Submit a credit request in the console with the outage timeframe, and we'll verify it against our monitoring data and issue the credit within 7 business days.
  • Downtime caused by force majeure or something on your end (e.g., accidentally deleting system files, breaking your network config) doesn't count toward credits — but we'll still help you fix it.

How to Get the Fastest Response

  • Open a ticket after logging in through the console — your instance ID and region are attached automatically, saving a round trip compared to email.
  • Be specific about "when it happened, what you were doing, and what error you saw," and paste the full error text rather than a screenshot — it significantly speeds up diagnosis.
  • For P1 issues, flag "Urgent" directly in the ticket rather than emailing — email is handled on the P3 timeline.
  • Full credit terms are in our Terms of Service, which governs in case of any discrepancy.
Running 365 Days a Year · No Scheduled Downtime

Service status and announcements, all on one page

Real-time availability, historical data, and incident announcements for our Singapore, Tokyo, Seoul, Hong Kong, and US West regions are all public on the status page. Any updates on service-impacting incidents are posted there too, in real time. Check it before reporting an issue — it'll help you immediately tell whether it's on our end or yours.

Open the Live Status Page Subscribe to Incident Alerts in the Console
  • JP TokyoSee status page for live availability and history
  • SG SingaporeSee status page for live availability and history
  • US-W West CoastSee status page for live availability and history

Guide doesn't cover your situation?

Log in to the console, open a ticket, and paste in the exact error. We'll take it from there.

Open a Ticket in the Console