BerryVM provides a dedicated physical Cloud Mac node. Instead of sending you through a generic help directory, we help you identify the affected layer first and then collect evidence in order. Most environment issues can be narrowed to connection, system, dependencies, builds, or networking before you submit a ticket.
Access details are only for establishing the initial session. A successful connection does not complete delivery verification. Update credentials, confirm the device configuration and node, then move your code, secrets, or build jobs onto the machine.
Confirm that the order ID, assigned node, device name, connection method, and details update time match. Never forward access details to public channels or store credentials in a project repository.
After establishing a session with the delivered details, immediately replace them with strong credentials managed by your team. Give each member a separately controlled access method instead of sharing one secret long term.
Check the chip, memory, storage capacity, macOS version, time zone, and free disk space. The base tier should be M4, 16GB, 256GB; the high-memory tier should be M4 Pro, 64GB, 2TB.
Verify both the graphical interface and command-line path, and record the local network, connection protocol, and test time. Run long jobs in a recoverable session or Runner rather than relying on one foreground window to stay online.
Pin system and tool versions first, then restore dependencies, caches, and the Runner. Leave a repeatable checklist at every step so future migrations, rebuilds, and device expansion do not depend on personal memory.
Confirm the project’s required major version, command-line tools path, available SDKs, and build targets. Before upgrading, check compatibility with the existing pipeline and dependencies.
Check the actual paths for the compiler, Git, Shell, Ruby, Python, and Node.js to prevent interactive sessions and the Runner from reading different environments.
Export lists of formulae, casks, and private sources, then restore them in batches as the project requires. Verify versions individually after migration instead of copying an unknown directory wholesale.
Compare the Swift and SDK combination with the project declaration. Use a minimal project to verify compilation, testing, and archiving before running the full project.
Confirm the execution user, working directory, environment-variable sources, cache location, concurrency, and log-retention policy. Inject sensitive values through controlled variables.
Repositories, build caches, signing materials, and access credentials are different data types. Migrate them separately with least privilege, retain only diagnostic fields in logs, and redact them before submitting a support request.
Review security measuresReproduce the issue and preserve the failure state, then change only one condition. These five paths cover connection, builds, disk, dependencies, and node networking; each lists the evidence to collect before requesting support.
First confirm that the order is within its active rental period, access details are current, and the target node and protocol are correct. Then test from another local network to distinguish client settings, local egress, and node-route issues.
Run the same commit, tool versions, and command again. First stop unrelated concurrent jobs, then compare the user, paths, environment variables, and permissions in the interactive session and Runner.
Check the project workspace, build artifacts, simulator data, package-manager caches, and Runner caches separately. Do not look only at total root-directory usage; identify the fastest-growing directory and confirm whether it can be safely rebuilt.
Check lockfiles, package sources, proxies, architecture, and execution user. Save the failure output before clearing caches; indiscriminate deletion can erase a comparable failure state and add download and resolution variables.
Sample continuously from the same source, with the same protocol and at similar times, then compare with another network egress. A single ping cannot represent the full path for artifact uploads, repository pulls, or remote desktop sessions.
Availability is not the speed of one connection, nor does it equal the quality of any third-party network path. When assessing a service event, consider node status records, order validity, impact scope, and the measurement definitions in the service terms.
All nodes operate 365 days a year. Scope, exclusions, claim deadlines, and compensation are governed by the service terms.
View measurement and compensation termsStatus cells provide a quick view of daily records; ticket decisions are based on verifiable node records, affected times, and the applicable scope of the service terms.
Articles are sorted by publication date and cover MLX, Homebrew, deployment-model comparisons, React Native builds, remote-debugging preparation, and data-protection boundaries.
Knowledge-base articles will appear here by date after publication. For now, use the checklists above to troubleshoot connections, environments, builds, and networks.
From environment checks and Python dependencies to model loading, learn how to build a reproducible MLX experiment environment on a dedicated physical machine, including memory needs, data paths, and items to confirm in a remote session.
Read the full guideUse a checklist to migrate formulae, casks, private sources, and project dependencies, then manage credentials, pin versions, and verify the migration.
View the migration checklistCompare the boundaries of both deployment models across resource exclusivity, environment consistency, delivery time, scaling flexibility, and cost structure.
See the decision criteriaUnderstand the cloud collaboration between JavaScript dependencies, native modules, Xcode projects, signing materials, and build artifacts.
View the build workflowClarify the roles of the Cloud Mac and external test environment across device access, signing permissions, network paths, log collection, and team collaboration.
View preparation stepsUnderstand data responsibilities during the rental period, access controls, log redaction, post-service handling, and how to choose nodes across regions.
View data boundariesSupport staff first need to reproduce or locate the fault layer. Complete context reduces follow-up, but do not send access passwords, tokens, private keys, or unredacted project data merely for completeness.
Tickets can link the order and node records, making them suitable for connection issues, device status, build environments, billing, and service events. After submitting, add redacted logs and reproduction results in the same thread.
Log in to the console and create a ticketChoose the channel that preserves the most relevant context. Send active device issues through a console ticket first; for general questions before ordering, contact support by email.
Describe the target workload, candidate configuration, expected rental period, and your team’s region. Do not send sensitive project files; describe only the task type and resource requirements.
View contact methodsLog in to the console and reference the specific order. BerryVM bills exclusively in USD and supports only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe).
Submit a billing ticketInclude the order ID, node, incident time with time zone, impact scope, reproduction steps, and redacted logs. Do not submit only screenshots or send access credentials.
Submit an incident ticket nowBerry M4 suits lightweight builds and everyday development; Berry M4 Pro is designed for memory-intensive builds and MLX experiments. Before ordering, verify the model, daily, weekly, monthly, or quarterly term, node, and additional storage.