From graphical desktop and terminal sessions to unattended builds, follow the same checks for the node, credentials, network, and toolchain. Every order includes one dedicated Apple Silicon physical machine, not a virtual machine.
Use the graphical desktop for visual work, the terminal for development and diagnostics, and automation for repeatable pipelines. All three can run in parallel, but manage their permissions and credentials separately.
Ideal for Xcode project setup, simulator debugging, certificate imports, visual log inspection, and remote work requiring the full macOS graphical interface. On your first connection, check display scaling, keyboard mapping, clipboard rules, and file-transfer permissions.
Ideal for installing dependencies, syncing repositories, running builds, collecting logs, and checking processes. Verify the host fingerprint when connecting, never copy private keys to shared directories, and use a separate low-privilege account for routine tasks.
Ideal for continuous integration, scheduled builds, test execution, and artifact archiving. Use a dedicated workspace, set explicit concurrency limits, restrict key access, and remove temporary files and logs containing sensitive fields when the job finishes.
Do not begin troubleshooting with repeated reconnects. First record the node details shown in the console, then check your local environment item by item. This also gives you complete context when submitting a support request.
Recheck after changing the node, network, or client.
Complete the basic connection first, then adjust display and transfer options. Change only one variable at a time so you can identify whether an issue comes from the network, client, or session settings.
Sign in to the console, open the relevant instance, and copy its current address, port, and username. Do not reuse a session configuration saved for an old order or guess the address from the node name.
Enter the connection details on a trusted network. When identity confirmation appears for the first time, verify the instance information. After entering the desktop, check keyboard and mouse input before starting large downloads or builds.
Choose a resolution based on your local display and connection quality. If text looks blurry, adjust client scaling first. If interaction lags, reduce the display size or refresh rate and compare the response.
First copy text containing no sensitive information, then transfer a small test file. Enable bidirectional transfer only when supported by the client and allowed by project policy; disable sharing features you do not need afterward.
This interface is illustrative. Actual addresses, resolutions, and available options depend on the console and the client you use.
A working SSH connection does not mean the pipeline is ready. Verify tool versions, workspace, execution permissions, cache policy, and artifact export paths separately.
Use a dedicated key for the remote node; never upload the private key to a repository, build cache, or shared team directory. On the first connection, compare the host fingerprint shown by the client with the console details. Stop and recheck the node if they do not match.
chmod 600 ~/.ssh/hireamac_node
ssh-keygen -lf ~/.ssh/hireamac_node.pub
ssh -i ~/.ssh/hireamac_node build@node-address
uname -m
sw_vers
df -h
xcodebuild -versionIn the example, node-address should be replaced with the current instance address returned by the console. Never write addresses, private keys, or valid credentials into public scripts.
Complete one repeatable build in a standard terminal before registering the Runner. After registration, check job tags, workspace, shell environment, and concurrency limits so the queue assigns only compatible macOS jobs to this node.
mkdir -p ~/ci-workspace
cd ~/ci-workspace
git --version
xcrun --find xcodebuild
xcode-select -p
security find-identity -v
ps aux | grep runner
du -sh ~/ci-workspaceInject certificate files, signing materials, and repository tokens through a controlled process. Keep only the fields needed for troubleshooting in logs, then inspect temporary directories, derived data, and exported artifacts after the job completes.
Confirm that the shell, Git, Xcode command-line tools, and build scripts run in a non-interactive environment.
Use explicit directories for repositories, caches, logs, and artifacts to prevent tasks from overwriting one another.
Give the Runner only the permissions required for the job, without extending key access to unrelated processes.
Keep exit codes, build stages, and redacted logs so failed jobs can be rerun.
Do not move the entire workflow at once. Keep inputs, validation points, and rollback actions for each track; move to the next only after the current one is stable.
Project repositories, dependency lockfiles, test assets, build scripts, and historical artifacts to retain. Classify public code, internal code, and sensitive materials first.
Check file counts, checksums, directory permissions, and disk usage. Fetch dependencies again and confirm the project opens and builds in the new directory.
Keep a local read-only copy and migration checklist. If validation fails, delete the incomplete cloud copy, correct the transfer scope, and restart.
macOS requirements, Xcode version, Swift version, package-manager lockfiles, environment-variable names, and build commands. Do not copy years of unknown accumulated configuration.
Record the system architecture and tool versions, run a clean build and basic tests, and compare artifact names, signing status, exit codes, and required logs.
Keep a version inventory and installation order. If versions conflict, return to the last verified combination instead of repeatedly installing unknown dependencies on a production build node.
Runner configuration, job tags, concurrency policy, workspace, credential-injection method, cache directories, and artifact-export rules.
Run one job first, then verify consecutive jobs and failure retries. Check that processes, temporary files, caches, and logs match expectations after each job ends.
Pause the new Runner's job tags so the queue returns to the original execution node; export failure logs and clear incomplete workspaces.
Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the eastern United States operate normally 365 days a year. Your experience still depends on your location, carrier routing, local network, and client settings.
| Node | Region code | Time-zone reference | Suitable workflows | Connection checks |
|---|---|---|---|---|
| Singapore | SG | UTC+8 | Remote development for Southeast Asian teams, regional builds, and cross-region collaboration | Test office and backup networks separately; record handshake, input response, and file-transfer results |
| Japan (Tokyo) | JP | UTC+9 | Projects for the Japanese market, iOS builds, and collaboration with teams in and around Tokyo | Check local carrier routing and compare graphical desktop and terminal-session stability |
| South Korea (Seoul) | KR | UTC+9 | Development for Korean teams, remote work in the Seoul region, and continuous integration | Run short sessions and long jobs continuously to detect recurring time-based route fluctuations |
| Hong Kong | HK | UTC+8 | Cross-region collaboration in Asia, graphical desktop work, and handoffs across locations | Check proxy and corporate-network policies to avoid adding connection hops through repeated forwarding |
| Eastern United States | US-E | UTC−5 / UTC−4 | Development, build queues, and time-zone handoffs for teams in the eastern United States | Test during the team's actual working hours and distinguish cross-region routing from node-local job performance |
Graphical desktop work involves frequent interaction, so prioritize the developer's location and usual network. Do not choose a remote-work node based only on the customer's market.
Test connection setup, continuous input, small-file transfer, and long builds separately. Retest during the team's usual hours; do not treat a single result as representative of the long-term route.
Once you choose a node, keep the client version, resolution, and network policy fixed. When performance fluctuates, change one condition at a time and record the before-and-after results.
A dedicated physical node reduces interference from shared compute resources, but users must still manage credentials, sessions, project data, and exports according to process.
Rotate credentials immediately after personnel changes, device loss, suspicious logins, or credential exposure. Use separate credentials for graphical desktop, SSH, and CI Runner to limit the impact of a compromised entry point.
Do not use a high-privilege account for routine builds. Elevate privileges temporarily only when installation or system configuration requires it, then return to a standard execution environment and check for permission changes.
Before leaving your workstation, stop terminals, forwarding, and graphical desktop sessions you no longer need. After automation finishes, confirm that the Runner has no leftover child processes or ongoing workspace activity.
Check downloads, the desktop, shell history, temporary directories, build logs, and caches. Remove unneeded certificates, token copies, debug packages, and test assets containing user data.
Export source changes, build artifacts, logs, configuration inventories, and data you need to retain in advance. Verify from another environment that the archive is readable; never treat the node as your only backup.
Three Apple Silicon dedicated physical-machine tiers cover five nodes: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the eastern United States. Rent by the day, week, month, or quarter; actual availability is returned in real time by the console.
We support only USDT-TRC20 and Visa / Mastercard / Amex via Stripe. All orders are settled in USD; available payment gateways are determined by the backend response.