BerryVM provides a Mac mini physical node dedicated to one customer throughout the rental term—not a virtual machine. Our security model covers device isolation, access control, operational records, and data boundaries, while clearly defining the customer’s configuration responsibilities.
BerryVM does not split the processor, memory, or local storage of one device among multiple customers. After delivery, the assigned device is dedicated to that customer throughout the term. At the end of the term, access is closed and end-of-service processing begins.
The chip, memory, and built-in storage belong to the assigned Mac mini as a whole. This is a dedicated physical machine—not a shared virtual machine—and resources are not described using oversubscription ratios.
Device identifiers, node details, and access information are delivered with the order. Customers should grant access only to authorized members and rotate credentials immediately when responsibilities change, a collaborator leaves, or exposure is suspected.
Support staff do not treat ongoing access to customer environments as a default requirement. When troubleshooting assistance is needed, define the issue scope, permitted actions, and valid time window in a console ticket, using redacted logs whenever possible.
Access details contain only what is needed to establish the first secure session. After receiving them, verify the device and node, update credentials, restrict sources, and record authorized members.
Match the order ID, device configuration, selected node, and received access details. If anything does not match, stop connecting and open a console ticket.
Do not keep using the initial password for daily collaboration. Set strong new credentials according to your team’s policy, prefer key-based authentication, and store recovery information securely.
Allow only the remote services and source addresses required for the task, disable unused sharing capabilities, and give automation runners separate, revocable authorization.
Record who has access, when credentials were rotated, which pipelines use the device, and who is responsible for revoking access when membership changes.
Troubleshooting normally starts with device status, network paths, and redacted logs. Assistance is provided only when the customer explicitly authorizes it and remote diagnosis is genuinely necessary, within the ticket’s agreed scope.
If credentials may be exposed, first stop affected automation, revoke related access, and rotate the credentials. Preserve the order ID, node, time, source address, and redacted logs, then open a console ticket.
Open a Security TicketCustomer project data primarily resides on the assigned dedicated physical machine. Account details, orders, payment status, support communications, and necessary operational records are handled for their respective purposes. See the Privacy Policy for retention grounds and user rights.
Account contact details, configuration, rental term, node, and payment status are processed to confirm the order, assign a device, and deliver access details. Project source code and production data are not required during activation.
During the term, customers are responsible for repositories, build caches, model files, keys, and artifact permissions on the assigned device. BerryVM processes only records necessary for service operation, security, and support.
After renewal is confirmed, device access continues according to the order. Teams should still rotate credentials on their own schedule, remove expired member access, and review keys used by automation tasks.
When the term ends, customer access is closed and device data is handled according to the service process. Before the end date, export required artifacts, revoke external-system tokens, and ensure no unique copy remains only on the device.
The Privacy Policy explains the handling boundaries for account details, order records, support communications, necessary logs, and device data.
Remote-session risk typically comes from long-lived credentials, overly broad source access, idle services, and untraceable shared access. Use the following checklist as an initialization baseline after delivery.
Enable only the remote services and ports required for the task. Keep unnecessary sharing, discovery, and test services disabled in development environments rather than leaving long-term entry points for temporary troubleshooting.
Check: services, ports, listening addressesUse revocable authentication materials for automation tasks and individual engineers. Do not share one set of long-lived passwords or write private keys directly into repositories, build scripts, or ticket text.
Check: key ownership, storage, revocationLimit source access by team egress, controlled jump paths, or task networks. For cross-region collaboration, confirm the source policy first rather than permanently allowing every address.
Check: source scope, exceptions, expirationRegularly review members, automation runners, remote services, and external tokens. Revoke permissions immediately when someone leaves the project, a pipeline is retired, or the device’s purpose changes.
Check: members, tasks, tokens, anomaly records| Item | Recommended action | Trigger | Records to retain |
|---|---|---|---|
| User access | Review member permissions and revoke expired access | Role change or departure from the project | Authorizer, revocation time, affected device |
| Automation credentials | Rotate keys and verify pipeline recovery | Scheduled rotation or suspected exposure | Key identifier, rotation time, verification result |
| Remote services | Disable idle services and narrow source access | Task completion or network policy change | Port, source rule, change owner |
| Support authorization | Close temporary access and update related credentials | End of ticket investigation | Ticket ID, authorization scope, closure result |
Security incident handling centers on facts and a timeline. Do not send access passwords when reporting an issue; the order ID, node, time, impact scope, reproduction steps, and redacted logs are usually more useful for rapid assessment.
Provide the order ID, node, first-discovered time, affected tasks, and actions already taken. Redact keys, tokens, customer data, and member identity information before attaching logs.
Confirm whether the incident is ongoing, affects one device or an external dependency, and whether credentials must be revoked, pipelines stopped, or source access restricted immediately.
Based on the facts, close affected entry points, revoke related authorization, or pause tasks. Isolation actions should be traceable; avoid deleting key logs before preserving evidence.
After rotating credentials, correcting source rules, updating dependencies, or reverting configuration, use a minimal verification task to confirm that connections, builds, and artifact paths work normally.
Document the timeline, root cause, impact scope, and follow-up actions. Identify any monitoring, permission-revocation, rotation mechanisms, or team checklists that should be added.
When service-side action is involved, use a traceable support path to share confirmed results, progress, and required customer actions. Do not replace conclusions with unverified speculation.
BerryVM targets 99.9% service availability, with all nodes operating normally 365 days a year. Metrics, exclusions, claim deadlines, and applicable compensation are governed by the Terms of Service.
To review a specific service interruption, provide the order ID, node, time, duration, and impact scope. Service-side records and customer logs should use the same time zone or clearly state their time zones.
Report vulnerabilities, security questions, or active incidents through a console ticket, or email support@berryvm.com. Include the order ID, node, timeline, impact scope, and redacted logs. Do not send access credentials, private keys, or unredacted project data.