BerryVM Cloud Mac Rental Terms

These terms apply to individuals and organizations that access the BerryVM website, create or use an account, submit or manage orders, make payments, receive device access details, or use Cloud Mac services. One person may fill multiple roles, or purchasing, finance, engineering, and external collaborators may handle them separately.

Website visitor

Use website content and public tools lawfully. Do not attempt to bypass access controls, disrupt site operations, or bulk-collect restricted information.

Account holder

Responsible for accurate account information, secure login credentials, authorized-member management, and the authenticity of orders, tickets, and activity records in the account.

Order contact

Responsible for verifying the model, location, term, additional storage, Thunderbolt 5 parallel-connection count, payment details, and renewal decision, and for ensuring they are authorized to submit an order for the paying entity.

End user

Responsible for the software, code, data, network activity, and access permissions on the device, and for following these terms and rules applicable to their workload.

When an account holder allows other members to use the service, they must ensure those members know and follow these terms. Actions resulting from member-permission settings, credential sharing, or insufficient internal approval are treated as actions authorized by the account holder unless the account holder promptly reports them and provides verifiable evidence of an anomaly.

BerryVM provides Cloud Mac, physical-node, and dedicated physical machine rentals. Each delivered order corresponds to an entire device assigned for the customer’s use during the active rental term. The service is not a shared virtual machine, and resources from the same device are not simultaneously divided among multiple customers.

The service includes order confirmation, device allocation at the selected location, a base system environment, delivery of access details, order-status records, and console ticket support. Customers may use the macOS graphical interface or command line for approved development, build, testing, and experimental tasks.

The service does not include software licenses purchased independently by the customer, external code repositories, public network links, third-party build platforms, external test devices, or other third-party resources required for the customer’s projects. The customer manages the accounts, fees, compatibility, and security settings for those services.

Available models are limited to Berry M4 and Berry M4 Pro. Both configurations can be selected in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the Eastern United States. Actual availability is based on the live result returned by the console when the order is submitted.

Customers should choose a location and configuration based on their team’s location, code-repository location, artifact-delivery destination, collaboration time zones, memory needs, and storage needs. Network latency depends on the customer’s location, access provider, routing, and access time. Public test data is for path comparison only and does not constitute a fixed latency commitment.

After order confirmation, customers who need to change the location, model, or add-ons should submit a request through the console. Whether a change can be made depends on the current order status, target catalog combination, and live console result. Do not assume that the original order will be migrated automatically or that its existing environment will be preserved without confirmation.

All orders are priced and settled in US dollars (USD). The only supported payment methods are USDT-TRC20 and Visa / Mastercard / Amex (via Stripe). The actually available gateway is determined by the result returned on the checkout page.

The total order amount consists of the selected model, rental term, and add-ons. Before submitting payment, customers should verify the quantity, location, start arrangement, term, storage expansion, and parallel-connection count on the confirmation page. The amount shown and confirmed by the customer there is the order amount.

On-chain payments must use the network, currency, and amount specified on the checkout page. If verification is required because the customer selected the wrong network, used an incompatible asset, underpaid, paid twice, or provided incorrect payment information, processing time depends on the verifiable transaction record. Card payments are authorized and reported by the relevant gateway, and BerryVM processes the order based on the final payment status.

An order is not considered paid until its payment status is confirmed. If a customer believes a payment result is incorrect, they should retain the order ID, transaction ID, or gateway record and submit a ticket through the console. Do not send complete card details, private keys, or access credentials on public pages or in regular email.

An order enters the delivery process after payment is confirmed, the configuration and location selection are valid, and all required information is complete. Delivery is complete when a dedicated physical machine has been assigned and the device identifier, location, term, and access details have been provided through a traceable path within the account.

Start and end times for daily, weekly, monthly, and quarterly rentals are determined by the order confirmation record. The term begins at the service start time recorded in the order and ends at the corresponding end time. Customers should monitor the term in the console and not rely solely on external reminders.

Renewal does not take effect through a verbal arrangement. Customers must confirm and pay for renewal before the current term ends; successful renewal is determined by the console order status. Until renewal is confirmed, the original term is not automatically extended because the customer continues connecting, a ticket remains open, or payment verification is still in progress.

After the term expires without a valid renewal, BerryVM may disable device access and begin the service-end process. Customers should export code, build artifacts, logs, and other data they need to retain before the term ends, revoke external keys, and verify the migration result.

Customers may use Cloud Mac for lawful software development, continuous builds, automated testing, React Native packaging, Swift projects, MLX and AI experiments, and similar tasks, provided that the tasks, data sources, software licenses, and network activity are properly authorized.

• Prohibited unlawful or infringing activity:Do not process clearly unlawful content or infringe intellectual property, privacy, or other lawful rights.
• Prohibited unauthorized access:Do not scan, probe, attempt to enter, or control accounts, devices, networks, or data that you are not authorized to access.
• Prohibited network disruption:Do not launch denial-of-service attacks, distribute malware, spoof origins, persistently abuse bandwidth, or bypass reasonable security restrictions.
• Prohibited interference with other customers:Do not exploit defects in external systems, incorrect routing, or service interfaces to interfere with other orders, nodes, or infrastructure.
• Prohibited concealment of high-risk activity:Do not use multiple accounts, automated requests, or false identities to evade investigations, restrictions, payment verification, or security measures.

Customers are responsible for software installation, dependency sources, key permissions, firewalls, remote-access source restrictions, and log retention on the device. If access details may have been exposed, an unusual process appears, or network activity deviates from expectations, immediately update credentials, restrict access, and submit a ticket through the console.

After receiving a credible security report, rights notice, or infrastructure anomaly signal, BerryVM may request an explanation, suspend specific network activity, isolate relevant access paths, or take necessary risk-control measures. The response should be proportionate to the identified risk, with necessary incident records retained.

Availability events are assessed using verifiable BerryVM status records, device records, and ticket timelines. Customer reports should include the order ID, location, start and end times, symptoms, reproduction steps, and redacted logs to distinguish device failures, customer configuration issues, and public-network path issues.

The following are excluded from BerryVM’s availability responsibility: interruptions caused by the customer’s actions or configuration; resource exhaustion caused by customer software, keys, dependencies, or tasks; failures of third-party services, public networks, customer access lines, or external code repositories; restrictions resulting from the customer’s breach of these terms; events beyond control; and situations where the impact cannot be verified because the customer did not provide necessary information.

Customers must submit a service-credit request through the console within 7 calendar days after the affected rental term ends. Once validated, BerryVM may provide an applicable service credit based on the confirmed duration of the impact, the relevant order amount, and the actual service scope. Credits apply only to the affected order, are not exchangeable for cash, and may not exceed the amount paid for the affected service period.

The availability target does not guarantee customer project artifacts, build completion times, third-party interface responses, or end-to-end network latency. Customers should maintain recoverable code, dependency lists, build-cache strategies, and artifact backups for critical pipelines.

Before an order is completed, customers may use the console to check whether cancellation is available. Once device allocation has begun or delivery is complete, cancellation, changes, and any eligible refund are determined based on actual resource allocation, term status, payment status, and support records.

When ending the service voluntarily, customers should first export data, revoke external access, delete keys no longer needed, and confirm that team members no longer depend on the device. After the service ends, remote access to the device is disabled and the order enters the device-data processing workflow.

If a customer seriously violates acceptable-use rules, threatens the security of other customers or infrastructure, provides fraudulent payment information, or refuses to cooperate with necessary security measures, BerryVM may restrict relevant access or terminate the service. Where risk permits, BerryVM will explain the issue and required action through the account record or order contact. For an active security risk, BerryVM may take isolation measures first and notify the customer afterward.

Device data is handled by service stage: during the active term, the customer manages device content; support access is limited to the scope authorized by the customer and necessary to resolve the issue; after the term ends, access is disabled and device data is handled according to the service process. Customers must not use BerryVM as their sole backup location and should verify that important data has been migrated securely before the service ends.

Accounts, orders, payment status, support communications, security incidents, and necessary technical records may be retained as needed to fulfill orders, resolve disputes, conduct security audits, and meet legal obligations. Device content and website account information are subject to different data-handling scopes; seePrivacy Policy.

Each party is responsible for actions within its control. BerryVM is responsible for providing the dedicated physical machine service according to the confirmed order, maintaining verifiable service records, and handling support requests. Customers are responsible for workload legality, account permissions, device data, software dependencies, keys, and external system configuration.

To the extent permitted by applicable rules, BerryVM is not responsible beyond the direct service relationship for indirect losses, lost anticipated profits, lost business opportunities, data loss caused by the customer’s failure to retain copies, or losses caused by customer software, third-party services, public-network paths, or external platforms.

BerryVM’s aggregate liability for a specific order is capped at the amount actually paid during the relevant service period for the affected order giving rise to the verified claim. This limitation does not exclude liability that cannot legally be limited, nor does it alter the availability-credit process expressly provided in these terms.

Events beyond control include natural events beyond reasonable control that cannot be avoided through ordinary technical and operational measures, widespread public-network failures, energy or communications-infrastructure outages, government action, major security incidents, and other events of a similar nature. The affected party should mitigate the impact where feasible, preserve records, and resume performance.

Third-party payment gateways, code repositories, software sources, external test devices, and other platforms used by the customer are controlled by their respective providers. BerryVM will help provide verifiable information from the service side but cannot replace the third party in handling its accounts, transactions, or system failures.

This version is identified as 2026.09 and takes effect on 2026-09-20. BerryVM may update these terms due to changes in the service catalog, billing process, security requirements, or applicable rules. Material changes will be described through the website, account notifications, or a channel accessible to the order contact, with the effective time of the new version stated.

Updated terms generally apply to orders newly submitted or renewed after their effective date. For orders already confirmed and still within an active term, the model, term price, location, and paid amount are governed by the order confirmation record. Changes required by law, security, or abuse prevention may apply to existing services after notice.

These terms and the resulting service relationship are governed by the laws of the jurisdiction where the platform operator is based. The parties should first resolve disputes through traceable support records and good-faith negotiation. If negotiation fails, a dispute may be submitted to a court with jurisdiction in that jurisdiction.

If any part of these terms is found unenforceable, the remaining parts remain effective. Failure to immediately enforce a right does not waive that right. Order confirmation records, the Privacy Policy, and supplemental arrangements confirmed through verifiable channels may form part of the service agreement together with these terms.

General inquiries, billing questions, active incidents, security reports, and questions about these terms may be sent to support@berryvm.com, or customers may log in to the console to submit a ticket. Include the order ID, issue type, impact period, and necessary redacted records. Do not send access passwords, private keys, or unredacted logs.