Clear rules for using your Cloud Mac

VMOrbit provides Cloud Mac rental for development, builds, continuous integration, and experimental workloads. The service consists of dedicated physical machines and physical nodes, not virtual machines. Users may access delivered nodes through a remote graphical interface or command line; connection details are provided during order confirmation and instance management.

The public catalog currently includes two configurations: VMOrbit M4 with an M4 chip, 16GB of memory, and a 256GB SSD; and VMOrbit M4 Pro with an M4 Pro chip, 64GB of memory, and a 2TB SSD. Any additional storage or Thunderbolt 5 daisy-chaining capability is a separate option and does not change the base model’s chip or memory specifications.

The six available nodes are Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, the US East Coast, and the US West Coast. Choose a node based on the actual network location of primary users, code repository routes, dependency sources, and team collaboration locations.

Users must be eligible to enter into and perform these Terms and must provide accurate, complete information suitable for service notifications. Teams and organizations must ensure that anyone operating an account on their behalf is properly authorized.

• Keep login credentials, SSH keys, and other access materials secure and do not share them with unrelated parties.
• Grant node access only to members who need it for their work, and revoke access promptly when responsibilities change.
• If you discover unusual login activity, compromised credentials, or unauthorized order activity, immediately replace the relevant credentials and submit a support ticket through the console.
• You are responsible for purchases, renewals, configuration changes, data operations, and support requests initiated under your account.

Users may not impersonate others, submit misleading information, bypass account security controls, or use automation to interfere with identity verification. Actions resulting from failure to protect credentials will be treated as authorized account activity unless valid evidence shows that the incident was caused by a platform-side security event.

When placing an order, users must verify the model, service node, daily, weekly, monthly, or quarterly billing term, additional SSD, and Thunderbolt 5 daisy-chaining option. The order confirmation returned by the console is the direct basis for fulfilling the order.

The two models in the public catalog are available across six nodes. Actual availability, delivery steps, and estimated completion time are returned in real time by the console. If additional confirmation is required, delivery may continue once the necessary information is provided.

Unconfirmed verbal descriptions, assumptions based on information outside the page, or configurations calculated by the user do not form part of the order. To change a node, term, or add-on, submit the relevant request or ticket through the console and use the executable result returned by the system.

The two base models use the published prices below. Daily, weekly, monthly, and quarterly are four separate rental terms; the price for one term does not represent a proportional conversion of another.

Add-ons are also priced independently according to the selected term and are included in the order together with the base model:

Users should verify the order total before payment. Renewals, additional storage, daisy-chained devices, or term changes may create a new order record. Pricing is based on the published catalog and order details shown when the action is confirmed.

Completing payment does not allow users to skip order confirmation. Order status, payment matching, and delivery results are determined by console records. For reconciliation, provide the order ID, payment time, amount, and the minimum necessary transaction evidence; do not submit complete payment credentials.

Users may not use VMOrbit services to conduct, assist with, or conceal unlawful activity, or compromise the security or normal use of the platform, nodes, network, other users, or third parties. Prohibited conduct includes, but is not limited to:

• Unauthorized access to, scanning, probing, or control of any account, system, network, or data.
• Distributing malicious code, running destructive automation, creating deceptive services, or helping evade security controls.
• Continuously consuming network, storage, or compute resources clearly disproportionate to normal development tasks and affecting node stability.
• Interfering with other users, attacking public networks, falsifying source information, or concealing the true purpose of prohibited activity.
• Reselling or lending access to unaudited third parties, or using shared credentials to evade account responsibility.
• Deleting, altering, or obstructing valid records required for security, billing, order, and support processes.

VMOrbit may restrict access, isolate connections, require remediation, or suspend service based on the impact of an incident. Urgent security risks may be addressed first, followed by an explanation of the reason and next steps in the account record or support ticket.

Uptime incidents are assessed using platform service records, node event logs, the user’s reported time, connection behavior, and network information verifiable by both parties. A single local connection failure does not automatically mean that a node is unavailable; users should first rule out local network, access credentials, firewall, and client configuration issues.

Impacts caused by the user’s actions, the user’s network, incorrect configuration, third-party dependency failures, unauthorized software changes, violations of these Terms, or events beyond reasonable control are outside the platform’s responsibility. If an incident is confirmed to be a VMOrbit service event, the remedy, scope, and outcome are determined by these Terms, valid service records, and the relevant ticket resolution.

Users should submit a ticket through the console promptly after discovering an incident and provide the node region, time of occurrence, reproduction steps, error details, and impact scope. Missing verifiable information may extend the assessment time.

VMOrbit is responsible for delivering and operating the agreed physical node but does not replace the user’s own data governance processes. Users should establish independent backups based on project value, recovery objectives, and team permissions, and verify that backups can actually be restored.

After the rental term ends, users may no longer be able to access the node. Do not rely on temporary access after service ends to migrate data, and do not keep the only copy on a single node for an extended period. An additional SSD expands node storage; it is not an independent backup service.

VMOrbit may suspend specific capabilities, restrict node connections, or terminate related services based on the level of risk when any of the following occurs:

• The order expires, required payment is incomplete, or payment records cannot be matched to the order.
• The user violates acceptable-use rules and the conduct has affected or may affect the node, network, or other users.
• The account or node presents an immediate security risk, including compromised credentials, unusual automation, or unauthorized access.
• The user submits a termination request and completes the required identity and order verification.
• The information provided by the user remains inaccurate, preventing order, payment, or security processes from continuing.

When advance notice is possible without increasing risk, VMOrbit will explain the issue and actionable remediation steps through the account record or a support ticket. When immediate risk control is necessary, access may be restricted first, followed by an incident explanation.

After service termination, remote access to the node, automated tasks, and instance management will stop. Users must complete data export, credential revocation, and pipeline migration before the rental term ends. Termination does not waive payment obligations, violation handling, or other duties incurred before termination.

To the extent permitted by applicable rules, VMOrbit’s liability for the service will remain reasonably proportionate to the confirmed incident, affected order, and verifiable loss. VMOrbit is not responsible beyond its control for losses caused by the user’s failure to maintain backups, incorrect project configuration, compromised credentials, reliance on third-party systems, or violation of these Terms.

If performance is prevented by natural disasters, widespread public infrastructure failures, government actions, war, social unrest, or other events beyond the parties’ reasonable control, the affected party will notify the other party promptly where feasible and take reasonable steps to reduce the impact.

VMOrbit may update these Terms due to changes in product capabilities, operational processes, security requirements, or applicable obligations. Changes that materially affect user rights or responsibilities will be announced through the website, account records, or the relevant session. Updated Terms apply to subsequent use from the stated effective date; confirmed orders are governed by their confirmation records and applicable Terms.

These Terms are governed by the laws of the jurisdiction where the platform operator is based. The parties should first discuss the disputed facts, order records, and proposed resolution through a support ticket or support email. Disputes that cannot be resolved through negotiation must be submitted to a court with jurisdiction in that jurisdiction.

If any part of these Terms is found unenforceable, the remaining provisions remain effective. VMOrbit’s failure to immediately enforce a right does not constitute a waiver of that right.