Cloud Mac Rental & Use Terms

1. Acceptance of Terms and Service Definition

MiniBinary provides rentals of dedicated physical Cloud Macs and related remote access capabilities. Each valid order corresponds to a genuine Apple Silicon physical node, with processor, memory, and local storage resources not shared with other tenants. The service is delivered as a physical machine, not a virtual machine or shared compute instance substituted for the dedicated device specified in the order.

The service includes use of the selected physical node, system initialization, access credential generation, console-based order management, and support related to node connectivity, billing, and troubleshooting. Ownership of the device does not transfer through rental; you receive remote usage rights for the order term and the purposes permitted by these Terms.

Placing an order, completing payment, receiving access credentials, or continuing to use a delivered node means that you agree to these Terms and the configuration, term, region, and add-ons shown on the order page. Anyone ordering on behalf of an organization must confirm that they are authorized to accept these Terms and manage the order for that organization.

2. Accounts and Orders

You must provide accurate, complete information suitable for order-related communication. Order numbers, device information, access addresses, and credentials are sensitive information. Limit who can access them, and do not distribute them through public code repositories, public documentation, or uncontrolled messaging channels.

You are responsible for orders, renewals, configuration confirmations, support tickets, and node operations initiated through your account. For collaborative work, establish clear permission assignments and credential-rotation procedures. Revoke access promptly when someone no longer needs it.

If credentials may have been exposed, order information appears abnormal, or unauthorized activity occurs, immediately update any credentials that can be changed and submit a console ticket with the order number, discovery time, scope of impact, and measures already taken. To reduce further exposure, do not paste complete passwords, private keys, or access tokens into tickets.

The console record controls. Before payment, verify the model, term, node, storage expansion, and Thunderbolt 5 parallel-connection option. After payment confirmation, submit a ticket as soon as possible if an unprocessed order needs adjustment. Whether an adjustment is possible depends on the order’s processing stage and the result returned by the console.

3. Configurations, Nodes, and Delivery

Three configurations are available: MB M4 16 with M4, 16GB RAM, and a 256GB SSD; MB M4 24 with M4, 24GB RAM, and a 512GB SSD; and MB M4 Pro 64 with M4 Pro, 64GB RAM, and a 2TB SSD. Delivery is based on the model, term, region, and add-ons finally confirmed by you.

The regions currently available are Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and US West—a total of 5 nodes. All model-and-node combinations are part of the regular catalog; actual availability at checkout is determined by the real-time result returned by the console.

Standard delivery typically proceeds through payment confirmation, node allocation, system initialization, and access credential generation. Each stage typically takes about 1 minute, for a typical total of about 4 minutes. Payment network confirmation, option verification, or additional security checks may affect the actual completion time. The order progress status controls.

After delivery, verify the node region, device model, chip, memory, storage capacity, system status, and access credentials. If the order record and device information do not match, pause workload deployment and submit a console ticket so the information can be checked against the order record.

4. Pricing and Payment

The service is available for daily, weekly, monthly, and quarterly rental, all billed in US dollars (USD). You must pay the total for the base configuration, term, and add-ons shown on the order confirmation page. Each billing period is priced independently and is not calculated as a simple multiple; for renewals, use the current order amount displayed in the console.

Payment methods are limited to USDT-TRC20 and Visa / Mastercard / Amex (via Stripe). Actual gateway availability is determined by the backend response from the console. Transfer fees for on-chain payments are handled by the payer under the rules of their wallet or service provider; card payments are subject to identity and transaction checks in the payment flow.

Ensure that the transfer network, amount, and recipient information match the order page. If an incorrect network or address is selected, or an amount inconsistent with the order is sent, verification requires the transaction ID and order number. Verifiable information for card transactions is based on the records returned by the payment flow.

Billing, order status, and payment results are governed by the console record. If you have questions about an amount or status, submit a console ticket with the order number, payment method, payment time, and verifiable transaction information. Do not submit complete card details or private wallet credentials.

5. Renewal, Expiry, and Data Handling

You can view the order term and expiry status in the console and renew when renewal is available. After a successful renewal, the new service term is based on the order record generated by the console. Allow sufficient time for payment confirmation and avoid waiting until an active build, test, or inference task is close to expiry.

After the service expires, remote access to the node may stop and running tasks may not continue. Before expiry, migrate and verify your code, build artifacts, model files, logs, and other business data. Do not use the Cloud Mac as your only copy.

After migration, confirm that files at the destination can be read, have the correct versions, and have the expected permissions. A transfer-complete notice is not a substitute for an integrity check; important projects can be verified using file counts, checksums, or build results.

After an order ends or expires, its node enters the service reclamation process. Do not assume that you can continue accessing the original system or recover data that was not migrated. Teams with business continuity requirements should define the renewal owner, expiry reminder owner, and data migration checklist in their internal procedures.

6. Acceptable Use

You may use the service only for lawful, authorized development, builds, testing, continuous integration, remote development, and model inference that comply with these Terms. Ensure that you have the necessary rights to upload, process, or distribute any code, data, or content.

You must not use or assist others in using a node for unlawful activity, unauthorized access, credential theft, malware distribution, mass exploitation of vulnerabilities, abusive network scanning, denial-of-service attacks, spam, or bypassing access controls or security detection.

You must not endanger the stability of nodes, networks, or related infrastructure through sustained abnormal traffic, destructive processes, malicious resource consumption, or other means. Stress testing, port scanning, and security research may target only systems you are authorized to test, with the scope, rate, and impact controlled.

You must not sell, transfer, or publicly share node access credentials, or use technical means to circumvent order terms, configuration limits, or access controls. Collaborative work must use auditable internal authorization procedures, and access must be revoked promptly when a member leaves the project.

If you discover anomalous behavior that may affect other systems or infrastructure, MiniBinary may take necessary measures such as restricting related connections, suspending high-risk processes, or temporarily blocking access, and explain through account information or ticket records what you need to verify. You must cooperate by providing reproducible steps, a time range, and redacted logs.

7. Service Continuity and Service Target

All nodes operate continuously 365 days a year without scheduled downtime periods. MiniBinary sets a 99.9% service target based on the remote accessibility of the node assigned to each valid order.

In the event of an unexpected hardware, power, network, or security incident, the platform may respond immediately and perform node recovery, connection repair, or other necessary actions based on the scope of impact. Avoid repeated restarts, deleting diagnostic information, or continuing operations that may increase the impact.

Inaccessibility caused by your system configuration, incorrect credentials, local network, browser environment, installed software, workload, voluntary restart, or force majeure is excluded from service-side availability statistics. The determination is based on node records, ticket information, and test results verifiable by both parties.

If you believe the service target was not met during the valid rental term, log in to the console and submit a ticket with the order number, node, start and end times of the impact, error details, local network information, and necessary logs. Eligible requests will be reviewed under these Terms and handled through service credits; the ticket status controls the outcome.

8. Limitation of Liability and User Indemnification

To the extent permitted by applicable law, each party’s liability should reasonably correspond to the verifiable direct impact, degree of fault, and amount of the relevant order. The service target, service credits, order records, and ticket records together form important evidence for handling service issues.

You are responsible for backup and recovery arrangements for your code, data, dependencies, build artifacts, keys, and business processes. Before system upgrades, permission changes, disk cleanup, or bulk automation, verify your rollback plan. You bear responsibility for consequences arising from your instructions, software, incorrect configuration, or unauthorized third-party operations.

If you violate the Acceptable Use rules, infringe third-party rights, process data beyond your authorization, or conduct unlawful activity through a node, and this causes verifiable claims, costs, or infrastructure damage, you are responsible for the consequences directly related to your conduct and must cooperate in stopping the impact, preserving evidence, and completing necessary remediation.

MiniBinary primarily handles service-side failures by restoring access, verifying impact, and providing service credits under applicable rules. Any liability arrangement is governed by the law of the jurisdiction where the platform operator is based and does not exclude statutory liability that cannot be limited by contract under that law.

9. Changes, Termination, and Contact

MiniBinary may update these Terms based on service capabilities, security requirements, payment processes, or applicable rules. Material changes will be described through the website, console, or account-related notices. Updated Terms apply to new orders from the stated effective date and to continued use of services as described in the notice.

If you do not accept an update, you may stop placing new orders and migrate your data before existing orders expire. Continuing to order, renew, or use the relevant services means that you accept the version of the Terms then in effect.

If there is a serious violation of the Acceptable Use rules, a payment anomaly, a risk of unauthorized access, a threat to node stability, or a legal requirement to act, MiniBinary may restrict, suspend, or terminate the relevant services. Measures will reflect the risk level, verifiable records, and necessity of the response; where appropriate, we will tell you what verification steps are required.

The parties should first resolve disputes through verifiable written communication. You may log in to the console to submit a ticket or email support@minibinary.com with the order number, subject of the dispute, timeline, desired resolution, and relevant evidence.

These Terms are governed by the law of the jurisdiction where the platform operator is based. Any dispute that cannot be resolved through communication will be handled by a court with jurisdiction in that jurisdiction.