DebugMac delivers a dedicated Mac Mini M4 physical node for each order. Tenants do not share the same physical node environment. This page explains credential issuance, user responsibilities, data recovery, and incident handling.
Isolation starts with device allocation—not with virtual resources carved out on a shared host.
Once an order is active, its node environment is not shared with other tenants. The CPU, memory, base SSD, and system session all run on the Mac Mini M4 assigned to that order.
SSH public keys, VNC credentials, and host fingerprints serve separate roles: command-line access, graphical sessions, and host identity verification. No change should bypass order identity checks.
Grant only the permissions required by the actual workflow, then expand access as needed. Shared keys, ownerless credentials kept indefinitely, and shared access records reduce traceability.
A successful connection is only the first step. The complete process also includes identity verification, permission scoping, credential rotation, and access recovery when the rental ends.
Submit only the public key that needs to be added to the node—never send the private key. For teams, use separate member keys instead of sharing one identity credential.
Before the first connection, compare the fingerprint in the delivery receipt character by character with the client prompt. If it changes unexpectedly, stop connecting and verify it through a console ticket.
Manage graphical-session credentials separately from SSH public keys. Provide them only to members who need a GUI, and rotate them promptly when someone leaves the project.
Separate automation, manual development, and release operations into identifiable access records. Before privileged operations, confirm backups, rollback paths, and the impact scope.
Immediately replace affected credentials after a member change, suspected key exposure, abnormal login, or workflow migration, and verify that the old credentials have been fully revoked.
Recover remote access when the rental ends. Export data before the deadline and confirm that automated pipelines no longer send jobs to the original node.
These boundaries help reduce irreversible changes. For actions that could broadly affect the system, disk, or network, preserve data and reproduction details first.
| Operation Category | User Can Perform Directly | Support Assistance Required | Pre-Execution Checks |
|---|---|---|---|
| Development Environment | Pull repositories, install project dependencies, switch to the provided Xcode toolchain, and run builds and tests | System-level environment issues or inconsistencies between delivery configuration and order records | Record versions, commands, exit codes, and reproducible steps |
| Access Control | Manage project keys, reduce member permissions, and stop unused automation jobs | Replace SSH public keys, reissue VNC credentials, and verify abnormal host fingerprints | Confirm the order ID, node region, and requester identity |
| Storage & Data | Clear build caches, export archives, and verify project file integrity | Enable the +1TB SSD, +2TB SSD, or Thunderbolt 5 daisy-chain option | Back up first and verify the target capacity and billing period |
| System & Network | Run ping, traceroute, port checks, and controlled transfer tests | Region migration, node-level network issues, or system changes affecting remote access | Preserve the timeline, source network, and redacted diagnostic results |
| High-Risk Actions | Pause the action and export data that remains accessible | Disk reset, system recovery, or permission or boot-item changes that cannot be rolled back | Define the impact scope, rollback conditions, and data recovery path |
Evaluating the metric requires checking the measurement window, node monitoring records, user-side actions, and force majeure boundaries.
Calculated on a rolling 90-day window, with all nodes operating normally 365 days a year and continuous availability.
A single dropped ping or local network fluctuation does not by itself indicate node unavailability. Reports should include the time, node region, source network, and reproduction method.
If only a specific port, client, or project fails during the same period, first distinguish access credentials, project configuration, and node service status.
After the support team verifies the timeline and impact scope, any failure to meet the agreed metric is handled through the applicable service credits under the service terms.
The data lifecycle does not begin only when the rental ends. Access materials, project files, exports, and recovery records should be managed separately from the day of delivery.
Verify the Debug M4 configuration, node region, host address, username, host fingerprint, and access issuance status to avoid sending jobs to the wrong target.
Manage repositories, dependencies, build caches, and artifacts; control member permissions by workflow; and keep independent copies of critical data.
Before the rental deadline, download archives, logs, and project data, verify file integrity, and stop runners or scheduled jobs that still target the node.
Revoke SSH and VNC access materials, close order-related entry points, and confirm that old credentials can no longer establish sessions.
Process rental data under the node recovery procedure and retain necessary order, security, and operational records. See the privacy notice for specific data-handling rules.
During a security incident, preserve evidence and limit further impact first. Notifications should reflect confirmed facts rather than unverified conclusions replacing the timeline.
Receive node alerts, user reports, or access anomalies, and record the earliest time, affected entry point, and initial symptoms.
User action: Preserve the original error and timestamp.Check the order, region, access records, and reproduction conditions; distinguish local network, credentials, project configuration, and node-side issues.
User action: Provide the order ID and redacted logs.Restrict abnormal access paths, rotate related credentials, or pause high-risk operations to prevent the impact from spreading.
User action: Stop repeated attempts and automated retries.Address the confirmed cause, verify permission, service, and data boundaries, and record changes and rollback conditions.
User action: Confirm the business-side acceptance steps.Restore access and workflows step by step, and observe whether connections, builds, and artifact exports return to a verifiable state.
User action: Run the minimum acceptance task.Compile the timeline, impact scope, response actions, and follow-up improvements; update credential management and operating checklists where needed.
User action: Confirm open items and owners.Send security reports to support@debugmac.com, or sign in to the console to submit a ticket. Do not send private keys, complete credentials, unredacted personal information, or project data unrelated to the issue.
Only Debug M4 is currently available: M4, 16GB RAM, and 256GB SSD, orderable in Singapore, Japan, South Korea, Hong Kong, and Western US. Live availability is shown in the console.