PingMini provides dedicated physical Cloud Mac machines. Choose graphical desktop, SSH, or automation based on your workflow, then migrate your code, toolchain, and build configuration. Every step includes inputs, actions, and acceptance checks.
You can use all three methods together, but we recommend against configuring every entry point at once for a first setup. Complete the minimum connection check first, then add automation and team permissions.
Best for checking the system initially, running Xcode, handling signing assets, monitoring build interfaces, and performing tasks that require human confirmation.
Best for repository sync, dependency installation, log collection, script execution, and low-bandwidth environments. Prefer keys over long-lived shared passwords.
Best for CI/CD, self-hosted runners, scheduled builds, and batch testing. Use a dedicated runner account, working directory, and revocable credentials.
The goal of the first connection is not to move the entire project immediately, but to confirm the host, display, input, and data-exchange boundaries. Record the result after each check.
Check the node, model, host address, and account name in the order one by one. Do not connect from historical records or reuse an address from an old project for a new order.
Connect from a trusted network. After signing in for the first time, check system information, time zone, disk capacity, and network status before importing any sensitive material.
Choose a resolution suited to your local display and connection. If text is blurry, check scaling first; if interaction is delayed, lower image quality before assuming a host performance issue.
Test Chinese and English input, common shortcuts, and keyboard layout. Confirm whether the clipboard allows two-way synchronization; sensitive content should not remain in a shared clipboard.
Record the network used to initiate the connection, client version, target node, and start time. If lag or disconnections occur later, this information helps distinguish local network issues from remote-session problems.
Run a small test project to confirm that compilation, logs, and the output directory work correctly. Only then migrate large repositories, media assets, or signing-related files.
Manage keys, host fingerprints, and account permissions separately. Do not put long-lived private keys, project keys, and shared team credentials in the same directory just to save a step.
Generate a dedicated key for the current device and collaborator. The filename should identify the device and purpose; the key comment should contain only necessary identifiers, never project secrets.
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/pingmini_dev
chmod 600 ~/.ssh/pingmini_dev
ssh-add ~/.ssh/pingmini_devKeep the private key on a controlled local device and submit only the public key. When a team member leaves the project, delete the corresponding public key instead of replacing the entire shared credential set.
The host fingerprint shown on the first connection must match the information from a trusted source. After confirming it, use read-only commands to verify the host identity and command-execution path.
ssh -i ~/.ssh/pingmini_dev user@host
ssh -i ~/.ssh/pingmini_dev user@host \
'sw_vers && uname -m && whoami'The expected result should include the macOS version, arm64 architecture, and the correct account name. If the result differs, stop the migration and verify the order and connection details first.
Give automation accounts only the permissions required for their tasks. Separate interactive and CI accounts so scripts cannot inherit unnecessary access to personal directories.
Use a dedicated alias and specified key file in the local SSH configuration, and disable irrelevant identity attempts to reduce the chance of using the wrong private key.
In addition to reviewing command output, check the script exit code. Automation systems use exit codes to determine success or failure; the final log line alone is not enough.
Moving from a local Mac to a Cloud Mac is not a whole-disk copy. Migrate data first, reproduce the toolchain next, and connect CI last. Keep input lists and acceptance evidence for every path.
Migration is complete when the same commit builds reliably in the new environment, not when the file count exactly matches the local device.
Clone again from a trusted remote and check branches, submodules, large-file references, and uncommitted changes.
Sync the lockfiles and version declarations used by the project to avoid unintentionally upgrading dependencies on the new machine.
Record the actual versions, selected developer directory, and SDK requirements, then run a complete build.
Import only the materials required by the project. Define the owner, purpose, and revocation path, and limit automation-account access.
Keep the commit ID, tool versions, task duration, exit code, and artifact location as the migration acceptance record.
Repositories, lockfiles, configuration templates, scripts, required assets, signing materials, and explicit version requirements. Every item should have a known source and purpose.
Derived build directories, package-manager caches, temporary simulator data, historical logs, and unrelated downloaded files. Copying these can magnify compatibility issues.
Remote sessions, SSH keys, and CI credentials should each have a clear owner, purpose, and revocation time. Ending collaboration does not mean merely closing a window; revoke access and remove residual data as well.
Give each collaborator an individual entry point. Avoid sharing one account and key among multiple people so access can be revoked precisely when team membership changes.
Rotate immediately when a device is replaced, a member leaves, a project changes hands, or credentials may have been exposed. Do not wait for a fixed cycle to end.
Use separate account boundaries for interactive work, automation, and operational tasks. Prevent CI tasks from gaining unnecessary access to personal directories.
Before the rental term ends, export required artifacts, revoke project credentials, delete sensitive files, and confirm that collaborator entry points have been reclaimed.
Open only the entry points required for the task and record the associated public key or runner account.
If the source, timing, or task behavior looks unusual, pause access first and preserve the necessary logs.
Verify that old keys can no longer connect and confirm that project materials have been handled according to the handoff requirements.
Do not change the address, network, credentials, and client settings at the same time. Verify one layer at a time and preserve the exact error and timestamp to shorten the path to the cause.
First confirm that service delivery is complete, the current term is valid, and the model and node match the order. Actual availability is determined by the real-time status returned by the console.
Check the address, port, and account name character by character; do not use historical connection records. When the address changes, update local aliases and automation configuration as well.
Switch to a trusted alternative network for comparison, and check whether the local firewall, corporate egress policy, proxy settings, or DNS resolution is affecting the connection.
Confirm that you are using the correct key and account. If the fingerprint is unexpected, do not bypass verification; stop connecting and check the host information against a trusted source.
If SSH works but the graphical session does not, check the corresponding services separately. If the graphical session works but a script fails, check the shell, paths, and permissions.
Keep the timestamp, client version, exact error text, reproduction steps, and completed checks. When submitting a support request, do not write only “unable to connect.”
Three fixed configurations cover lightweight builds, everyday development, and large-model inference. After ordering, connect to the physical node using the order confirmation details and migrate your development environment step by step.