Dedicated physical nodes, governed by one set of rules from order to completion

Service definition

RunnerVM provides Cloud Mac services for iOS and macOS development, CI/CD, and related computing tasks. Each valid order corresponds to one dedicated physical Mac mini node, together with the connectivity, basic management, order lookup, and technical support needed to use it. The delivered resource is not a virtual machine, and its operating system instance is not shared with other customers.

“Node” means the physical device specified in the order; “region” means the service location where the device is hosted; “rental term” means the day, week, month, or quarter specified in the order; and “add-ons” means storage expansion or Thunderbolt 5 parallel connectivity purchased with the host. An add-on is part of the service only when it is expressly listed in the order record.

The service allows users to connect to nodes through authorized graphical interfaces or command-line tools, install tools required by their projects, and run build, test, automation, and experimental tasks. The service does not include creating, reviewing, or long-term storing user project code, signing materials, third-party software licenses, or business data. Users are responsible for confirming the source of these materials and their rights to use them.

Orders and delivery

The order is governed by the model, region, term, quantity, and add-ons finally confirmed in the console. Combinations listed in the current catalog can be ordered, but actual availability is determined by the console in real time. A configuration that has not completed settlement, identity verification, or risk verification is not an active order and does not reserve a device.

After settlement and any required verification are complete, RunnerVM prepares the node and connection details according to the order. Delivery is considered complete when the node is linked to the order, required credentials have been provided, and the user can initiate a connection by following the support guide. After receiving the delivery details, users should promptly verify the model, region, and add-ons, then change the initial password, verify the host fingerprint, and review the access scope.

If the delivery details do not match the order, submit a console ticket with the order ID, node region, time of discovery, and description of the discrepancy. To avoid increasing security risk, do not import certificates, keys, or production data to a node that has not been verified.

Pricing and billing

The order price is determined by the selected model, rental term, and add-ons and is shown before payment is submitted. All orders are priced and settled in US dollars (USD). Prices for different cycles are independent catalog prices and must not be interpreted as automatic conversions, discount commitments, or long-term price locks.

RunnerVM supports USDT-TRC20, plus Visa, Mastercard, and Amex through Stripe. The payment gateways available to you are determined by the console. Verify the payment network, amount, order ID, and recipient details. For reconciliation requests caused by selecting the wrong network, entering incorrect information, or making a duplicate payment, submit verifiable records through a console ticket.

Payment status is determined by the order record and confirmation of funds received. An on-chain transaction ID, payment processing record, or card preauthorization alone does not mean that the order is active. If manual payment verification is required, retain the transaction time, amount, payment method category, and order number. Do not submit complete sensitive payment information through public channels.

Rental periods and renewals

The rental term begins at the service start time shown in the order record and ends when the applicable day, week, month, or quarter cycle is complete. The console record governs the service start time, expiration time, and order status. Before expiration, users should review build queues, export artifacts, migrate necessary data, and handle any renewal requirements.

Renewal does not automatically extend the original order indefinitely. Users must submit and complete a new renewal order before the current term ends. Node retention arrangements enter the execution process only after the renewal order has been settled and confirmed. An unpaid request, a payment awaiting verification, or an application still under risk review does not create a right to continued use of the current device.

When the rental term expires without a valid renewal order, RunnerVM may revoke connection credentials, stop user tasks, and begin device recovery. Users should export and back up their data before expiration and should not treat the node as their only data copy. The feasibility of recovery after expiration depends on device processing and security status and does not replace the user’s own backup procedures.

Acceptable use

Users may use nodes only for lawful, authorized development, build, testing, automation, and computing tasks. Do not use a node to access accounts, systems, networks, or data without authorization, or to bypass authentication, access controls, rate limits, or other security measures.

Do not distribute malware, run unauthorized scans or attacks, send abusive traffic, interfere with domain resolution or network services, consume third-party computing resources, or engage in conduct that could harm the stability of other devices, nodes, or networks. Users must not use the service to infringe copyrights, trademarks, trade secrets, privacy rights, or other lawful rights.

Users must manage concurrent tasks, disk writes, network connections, and automated retries reasonably. If a script runs out of control, credentials are exposed, or project dependencies cause abnormal traffic, immediately stop the relevant tasks, rotate credentials, and report the matter through a console ticket. RunnerVM may apply connection limits, task isolation, or temporary suspension to control risk and will record the basis for its action.

Availability and service continuity

RunnerVM targets 99.9% availability. All nodes operate normally 365 days a year, with no fixed downtime period. Public status records from the past 90 days describe observed service performance but do not guarantee the future outcome of every order, network path, or user task.

Availability is assessed primarily by whether the node associated with the order can provide the agreed connectivity and computing capacity, using platform monitoring, node logs, network records, and user-submitted evidence. A single build failure, project configuration error, dependency source issue, user network interruption, invalid credential, or user-initiated task shutdown does not necessarily mean that the node was unavailable.

In the event of hardware failure, a security incident, or a connectivity issue, RunnerVM may take emergency security measures, isolate the network, inspect the device, or assist with migration. Effects involving external networks, the user’s local network, third-party dependencies, user scripts, or user configuration will be assessed against the verifiable evidence. Effects caused by force majeure will be handled based on the facts of the event and applicable rules.

Service credits and compensation

If a user believes an order was affected by a node unavailability event, they should submit a verification request through a console ticket as soon as possible after the event ends. The request must include at least the order ID, node region, start and end times of the impact, connection method, error symptoms, troubleshooting steps already taken, and logs or screenshots showing the scope of the impact.

RunnerVM will use platform monitoring, node logs, network records, and user evidence to determine whether the event was a service-side availability issue and will verify its duration and actual impact. Requests missing an order ID, time range, or verifiable evidence may require additional information. Users must redact keys, tokens, and personal data from logs.

The scope of any service credit, term adjustment, or other remedy approved after verification is determined by the applicable Terms, the event’s impact, and the verification result. Remedies apply only to the affected active order and do not automatically extend to unaffected tasks, related projects, expected revenue, or other indirect results. The same event will not be counted more than once for remedies of the same nature.

Suspension, termination, and liability

If RunnerVM detects exposed credentials, unauthorized access, malicious tasks, abnormal network activity, or another clear security risk, it may first restrict connections, isolate the node, or suspend related tasks and then communicate with the user based on the severity of the incident. Actions must be proportionate to the risk, with necessary records retained to prevent the risk from continuing to affect the user, other devices, or networks.

RunnerVM may suspend or terminate the relevant services if a user violates the acceptable-use rules, refuses to cooperate with necessary security verification, continues to generate abusive traffic, or fails to renew after the rental term expires. For issues that can be corrected, RunnerVM may require remediation within a specified period. It may take immediate protective measures in cases involving ongoing attacks, malware distribution, or a serious security risk.

Users are responsible for maintaining independent backups of project code, build artifacts, keys, certificates, and business data and for completing migration before the order ends. Each party is responsible, under the applicable Terms and based on actual evidence, for losses that can be directly demonstrated and have a reasonable causal connection to a breach. Indirect losses will be assessed and handled with regard to applicable law, the nature of the conduct, foreseeability, and reasonable mitigation measures taken by both parties.

These Terms are governed by the laws of the jurisdiction where the platform operator is based. For disputes arising from these Terms, an order, or use of the service, the parties should first negotiate in good faith through support records and console tickets. If negotiations do not resolve the dispute, either party may bring a claim before a court with jurisdiction in that jurisdiction.

If any part of these Terms is found unenforceable, the remaining parts will continue to apply according to their original purpose. RunnerVM may update these Terms due to product workflows, payment processing, security requirements, or legal obligations. Material changes affecting user rights or obligations will be communicated through appropriate in-product channels and will take effect at the published effective time.