VMOrbit provisions dedicated Apple Silicon physical nodes and manages service delivery and node operations. Your team controls account permissions, project data, keys, signing materials, and application configuration. Defining this boundary makes security steps for remote development, continuous integration, and data migration practical and actionable.
Dedicated access does not eliminate configuration work. Physical isolation clarifies resource ownership, but your team must continually manage member access, key storage, project permissions, and backup policies.
| Control area | VMOrbit is responsible for | The customer is responsible for | Recommended checks |
|---|---|---|---|
| Service delivery | Delivering the model, node, and term specified in the order, and keeping the node operational. | Verifying order details, authorized users, and connection environments. | Do the model, region, term, and contact match the actual use case? |
| Access permissions | Providing the management and support processes associated with the order. | Creating individual user accounts, assigning least privilege, and removing access for departed members. | Are any unnecessary accounts, keys, or remote entry points still active? |
| Project data | Maintaining the node environment required to run the hosted service. | Managing code, build artifacts, caches, signing materials, and necessary backups. | Does a recoverable copy of critical data exist outside the node? |
| Application configuration | Helping locate node and connection-layer issues through the support process. | Managing toolchains, dependencies, CI configuration, token permissions, and log redaction. | Are configuration changes recorded, and are sensitive values excluded from logs and repositories? |
VMOrbit Cloud Mac provides a dedicated physical server, not a virtual machine. Your team should separate people, connection entry points, and project permissions into three independent control layers instead of using one long-lived credential everywhere.
Create an individual identity for each person who needs to operate the node. Never share long-lived passwords or private keys. Assign permissions by responsibility—development, builds, or auditing—and review the member list regularly.
SSH is suited to command-line administration and automation; VNC is suited to work that requires the macOS graphical interface. Open only the entry points you actually use, and restrict source networks and permitted hours.
Repositories, build systems, signing workflows, and external services should be authorized separately. Node administrator access should not automatically grant access to every project secret or production resource.
Who owns it, what can it access, and when should it be revoked? Any credential that cannot answer all three is unsuitable as a long-term entry point.
Each member should use a traceable individual account. Avoid having multiple people share the same long-lived credentials.
Enable strong authentication when supported by the relevant identity system, and assign a controlled owner for recovery procedures.
Set rotation periods for SSH keys, CI tokens, and signing credentials, then verify that old values no longer work.
When a member leaves, a device is lost, responsibilities change, or a credential may be exposed, revoke access first and assess the impact afterward.
Do not put private keys, long-lived tokens, recovery codes, or complete payment credentials in code, configuration examples, shell history, build output, or ordinary support messages.
Also check SSH authorization entries, VNC access, repository members, runner registrations, environment variables, signing workflows, and any locally stored copies.
Confirm the authorized identity first, then restrict the source and review login records. When a connection fails, do not repeatedly widen access. Check credentials, ports, the local firewall, the network path, and node status step by step.
| Check | SSH | VNC | Warning signs |
|---|---|---|---|
| Best for | Command-line administration, automation, builds, and log review. | Development, debugging, and tools that require the macOS graphical interface. | The connection method does not match the task, leaving an unnecessary entry point open. |
| Identity control | Prefer individual SSH keys and regularly clean up the authorized-key list. | Use individual node accounts and never share long-lived login credentials. | Unknown keys, unknown accounts, or departed members can still connect. |
| Source restrictions | Restrict administrative entry points to the network paths your team actually uses. | Allow access only for members who need graphical operations, and verify the source. | Multiple unfamiliar sources or unusual connection attempts appear within a short period. |
| Record review | Review login times, sources, accounts, and critical actions performed. | Review session times, authorized members, and unexpected disconnections. | Unclaimed sessions, logins at unusual times, or sudden permission changes. |
Continuous integration connects to repositories, dependency sources, signing workflows, and release targets. Configure these permissions separately; no single token should be able to read every repository, change configuration, and execute releases.
Register each runner only with the repository or project group that needs it. Create a separate execution boundary for jobs from untrusted branches and external contributions.
Deliverable: runner-to-repository mappingPut signing materials, access tokens, and deployment credentials into a controlled secrets workflow. Inject them temporarily per task instead of writing them into repositories or fixed scripts.
Deliverable: secrets purpose and owner listAvoid printing sensitive values in command echoes, environment-variable dumps, stack traces, or build attachments. Review and redact logs again before submitting them to support.
Deliverable: log-redaction rulesAfter each task, remove temporary files, sensitive cached content, and unneeded build artifacts while retaining the minimum records genuinely useful for reproducing an issue.
Deliverable: post-task cleanup scriptThe only copy on a node should never be your team’s recovery plan. Code, build artifacts, caches, and signing materials have different value and require separate synchronization, backup, export, and cleanup rules.
Confirm the transfer source and destination directory. Do not bring unrelated credentials, personal files, or old archives onto the node.
Separate source code, dependency caches, test data, and release materials. Assign clear access owners for sensitive directories and record important configuration changes.
Keep necessary copies outside the node and regularly verify that they can be read and restored. A successful sync alone does not prove recoverability.
Before the term ends, export code, configuration, necessary logs, and build results. Confirm that the target environment has the toolchain and permissions needed to continue working.
Revoke remote access, remove unneeded keys, tokens, working directories, and temporary files, and complete your team’s export confirmation.
Support requests, node events, and necessary actions are tracked for traceability, with the precise scope governed by applicable policies and service processes. Customer submissions should contain only the minimum context needed to locate the issue.
Record the order reference, node region, issue type, impact, reproduction steps, and follow-up materials so the same conversation can continue smoothly.
Organize records around the incident timeline, observable symptoms, isolation actions, and recovery results. Avoid leaving only conclusions that cannot be verified.
When collaboration is needed, specify the target, authorization scope, and completion status. Include only diagnostic excerpts in logs, after removing sensitive values.
Do not keep using suspicious credentials while waiting for a complete conclusion. First reduce the impact, then preserve the necessary timeline, rotate potentially affected credentials, and create an ongoing record through a console support ticket.
Stop suspicious sessions, revoke anomalous accounts or keys, and pause affected runners and automated tasks. Isolation should cover every other entry point that may use the same credential.
Record when the issue was discovered, the symptoms, sources, related accounts, recent changes, and actions already taken. Keep only the minimum necessary logs without overwriting original timestamps.
Replace potentially affected SSH keys, node-account credentials, repository tokens, and CI secrets. Confirm that old values are invalid rather than merely creating new ones.
Link the relevant order in the console and provide the node region, time, symptoms, actions taken, and redacted logs. Then coordinate investigation and recovery according to the impact.
For an existing order or an active node issue, sign in to the console first and submit a linked ticket. If you cannot access the console, email support@vmorbit.com. Use the same address for security reports, business collaboration, and compliance-material requests.
Link order-related issues to the node through a console ticket. For login problems or general security questions, use the support email. We never ask you to send secret credentials through ordinary email.
Before choosing a model, node, and term, identify authorized members, remote entry points, backup owners, and incident contacts. Actual availability and delivery details are based on the real-time information returned by the console.