Each order corresponds to one dedicated physical machine for a defined term, not a virtual machine. ZoomMini operates the physical node and console; customers manage system accounts, application configuration, code, secrets, and backups. Clear boundaries make permissions auditable and revocable.
A dedicated physical machine places customer workloads within a clearly defined device boundary. However, device dedication does not automatically secure every account, remote entry point, or application credential. An effective isolation model combines the physical, control, system, and workload layers.
Each active order corresponds to one dedicated physical machine and a defined term. The device is not a shared virtual machine; its processor, memory, and local storage are not allocated to other customers through multi-tenant virtual sessions.
Use the console to view device status and connection details; use VNC, screen sharing, or SSH to access the system. Console sessions and operating-system sessions are separate permission surfaces and should be protected independently rather than with weak shared credentials.
Remote access should not automatically grant full system privileges. Administrator access, everyday development accounts, CI runners, and temporary troubleshooting accounts should be separated, granted only for the task, and revoked promptly afterward.
The goal of access control is not to add login steps. It is to let your team answer three questions: who accessed the device, what permissions did they use, and did they lose access after leaving the project?
Do not let multiple people share one system account long term. Unique accounts link terminal history, file ownership, runner actions, and troubleshooting records to specific people, while allowing access to be revoked for an individual who leaves the team.
Use separate keys for different people and automation tasks, and record each key’s purpose and owner. Store private keys only on controlled endpoints or in a secret-management system; never share them through tickets, email, chat, or code repositories.
Routine builds should not continuously use administrator privileges. Restrict each CI runner to the required directories, repositories, and commands. When temporary elevation is needed, confirm its purpose first and restore the original permissions afterward.
Rotate system passwords, SSH keys, and repository tokens regularly according to your internal policy. If someone leaves the team, a device changes hands, a key is exposed, or an unusual login appears, rotate credentials immediately rather than waiting for the regular schedule.
Delete unused public keys, accounts, runner registrations, saved remote-desktop entries, and automation tasks. Disabling a user account while retaining a shared token leaves behind a persistent access path that is difficult to attribute.
ZoomMini provides the device and remote access. Customers decide which code, build artifacts, test data, and secrets enter the device, and are responsible for validating, backing up, and migrating them before the term ends.
Choose VNC, screen sharing, or SSH according to the task. Before connecting, verify the address and device details shown in the console. On the first SSH connection, verify the host fingerprint; if it changes, stop the connection and investigate.
Customers manage repository credentials, signing materials, deployment keys, and service tokens. Prefer injecting them per task through a controlled secret-management system, with defined scope and revocation paths. Never write secrets into a version-controlled repository.
Remove passwords, private keys, complete tokens, complete payment credentials, and unrelated personal data before submitting troubleshooting information. Keep timestamps, commands, error codes, and necessary context so the issue can still be reproduced.
Migrate code, build artifacts, logs, and business data before the expiration time, and verify that backups can be read. Then revoke repository tokens, deployment credentials, and runner registrations, and delete local copies that are no longer needed.
Continuous integration environments often have repository read, signing, testing, and release permissions. Separate these capabilities into independent secrets, inject them by pipeline stage, and ensure every secret can be rotated and revoked independently.
Tokens should cover only the repositories and operations required. A pull-only runner should not have administrative access, and temporary tasks should not reuse long-lived release tokens.
Use a separate account and working directory for the runner. Verify the source of dependency caches, and prevent build scripts from printing secrets in environment variables or request headers.
Store signing certificates and related private keys in a controlled secret-management system, injecting them only into tasks that require signing. Remove temporary files and process environment data when the task finishes.
Keep release tokens separate from repository tokens. Test pipelines must not inherit production release permissions. When people or projects change, revoke access independently without affecting other tasks.
Check whether build scripts print environment variables, failure handling echoes complete commands, cache directories contain credential files, or artifact archives unintentionally include configuration files. If a secret reaches a log, do more than delete the log: rotate the corresponding credential.
$ git grep -nE "TOKEN|PRIVATE_KEY|PASSWORD" -- .
$ find build/ -type f -name "*.env" -o -name "*.key"
$ security find-identity -v -p codesigning
$ launchctl list | grep runner
Check results:
✓ No plaintext secrets found in the repository
✓ No credential files included in the build archive
✓ Runner uses a separate system account
✓ Signing materials injected through a controlled processZoomMini targets 99.9% service availability. All nodes operate normally 365 days a year; daily records show operating status, while incident markers flag changes for review and do not directly mean a full day of unavailability.
If you believe the service did not meet its target, submit a ticket through the console with the order identifier, node, affected period, reproducible symptoms, and sanitized logs. Eligible requests are reviewed under the service terms and compensated with service credits.
View service terms and review criteriaFor suspected account anomalies, unauthorized access, or secret exposure, do not continue running high-privilege tasks while waiting for a complete conclusion. First contain the impact, then preserve necessary records, notify the support team, and rotate secrets.
Record the discovery time, device identifier, node, affected account, related processes, and impacted workloads. Distinguish console, system-account, repository-token, and application-behavior anomalies instead of treating different permission surfaces as one issue.
Pause suspicious automation tasks, revoke anomalous sessions, disable related accounts or public keys, and restrict high-risk tokens. Do not allow known anomalous access to expand merely to preserve the scene; record the time and operator for each containment action.
Save event-related login records, command history, runner output, process information, and error codes. Sanitize everything before export; do not send passwords, private keys, complete payment credentials, or unrelated personal information.
Submit the order identifier, node, occurrence time, containment actions already taken, and sanitized logs through a console ticket or to support@zoommini.com. If an ongoing risk remains, clearly mark “Security incident” in the subject for rapid routing.
Rotate system credentials, SSH keys, repository tokens, runner keys, signing materials, and deployment credentials according to the impact scope. Before restoring tasks, confirm that old credentials are invalid, new permissions are least-privilege, and no anomalous processes remain.
Submit a ticket from the console so the request can be linked to the order, node, and device status.
Send an email to support@zoommini.com, with “Security incident” and the order identifier in the subject.
Clear responsibility boundaries reduce waiting and repeated checks during troubleshooting. Physical nodes, the console, and device provisioning fall within ZoomMini’s operating scope. Accounts, applications, code, secrets, and backups inside the system remain under customer control.
| Control area | ZoomMini is responsible for | Customer is responsible for | Recommended checks |
|---|---|---|---|
| Physical node | The dedicated mapping between the device and order, baseline node operation, and device status in the console. | Using the device for the order’s intended purpose, managing workloads, and migrating data during the term. | Device identifier, node, and term start and end times. |
| Console account | Providing account access, order management, instance status, and the ticketing entry point. | Protecting login credentials, identifying anomalous access, and promptly updating or revoking related permissions. | Recent access, order changes, and ticket history. |
| Remote connection | Providing connection details and status information for the corresponding device in the console. | Verifying the address and host fingerprint, protecting remote credentials, and configuring trusted clients. | Node, address, fingerprint, and connection account. |
| System account | Providing a usable macOS graphical interface and command-line environment. | Creating unique accounts, enforcing least privilege, rotating credentials, and removing former team members. | Account list, public-key list, and administrator privileges. |
| Application and CI/CD | Maintaining service operation for the physical node and console. | Managing Xcode, dependencies, runners, scripts, repository permissions, and release workflows. | Runner account, working directory, and token scope. |
| Code and secrets | Not deciding where customers store code and secrets or how they authorize and rotate them. | Using a controlled secret-management system and avoiding plaintext in scripts, repositories, and logs. | Secret purpose, scope, owner, and revocation method. |
| Logs and support | Investigating physical-node and console issues based on ticket information. | Providing accurate times, reproduction steps, and sanitized logs without sending secrets. | Error codes, versions, timeline, and actions taken. |
| Backup and migration | Displaying order and device term information in the console. | Defining a backup strategy, verifying recoverability, and migrating data before the term ends. | Backup integrity, recovery tests, and token revocation. |
The dedicated physical machine assigned to the order, baseline node operation, device status, order-management entry point, and support-ticket handling.
Operating-system permissions, remote credentials, application configuration, code, secrets, build pipelines, log sanitization, backups, and migration.
Customers provide the order, node, timeline, and sanitized logs. ZoomMini locates infrastructure status within its boundary, while both parties verify their respective permission surfaces.
Choose the right model and term, then configure the environment with unique accounts, SSH keys, least privilege, controlled secret injection, and a pre-expiration migration checklist.