First connection
Verify the node, source address, and access method. Complete your personal session first, then hand it over to team members.
Connect, Build, Troubleshoot
A clear next step from first connection to reliable Cloud Mac operation
Confirm the access route and security boundaries first, then configure Xcode, Runner, MLX, or your media workflow. When issues arise, isolate them layer by layer across networking, authentication, storage, toolchains, process resources, and regional routing instead of changing several variables at once.
Standard provisioning takes about 4 minutes. Actual node and order availability is determined by the live status shown in the console.
SUPPORT / RUNBOOK
Task Delivery & Troubleshooting Board
Actionable steps
Build & run
Pin tool versions, cache directories, and concurrency limits so Xcode or Runner jobs run consistently.
Diagnose issues
Keep the time range, exact error text, resource metrics, and reproduction steps, then submit a ticket through the console.
Dedicated Apple Silicon physical node
Not a virtual machine
Runs 365 days a year
Recommended reading order
Quick-start index
Five steps are arranged by dependency. Each step's records become inputs for the next; teams should not skip key rotation or access revocation.
-
01
Place your order
Choose the model, rental term, node, and storage add-ons. After payment, wait for the console to return the order status. Do not use an old screenshot to judge current availability.
-
02
Receive access credentials
Verify the instance, node, and access instructions in the console. Store credentials only in a controlled password manager; never forward them to group chats or commit them to a code repository.
-
03
Complete the first login
Establish a Remote Desktop or SSH session from a trusted network. Record the first connection time, client version, and public source address to create a comparable connection baseline.
-
04
Rotate keys
Create your team's SSH keys and least-privilege accounts. Verify the new route works before revoking temporary access materials, avoiding lockout caused by deleting before verifying.
-
05
Complete the team handoff
Hand over the task, branch, cache state, running processes, and output location—not personal credentials. Assign the next operator and responsibility for exporting data before the rental ends.
Before connecting
Four connection paths, each with its own minimal checklist
When a connection fails, first identify which path you are using. Remote Desktop, SSH, file transfer, and firewall allowlists have different checks and should not be investigated as one issue.
Graphical session
Secure Remote Desktop
Use a client that supports encrypted connections and test first from one trusted network. Record the client version, display resolution, keyboard layout, and whether a proxy network is used.
- Use one display and the default resolution for the first connection
- Confirm clipboard and file mapping comply with team policy
- Keep a continuous test window when input latency is abnormal
Suitable for Xcode, Final Cut Pro, and graphical administration
Command line
SSH
Assign each operator a separate key and verify instance details before the first connection. Automation should use a dedicated account, not a personal interactive session.
- Store private keys on controlled devices and restrict file permissions
- Maintain separate authorized public keys for team members
- Keep verbose output on connection failure, but remove sensitive content
Suitable for automation, log checks, and remote commands
Data channel
File transfer
Use resumable tools for large files and separate directories for inputs, intermediate files, and outputs. Transfer a small sample to verify permissions and disk space before starting the full sync.
- Compare file counts and checksums before and after transfer
- Keep models, media, and build caches in separate directories
- Do not overwrite files directly in an active cache directory
Suitable for transferring models, media, build artifacts, and logs
Access boundary
Firewall allowlist
Allow only confirmed public source addresses and required ports. When a home or mobile network address changes, update the rule rather than expanding it to an uncontrolled range.
- Record office networks, Runner, and operations egress separately
- Set a clear revocation time for temporary sources
- Test once from an allowed source and once from a blocked source after changes
Suitable for fixed office egress and controlled automation networks
Continuous integration
Turn your GitHub Actions self-hosted Mac Runner into a recyclable job
Runner stability depends on pinned versions, concurrency limits, cache ownership, and post-job cleanup. Do not let the previous job's state become a hidden dependency for the next one.
Labels should describe verifiable capabilities
Labels should cover chip architecture, major Xcode version, purpose, and queue boundaries. Do not use a temporary project name as a long-term capability label, or scheduling rules will become inaccurate as projects change.
- Registration method
- Dedicated to an organization or repository
- Runtime account
- Separate least-privilege account
- Validation action
- Run one test job with no sensitive information
Limit concurrency first, then observe resource peaks
Start with a single-job baseline and record CPU, unified memory, disk writes, and build duration separately. Increase concurrency only when jobs are independent and peak usage still has headroom.
- Dependency cache
- Key by lockfile and tool versions
- Derived data
- Isolate by project and set a cleanup limit
- Concurrency decision
- Decide using peak resources and queue wait time together
Keep signing materials out of shared caches
Inject sensitive materials only during the required job stage. After completion, revoke temporary files, environment variables, and background processes. Success and failure paths must run the same cleanup routine.
- Sensitive materials
- Separate permissions and lifecycle
- Retry after failure
- Clean up leftovers before re-queueing
- Rental end
- Revoke the Runner, keys, and access rules
Development environment
Track tool versions, installation sources, and cache directories
Record the current state before upgrading. For continuous-build hosts, stable and reproducible versions are usually more valuable than following the latest release.
| Tool | Initial setup | Routine maintenance | Check first when issues occur |
|---|---|---|---|
| Xcode | Pin the major version and record the command-line tools selection and first-launch status. | Preserve project compatibility results before upgrading and isolate DerivedData by project. | Selected path, SDK, simulator state, free disk space, and complete build logs. |
| Homebrew | Install with one controlled account and save the dependency list and required version constraints. | Review changes before updating; do not upgrade dependencies during a build job. | Path priority, directory ownership, architecture match, and formula version. |
| Ruby | Use the version declared by the project and lock Bundler and dependency files. | Cache reusable dependencies, but do not mix incompatible Ruby versions. | Interpreter path, Gem install directory, lockfile, and native extension build output. |
| Node.js | Pin the runtime and package manager versions per project and enable lockfile verification. | Cache downloaded content rather than opaque work directories; regularly clear invalid caches. | Node path, package manager version, lockfile differences, and native module architecture. |
| Container alternative | Run Linux container steps in an external Linux environment; let the Mac node handle macOS-specific builds and tests. | Use scripts to standardize inputs and artifact formats, reducing manual transfers between platforms. | Platform assumptions, file permissions, line endings, architecture, and artifact transfer path. |
| Build cache | Create cache keys from the project, branch strategy, tool versions, and lockfile. | Set capacity thresholds and cleanup order: delete regenerable caches first, then working files. | Hit rate, directory permissions, remaining space, file count, and concurrent writes. |
High-memory & large-file tasks
Manage memory, storage, and transfer paths together for MLX inference and media production
Both task types can occupy unified memory for long periods and produce large outputs. Before starting, define the input files, temporary directory, completion criteria, and transfer method.
MLX inference
Run a small-batch baseline after storing the model
Place model files, quantized versions, input samples, and results in identifiable directories. Run a small batch first, recording load time, peak unified memory, per-inference time, and output size before choosing batch size and concurrency.
- File preparation:Verify model file integrity and reserve space for the model, cache, and output together.
- Resource monitoring:Watch memory pressure, swap activity, disk I/O, and process duration together.
- Keep long jobs alive:Use resumable task management and emit stage progress and intermediate results.
- Return results:Generate a manifest and checksums first, then transfer the results; never judge completion by filename alone.
For 64GB high-memory tasks, consider VPSGit M4 Pro: M4 Pro, 64GB, 2TB.
Media production
Sync proxy media, project files, and deliverables separately
When using Final Cut Pro remotely, validate input latency, preview smoothness, and audio-video sync with a short proxy clip first. Confirm free disk space and the transfer time budget before uploading the full media set.
- Media sync:Keep original media, proxy files, and project files in separate directories to avoid overwriting media in use.
- Editing baseline:Record Remote Desktop resolution, network route, and playback quality for comparison.
- Export management:Confirm the target format, temporary space, and naming rules before export; retain stage logs for long exports.
- Deliverable transfer:Transfer a small sample for approval first, then send the final files and checksum information. Clean up regenerable files afterward.
For large media sets, choose +1TB SSD or +2TB SSD and confirm export time before starting the task.
Layered troubleshooting
Validate one layer at a time and record every result
First determine whether the issue is local, in the connection path, or inside the node. Record whether symptoms change after each step; do not upgrade tools, change networking, and clear caches in the same round.
-
01
Network
Test basic connectivity, packet loss, and jitter from the same source, then retest from a known-stable network. Record the client network type, proxy usage, and the time range when the issue occurred.
-
02
Authentication
Confirm the current authorized account and key. Check local file permissions, authorization scope, and the latest rotation record. Never put credential contents in a ticket.
-
03
Storage
Check free capacity, directory ownership, file count, and the source of large-directory growth. When builds fail, also check temporary, cache, and output directories.
-
04
Build toolchain
Record Xcode, SDK, Ruby, Node.js, package manager, and dependency lockfile versions. Compare them with the last successful job; do not start with a global upgrade.
-
05
Process resources
Observe CPU, unified memory, swap activity, disk writes, and leftover child processes. Distinguish a one-time peak, sustained usage, and resources not released after task completion.
-
06
Regional routing
Compare the same client and operation during similar time windows. Do not mistake different task loads for regional differences. For cross-region migration, reconfirm directories and schedule data transfer.
Before submitting a ticket
Turn reproducible information into one diagnostic sheet
Tickets are handled by impact scope and order status. Complete information reduces back-and-forth, but remove keys, access passwords, signing materials, and business data.
- Order ID, selected node, and model
- Issue start time and duration
- Affected connection method or job stage
- Shortest reproducible procedure
- Exact error text and necessary log excerpts
- Checks completed and the result of each step
Service availability metric
99.9%Service availability target
All nodes operate normally 365 days a year. Availability is calculated within the scope defined by the service terms; user actions, third-party dependencies, and uncontrollable events are handled as specified there.
Status record for the past 90 days
Shown in three consecutive 30-day periods. Specific events and the latest status are determined by the console.
Past 30 daysCurrent period
Updated after events are confirmed
Days 31–60Historical period
Archived by service-event criteria
Days 61–90Historical period
Event impact scope retained
Service credits
When the conditions in the service terms are met, you may request service credits for the affected period. Include the order, impact window, and verifiable symptoms; eligibility and credit amounts are governed by the service terms.
Secure operations
Assign a clear owner from node access through rental end
Security is not a one-time setup. Create checkpoints for accounts, permissions, keys, sensitive materials, backups, and revocation, and verify each item during team handoffs.
Separate accounts
Each operator uses an identifiable account; personal sessions are never shared. Automated Runners use service accounts separate from human operations.
Check: each person maps to one account
Least privilege
Grant only the directory, command, and network access required for the current task. Temporary permissions must state their purpose and revocation time.
Check: no long-term elevated access without a purpose
Key rotation
Rotate keys immediately after membership changes, device loss, or permission-boundary changes. Verify the new key first, then revoke the old key and record the result.
Check: the authorization list matches the actual configuration
Sensitive material cleanup
Clean signing files, temporary tokens, environment variables, and sensitive log excerpts according to the task lifecycle. Keep them out of shared caches.
Check: cleanup runs on both success and failure paths
Back up before ending
Before the rental ends, export source changes, build artifacts, model results, media projects, and necessary logs, then verify the backup is readable.
Check: backup location and verification result are recorded
Revoke access
After the task, revoke accounts, public keys, Runner registration, allowlists, and temporary shared paths, and confirm background processes have stopped.
Check: all external node entry points have been reclaimed
Ready to begin
Choose a model and node, then follow this runbook to complete delivery
All three tiers of dedicated Apple Silicon physical nodes are available for daily, weekly, monthly, or quarterly rental. Pay with USDT-TRC20 or Visa / Mastercard / Amex (via Stripe); all billing is in USD.