This page covers the troubleshooting commands for the three most common issue categories: connectivity, builds, and networking. About 80% of our support tickets get resolved this way in under 10 minutes — for everything else, incident tickets get a first response within 2 hours.
There are only two channels for human support: console tickets and email. Both go straight to the on-call engineer — no scripted support layer in between.
Best for: instance failures, refund requests, migration scheduling — anything tied to a specific machine. Path: Log in to the console → Tickets → New. The full process is logged, and you'll get an email whenever the status changes.
First response ≤ 2 hours
Best for: can't log in to the console, account security concerns, invoices, and business inquiries. Email support@armmini.com — include your account email and instance ID to skip a round of back-and-forth.
First response ≤ 8 hours
The troubleshooting guide on this page covers connectivity, builds, and networking; Remote Access has full VNC/SSH walkthroughs and a troubleshooting quick-reference; FAQ covers billing and permissions. Checking the docs first is usually faster than waiting on a response.
| Severity | Typical Scenario | Ticket First Response | Progress Updates | Recommended Channel |
|---|---|---|---|---|
| P1 | Instance unreachable / node-level outage | ≤ 30 min | Every 60 minutes | Console ticket |
| P2 | Partial feature outage (e.g., VNC works but SSH doesn't) | ≤ 2 hours | Every 4 hours | Console ticket |
| P3 | Usage questions, configuration help | ≤ 4 hours | As progress is made | Ticket or email |
| P4 | Feedback, business inquiries & partnerships | ≤ 24 hours | As progress is made |
Our support team runs shifts across UTC+8 and UTC-8, and SLAs are counted in calendar hours — weekends and holidays included. We determine the severity level based on impact, so you don't need to tag it yourself.
Reboots, reinstalls, and credential resets don't need a human in the loop. Power actions in the console go through an out-of-band channel, so they still work even if the system is completely frozen — one of the perks of a dedicated physical machine.
Path: Console → Instance → Power → Reboot. This power-cycles the whole machine and takes about 90 seconds; disk data is untouched, but unsaved work will be lost. This is the first thing to try for VNC black screens or an unresponsive system.
Path: Console → Instance → System → Reinstall. Choose your target macOS version from the list; a reinstall wipes the whole disk and takes 25–40 minutes, with new VNC/SSH credentials emailed to you afterward. One free reinstall is included per billing cycle.
Path: Console → Instance → Access → Reset VNC Password. Takes effect immediately; the new password is shown on-screen only once, so save it right away. Use this if you've forgotten your password, suspect a leak, or are handing off the machine — it doesn't affect SSH access or data on the instance.
Path: Console → Instance → Access → SSH Public Key. Paste in a new key and it's written to authorized_keys within 60 seconds; you can also check a box to revoke the old key at the same time. Supports ed25519 and RSA (≥3072 bits), with up to 5 keys per instance.
Follow the steps in order — each one gives you output you can check against. If you're still stuck at the end, paste the output from the last step into a ticket and we'll pick up right where you left off.
Symptom: The VNC client shows as connected, but the display is solid black or stuck on a gray screen, with no response to mouse or keyboard.
$ sudo launchctl list | grep -i screensharing
$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
Done.
$ sudo pmset -a displaysleep 0 sleep 0Symptom: ssh hangs for a while before returning Operation timed out, or immediately returns Permission denied.
sudo pfctl -d to temporarily disable the rules before fixing them.$ ping -c 5 <instance-public-ip>
$ chmod 600 ~/.ssh/id_ed25519
$ ssh -vvv -o ConnectTimeout=10 dev@<instance-public-ip>
$ sudo pfctl -sr | grep 22Symptom: xcodebuild fails in CI with errSecInternalComponent or User interaction is not allowed, but local GUI builds work fine.
$ security unlock-keychain -p "$KEYCHAIN_PASS" ~/Library/Keychains/login.keychain-db
$ security set-key-partition-list -S apple-tool:,apple: -s -k "$KEYCHAIN_PASS" ~/Library/Keychains/login.keychain-db
$ security find-identity -v -p codesigning
1 valid identities foundDownload the arm64 macOS runner package from your CI platform's runner settings page, then run the following commands in an SSH session on your instance.
$ mkdir ~/actions-runner && cd ~/actions-runner
$ tar xzf actions-runner-osx-arm64.tar.gz
$ ./config.sh --url <repo-or-org-url> --token <registration-token> --labels self-hosted,macos,arm64
$ ./svc.sh install && ./svc.sh start
√ runner service startedInstall it as a launchd service with svc.sh instead of running run.sh in the foreground: it auto-reconnects after disconnects and comes back up automatically after an instance reboot — no extra keep-alive script needed. Registration tokens are only valid for an hour, so just regenerate one if it expires.
$ brew install gitlab-runner
$ gitlab-runner register --executor shell --url <your-gitlab-url> --token <auth-token> --tag-list macos,xcode,arm64
$ brew services start gitlab-runner
Successfully started `gitlab-runner`Set the executor to shell so builds run directly in the macOS user session with full access to the Xcode toolchain and simulators. We recommend keeping concurrency at 1: on Apple Silicon, one job that has all performance cores to itself finishes faster than two jobs fighting over them.
Don't mix CI certificates into the login keychain. Create a separate build.keychain with a 21600-second (6-hour) timeout, and run an unlock at the start of every job — this eliminates signing prompt issues at the root.
Pass -derivedDataPath to xcodebuild pointing to a fixed directory outside the job's working tree. On a dedicated physical machine, the cache persists on disk across jobs, and incremental builds on large Swift projects come in 40–70% faster than full builds.
Use xcrun simctl create to pre-build the device types you use most and leave them in place. UI tests skip the simulator cold-start, typically saving 60~90 seconds per job. Since the instance is never reclaimed, a one-time setup lasts indefinitely.
$ security create-keychain -p "$PASS" build.keychain
$ security set-keychain-settings -lut 21600 build.keychain
$ security unlock-keychain -p "$PASS" build.keychain
$ xcodebuild -scheme App -derivedDataPath ~/ci-cache/DerivedData buildEach of our five locations has a test endpoint sharing the same rack-level egress as your production instances, so testing it is effectively testing your instance. See the node latency table on the Remote Access page for reference figures by region.
| Node | Test Endpoint | Region | Notes |
|---|---|---|---|
| Tokyo | ping.tyo.armmini.com | East Asia | Shares egress with Tokyo instances — latency here reflects real-world experience |
| Seoul | ping.icn.armmini.com | Northeast Asia | Shares egress with Seoul instances |
| Silicon Valley | ping.sjc.armmini.com | US West Coast | Shares egress with Silicon Valley instances |
$ ping -c 20 ping.tyo.armmini.com
20 packets transmitted, 20 received, 0% loss
$ mtr -rwzbc 100 ping.tyo.armmini.com > mtr-report.txt
-r report mode, -c 100 samples 100 packets, about two minutesmtr -rwzbc 100 locally against the matching node's test endpoint and save the report.We handle issues on our data center egress side the same day; packet loss on cross-network middle-mile paths needs a hop-by-hop check with upstream providers, which usually takes 1–2 business days to pin down, with progress updates posted continuously in the ticket.
All nodes run 365 days a year with no service interruptions you'd need to schedule around; hardware swaps at the node level are handled with standby machines and don't eat into your usage time. When something does go wrong, here's the process — fully auditable from start to finish.
Monitoring alert fires, on-call SRE steps in. All five nodes are staffed 24/7 in rotating shifts.
Impact scope confirmed; first incident email goes out to affected users: symptoms, scope, estimated recovery time.
Progress update emailed every 60 minutes until resolved — no "silent fix" here.
Downtime is calculated against the monthly 99.5% uptime commitment; any owed service credit is applied to your account automatically — no need to request it.
Postmortem published: root cause, full timeline, and follow-up actions, sent by email and posted to the console announcements.
Specific credit tiers and exclusions (force majeure, user-caused issues) are covered in Section 5 of the Terms of Service. If you detect an outage on your end but haven't received an incident email from us, open a P1 ticket directly and we'll cross-check it against your monitoring data.
Switching nodes, or moving over from another provider or a local Mac to ArmMini — our engineers provide free one-on-one assistance. Here's exactly what's covered, so you know what to expect before you schedule.
$ rsync -avzP --exclude 'Library/Caches' -e ssh ~/work/ dev@<new-instance-ip>:~/work/
-P supports resume on interruption; Tokyo→Seoul within-region tests show roughly 45~80MB/s
sent 182.4G speedup is 1.31Paste the output from your last step into a ticket, and the on-call engineer will pick up right where you left off. Incident tickets get a first response within 2 hours — weekends and holidays included.