Collect and verify the host fingerprint
Before connecting for the first time, collect the ED25519 host public key, calculate its fingerprint, and compare it with the delivery details. Never ignore a warning before verification.
ZoneMini provides dedicated physical machines, not virtual machines. Use SSH to run build commands, macOS Screen Sharing for graphical tasks, or register a fixed host as a CI Runner. Verify your connection details first, then choose an access method. Never expose credentials in chat history or pipeline logs.
All three methods can coexist. Prefer SSH or a Runner for routine automation; open Screen Sharing only when you need the Xcode interface, system settings, or graphical diagnostics.
Use it to clone repositories, install dependencies, run tests, execute Xcode command-line builds, inspect logs, sync artifacts, and check disk space. Stable scripts should use key-based authentication, with a host alias stored in your local SSH configuration.
Use it to inspect Xcode projects, perform graphical debugging, check Keychain access permissions, adjust display settings, and verify archive results. Lock the session when finished, and never leave sensitive information on the desktop or clipboard.
After registering the host with your existing CI system, assign tags by repository, branch, or job type. Use a separate working directory and restricted token for the Runner, with explicit cleanup rules for caches and build artifacts.
Connection failures are often caused not by the host, but by mismatched host addresses, usernames, network policies, or order status. Follow the checks below in order to avoid repeated guesswork.
Sign in to the console to verify that the instance has been delivered, then confirm the model, location, and rental period for the current order. Match each connection detail to that instance.
Copy the host address from the console. Do not reuse an address from an old ticket, script, or team chat. Teams with multiple hosts should add purpose-based labels to each address.
The SSH username and graphical-session username may differ by access method. Do not guess the default username or hard-code temporary passwords in scripts.
Use temporary credentials only for the first login. Update them immediately after signing in, and store the new credentials through your team's approved password-management process.
Confirm that your current network permits outbound traffic to the target port. Corporate networks, proxies, and security software may restrict SSH or graphical connections; check with your network administrator first.
Record the host, purpose, owner, host fingerprint, and credential-rotation date. After the first connection, do not dismiss warnings about host-fingerprint changes.
Do not paste temporary credentials, SSH private keys, repository tokens, or signing certificates into public issues, complete pipeline logs, or unencrypted documents. When requesting support, provide only redacted command output.
Open the console to verify connection detailsThe commands below use placeholders and contain no real host addresses or credentials. Replace the placeholders with the information supplied in the console, and run them on a trusted network.
Before connecting for the first time, collect the ED25519 host public key, calculate its fingerprint, and compare it with the delivery details. Never ignore a warning before verification.
Create a separate key pair for the ZoneMini host. Keep the private key on a controlled local device, then add the public key to the remote authorized-key list.
Store the host address, username, key path, and session-keepalive settings in your SSH configuration to avoid manual entry and accidental use of the wrong host.
Confirm that key-based login works before updating the temporary credentials. Do not remove the only working login method before the key has been verified.
ssh-keyscan -t ed25519 <node-address> > zonemini_hostkey
ssh-keygen -lf zonemini_hostkey
ssh-keygen -t ed25519 -f ~/.ssh/zonemini_ed25519
ssh-copy-id -i ~/.ssh/zonemini_ed25519.pub <user>@<node-address>
ssh -i ~/.ssh/zonemini_ed25519 <user>@<node-address>
Host zonemini-build
HostName <node-address>
User <user>
IdentityFile ~/.ssh/zonemini_ed25519
ServerAliveInterval 30
ServerAliveCountMax 3
Screen Sharing is useful for graphical Xcode debugging, checking system settings, and reviewing archives. Run build scripts, collect logs, and process batch jobs through SSH whenever possible.
In macOS Finder, choose “Go” and “Connect to Server,” enter the server address from your delivery details, and start the session with the authorized username and credentials.
vnc://<node-address>
Use Finder's Connect to Server option. Do not save credentials through shortcuts from unknown sources.
Verify the username and host address, then enter your credentials. For collaboration, do not share one set of long-term login details.
When the network is unstable, lower the resolution or color quality first. A high-resolution desktop increases data transfer and input latency.
Do not copy private keys, complete tokens, or plaintext passwords. Before pasting across sessions, verify the target window and current user.
Closing the client does not necessarily log you out of the desktop. Lock the session when finished and close sensitive windows you no longer need.
Windows or Linux workstations need a compatible graphical connection client. Clients may differ in shortcut keys, clipboard behavior, color, scaling, and multi-monitor support, so test with a non-sensitive task first.
Choose a client that supports the target connection protocol, encrypted transport, and custom resolutions. The installation source should be team-approved, and the client should be kept up to date.
Verify DNS, routing, and the target port before testing the graphical session. Corporate proxies, egress firewalls, and wireless-network changes can all interrupt a session.
Start verification with one display at a medium resolution, then increase the canvas size gradually. If the screen is blank or cropped, return to a lower resolution and reconnect.
A setup is ready for daily use only when it supports stable input, clear log reading, correct mapping of common shortcuts, and safe session termination. If the task can be fully scripted, prefer SSH or a CI Runner.
Use a separate account, working directory, and restricted token for the Runner. Start with one minimal test pipeline, then add signing builds, caching, and archiving steps.
Separate source code, dependency caches, build intermediates, and final artifacts to simplify cleanup rules and disk-usage troubleshooting.
Authorize the token only for the target repository and required operations. Do not reuse a personal access token or write the token to the repository or build output.
Tag jobs by Xcode version, project type, model, or workload to prevent incompatible jobs from being scheduled on the wrong environment.
Run dependency checks and unit tests before archiving. On failure, retain necessary logs, but never upload the entire user directory unconditionally.
After confirming that artifacts reached the target storage, delete temporary credentials, temporary keychains, expired caches, and obsolete build directories.
set -euo pipefail
WORK_DIR="$HOME/ci-work/project"
RESULT_DIR="$HOME/ci-results"
mkdir -p "$WORK_DIR" "$RESULT_DIR"
cd "$WORK_DIR"
git fetch --prune
git checkout "$CI_COMMIT_REF"
xcodebuild \
-scheme "$CI_SCHEME" \
-destination "generic/platform=iOS" \
test
xcodebuild \
-scheme "$CI_SCHEME" \
-archivePath "$RESULT_DIR/App.xcarchive" \
archive
find "$WORK_DIR" -name "*.tmp" -delete
Every permission should have an owner, purpose, and expiration date. Shared accounts, repository tokens, and temporary files left unmanaged over time make a fixed build environment increasingly difficult to audit.
Each maintainer should use a separate key. When someone leaves the project, remove that public key without affecting anyone else's access.
When a shared environment is necessary, still distinguish personal logins from automation accounts. Never let a Runner use an administrator's everyday account.
Maintain rotation records for repository tokens, Runner registration tokens, and temporary access credentials, and delete expired tokens promptly.
Build jobs should receive access only to the required repositories and branches. Use separate credentials for uploading artifacts and reading source code.
Lock the session before leaving the desktop, close windows containing sensitive content, and clear clipboard contents you no longer need.
When a job ends, delete temporary private keys, one-time tokens, temporary keychains, and authorization files that are no longer needed.
Don't randomly change passwords, addresses, and clients in succession. Record the error type, time, local network, host, and access method first, then run the relevant checks.
| Symptom | Check first | Action to take | Include with support request |
|---|---|---|---|
| Connection timeout | Host address, local network, egress rules, and target port | Switch to a trusted network; test port connectivity; confirm that you are not using an old address | Time, host, client network type, and redacted probe results |
| Authentication failure | Username, key path, file permissions, and whether credentials were updated | Use verbose SSH logs to identify the selected key; verify the authorized public key | Error lines, username, and key fingerprint—never the private key or full password |
| Host fingerprint changed | Whether the host address was changed, the instance rebuilt, or the local alias modified | Stop connecting; recheck the fingerprint in the console; update the record only after confirmation | Host, old fingerprint, new fingerprint, and time first detected |
| Blank graphical session | Whether the session is locked, display resolution, and client compatibility | Lower the resolution; reconnect; use SSH to check system status | Client OS, client version, display settings, and redacted screenshot |
| Incorrect resolution | Client scaling, multi-monitor mode, and window size | Return to one display and medium resolution, then restore settings one by one | Expected resolution, actual resolution, scaling ratio, and client type |
| Frequent session interruptions | Wireless changes, proxy, idle policy, and link instability | Use a stable network; enable SSH keepalives; run long jobs in a persistent session | Interruption frequency, duration, network changes, and relevant log excerpts |
nc -vz <node-address> 22
route -n get <node-address>
ssh -vvv zonemini-build 2>&1 | tee ssh-debug.log
Provide the order number, one of ZoneMini M4 Core / ZoneMini M4 Plus / ZoneMini M4 Pro, host, time, connection method, reproduction steps, expected result, and redacted logs. Do not upload certificate private keys, repository tokens, or full passwords.
Prepare the use case, concurrent job count, memory requirements, target location, and rental period. View connection details for existing orders in the console; check the Help Center first for configuration questions.