First connection
Prepare your SSH public key, verify the username, host address, and fingerprint, then choose between the command line and browser-based graphical interface.
This is not a generic FAQ list. Each guide follows a troubleshooting sequence to help you determine whether the issue comes from your local network, connection credentials, remote service, development environment, or task itself.
For DplyMini dedicated physical Mac mini devices. Each device runs outside a virtual machine, with both the macOS graphical interface and command line available for iOS/macOS development, CI/CD builds, and AI inference experiments.
Is it a single command, one project, the entire device, or every connection on the local network?
Record the time, node, complete error line, and operation just performed.
Check each layer in order: console status, local link, credentials, services, and target port.
Choose the entry point closest to your current goal. Do not change networking, credentials, and build settings at the same time, or it will be difficult to tell what actually fixed the issue.
Prepare your SSH public key, verify the username, host address, and fingerprint, then choose between the command line and browser-based graphical interface.
Check the Xcode selection path, command-line tools, signing assets, fastlane dependencies, and the CI Runner execution account.
Confirm target-directory space, file permissions, checksums, and your resume strategy to avoid mistaking an interrupted transfer for a device failure.
Verify DNS, the egress path, firewall rules, target ports, and remote services in sequence. Do not reset all network settings at once.
Verify the order term, USD billing record, payment status, and order association. Submit operational issues through the relevant order.
This sequence is useful for SSH timeouts, inaccessible graphical sessions, offline build agents, and unreachable service ports. Each step answers one question; record the result.
Sign in to the console and open the relevant order. Verify that the device name, node, term, and connection address match the current command. Use the console’s real-time status as the availability source of truth.
The order matches the target device, and the connection details were copied correctly.
Confirm that your local network can resolve other domains and access common HTTPS services. If you are on a corporate network, guest Wi-Fi, or proxy, switch to a known-working link for comparison.
Does the issue occur only on one egress network?
Check whether the SSH configuration references the expected private key and whether the key-file permissions are appropriate. When authentication fails, use verbose output to confirm which key the client actually tried.
Did the connection reach the host, or did it time out before authentication?
If SSH works but the graphical interface is interrupted, the underlying network and device are usually still reachable. Check the browser session, resolution, clipboard, or desktop service instead.
Is the entire device affected, or only one remote service?
Confirm that the application is listening on the expected address and port, and that local or project firewall rules allow access. Do not immediately blame node networking when the application has not started.
Is the port unreachable, is the service not listening, or does the application exit immediately after starting?
Replace the hostname in the command with the connection address shown in the console. Before sharing logs, remove usernames, addresses, key paths, and project secrets.
$ ssh -vvv user@host
$ nc -vz host 22
$ scutil --dns
$ lsof -nP -iTCP -sTCP:LISTEN
SSH, browser-based remote access, and graphical desktop sessions use the same dedicated physical Mac, but their failure causes differ. Verify lower-level connectivity first, then inspect the higher-level interaction.
Diagnostic standard: verbose output should show where DNS, TCP connection, host verification, and authentication each stop.
Diagnostic standard: interaction stability matters more than peak bandwidth; background tasks should not depend on a browser window remaining open.
When the same project works in an interactive terminal but fails in a CI Runner, PATH, permissions, environment variables, or the execution account are often different. Reproduce the environment difference before changing project configuration.
Run xcode-select -p and xcodebuild -versionto confirm that the interactive terminal and Runner use the same toolchain. If the project requires a specific version, put the selection logic in the task initialization step.
First check certificate validity, provisioning-profile matching, and Keychain access permissions. Do not look only at the final signing error; find the first signing diagnostic in the build log.
Run tasks using the project’s dependency lockfile, and confirm that Bundler, plugins, and environment variables come from the same working directory. When the interactive terminal succeeds but automation fails, compare PATH and working directory on both sides.
Check the Runner execution account, working directory, cache directory, and temporary-directory permissions. Inject sensitive variables through the task environment; do not write them to the repository, ordinary logs, or ticket body.
Users manage project data on dedicated physical Macs. Define directories before starting, verify transfers afterward, keep independent backups at key points, and migrate data before the term ends.
Separate source code, dependency caches, build outputs, and temporary files. CI tasks should use explicit absolute paths so different execution accounts do not write files to unexpected locations.
Transfer large files in batches, preferably with a resumable tool. Compare file counts, sizes, and checksums before and after transfer; do not rely solely on the progress bar reaching 100%.
The only copy on a device is not a backup. Keep source code under version control and sync critical artifacts and experiment results to independent storage managed by you.
Do not wait until the final moment of the term to export data. Allow time for transfer, verification, and retries, and confirm that the destination can be read before removing temporary credentials.
Users are responsible for project data, access credentials, backups, and migration arrangements before the term ends. If device access fails, submit a ticket from the relevant order as early as possible and describe the unmigrated data types and task impact.
Orders can use daily, weekly, monthly, or quarterly terms. All charges are settled in USD. Payments support only USDT-TRC20 and Visa / Mastercard / Amex via Stripe; the console shows the gateways currently available.
For short-term fixes, one-time archiving, or temporary experiments, consider a daily term. For continuous iteration, a stable Runner, or a long-term project, compare weekly, monthly, and quarterly plans. Before ordering, confirm the expected task duration, data-migration time, and team handoff plan.
Do not create multiple identical orders. Save the order number, payment time, amount, and the necessary transaction identifier returned by the gateway, then submit a ticket through the relevant order. Do not include complete payment credentials or unrelated sensitive account information.
Check add-ons, term, and quantity in the order configuration and details. Thunderbolt 5 daisy chaining is calculated per device. If delivery information differs from the order details, submit a ticket from that order with a redacted screenshot.
Submit operational issues through the relevant order so the device and order can be correctly linked. For general questions, email support@deploymini.com.
Copy the relevant order number from the console; do not provide only the device nickname.
Specify Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or the US West.
Provide a time range with the time zone and state whether the issue is ongoing.
List commands, page actions, and expected results in the order they actually occurred.
Keep the first error and surrounding context; remove addresses, tokens, and business data.
Suitable for connection interruptions, hardware anomalies, order delivery, and billing-association issues. Open the order in the console, then create a ticket.
Suitable for configuration choices, node availability, partnership inquiries, security, and privacy questions. State the question type in the subject; if you have an order, include its number.
Crop unrelated windows from screenshots. Replace usernames, host addresses, tokens, repository addresses, and project data in logs. Support usually needs only the error context and necessary identifiers.
Clearly stating the issue type, scope, and whether it is ongoing helps reduce follow-up questions. These four categories use the same ticket entry point but require different evidence.
Configuration choices, node availability, rental terms, payment details, or long-term team needs.
SSH timeout, authentication failure, interrupted browser session, or unreachable target port.
Persistent disk, memory, restart, or device-level errors unrelated to a single project.
Unexpected access, suspected credential exposure, or system operations that do not match expectations.
Entering through the relevant order preserves the device, node, and order association and reduces the time needed for initial confirmation.
For a new task, follow the getting-started steps to prepare keys, the node, and tool versions. For an active issue, submit a ticket through the relevant order.