Each active rental maps to one dedicated physical Mac mini—not a virtual machine, and not a device whose processor, memory, or local storage is shared with other tenants. This page explains the security boundary through control objectives, actions, and verifiable records.
Security decisions span three areas: asset ownership, access paths, and delivery status. During a rental, the target Mac mini’s physical compute resources are dedicated to the current tenant. Platform administration is constrained by authorization scope and activity records. At the end of the rental, the device undergoes data cleanup and pre-delivery checks.
The processor, unified memory, and built-in storage are not divided among tenants. Your build queues, caches, test processes, and remote desktop sessions run on the same dedicated device.
Remote connections should use keys wherever possible, while internal platform access follows least privilege. When node work is required, the task scope is confirmed first, followed by permissions appropriate to that task.
Security controls cover provisioning, use, offboarding, media cleanup, and pre-delivery checks rather than treating data handling as one action at rental end.
Submit a console ticket with the order number, node, controls to verify, and time range. Support will compile available records related to device mapping, access handling, or cleanup status. Do not send private keys, complete credentials, or unredacted business data in your message.
Log in to the console and submit a verification ticketAccess control is more than setting a password once. A stronger approach gives user connections, platform administration, and incident handling clear, separate entry points—while allowing credentials to rotate, permissions to be revoked, and actions to be traced.
Configure a personal SSH public key soon after the first connection, and use separate keys for each member, automation Runner, and deployment task. This lets you revoke one identity without replacing every connection credential.
ssh-keygen -t ed25519
Daily build accounts should have only the permissions needed to pull code, install dependencies, run tests, and write to artifact directories. Elevated actions should be tied to specific tasks; do not give persistent Runners capabilities beyond their workloads.
id && groups
When a member leaves, an automation token is exposed, a project ends, or access scope changes, revoke old credentials immediately and generate new ones. Do not share one long-lived token across pipelines or write keys directly into repositories or build logs.
If you detect an unknown-source connection, unusual failed attempts, or activity outside expected working hours, first restrict the source address and revoke related credentials. Then preserve the time range, source address, account, and necessary logs, and submit redacted material through a ticket for node-level investigation.
Identify each identity separately for easier revocation and review.
Narrow reachability to the team network and toolchain.
Run development and build tasks within the tenant device boundary.
Administrative access supports device delivery, troubleshooting, and authorized support operations. Tenant traffic supports SSH, graphical interfaces, code retrieval, dependency downloads, builds, and artifact transfer. These paths should not be combined into one permission scope for convenience.
Only actions required to deliver a node or troubleshoot hardware or network issues should enter the administrative workflow. Confirm the target, reason, and scope before access; require reconfirmation for high-risk actions; then close temporary permissions and retain necessary records.
Open only the services actually in use, restrict administrative-port source addresses, and use separate credentials for file transfer and automation. Close temporary debugging ports immediately after the task, and do not expose databases, caches, or internal panels to unnecessary networks.
Suitable for Southeast Asian teams and cross-region pipelines. Test routing from primary office networks before connecting, and allow only the necessary Runner, repository, and artifact-storage addresses.
Key checks: source restrictions, dependency egress, file-transfer pathsSuitable for projects in Japan and Northeast Asia. Record developer remote sessions and automated build traffic separately, and never copy personal connection credentials to persistent Runners.
Key checks: identity separation, build tokens, session recordsSuitable for South Korean teams and regional testing. Use a separate account for persistent agents, regularly review authorized keys and task labels, and remove unused entry points.
Key checks: persistent agents, authorized keys, task isolationSuitable for teams connecting to code repositories and collaboration networks across Asia. Configure access rules for the actual path; cross-border collaboration should not expand reachability for every port.
Key checks: cross-border routing, port scope, redacted logsSingapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong run 365 days a year. A node determines the connection location, but it does not automatically restrict source addresses, separate team credentials, or close unnecessary services. Configure these controls explicitly for your network and pipelines.
Data security does not happen only at offboarding. Device mapping, permission management during use, tenant migration, media cleanup, and pre-delivery checks form one complete chain.
Confirm the model, memory, storage, rental period, and target node against the order, then link the physical device identifier to the active rental. Check the base system state and remote access path before delivering connection details.
Checks: order number, model, node, device mapping statusCode, dependency caches, build artifacts, and experiment files are stored on the rented device or remote storage configured by the user. Teams should separate accounts, encrypt sensitive files, limit log content, and maintain independent backups for critical data.
Tenant actions: separate permissions, encrypt data, verify backups, redact logsBefore the rental ends, export the code, artifacts, and configuration you need to keep, and verify that backups are readable. Then revoke the node’s tokens and keys from code repositories, CI/CD platforms, and deployment systems, and stop persistent agents.
Completion criteria: data migrated, backups readable, external credentials revokedAfter the device leaves the current rental, it enters the cleanup process. Handle local user data, project files, caches, keys, tokens, and remote-access configuration. Tie cleanup actions to device status rather than simply deleting visible directories before immediate redeployment.
Control objective: previous-tenant data and credentials do not reach the next deliveryBefore the device re-enters the delivery process, verify that old users, keys, persistent tasks, and project data have been removed, and confirm that remote access uses new delivery credentials. Only after passing these checks is the device mapped to the next rental.
Review scope: users, keys, tasks, data directories, connection configurationAudit records support troubleshooting, permission reviews, and security investigations. They focus on necessary facts rather than collecting tenant business content. The main correlation fields are the node, acting identity, authorization reason, time range, and result.
Before changing access, system-level configuration, or data, or taking any action that affects connectivity, clearly confirm the node, impact scope, and expected result.
Task basis, confirmation scope, execution resultRetain the identity, node, time, action type, and status needed for support investigations. Do not put private keys, complete tokens, or business data into records.
Identity, node, time range, action categoryGrant internal access according to role, using task-scoped permissions for temporary work. Revoke capabilities promptly when a person’s role or task status changes.
Authorized identity, reason, permission scope, statusLink support actions to the specific node and issue so later reviews can confirm that authorization boundaries were respected and reconstruct the sequence of key actions during an investigation.
Ticket link, action sequence, resolutionConfirm the target node, issue, permitted actions, and data boundaries that must not be touched. If information is insufficient, gather more evidence rather than expanding access to compensate.
Prefer lower-impact, reversible actions. If the issue differs from the original task, pause further work and reconfirm authorization and impact.
After the task, revoke temporary access and record the actions performed, node status, and recommendations so the next review does not depend on verbal handover.
For unknown logins, exposed credentials, unusual network activity, accidental data deletion, or unexpected node behavior, contain the impact first and preserve evidence. Do not overwrite key logs or continue using potentially exposed credentials just to restore service quickly.
Record the first-seen time, node, account, source address, symptoms, and most recent normal state. Preserve necessary original logs and create a redacted copy for submission.
Restrict anomalous sources, revoke suspected exposed keys or tokens, and pause related automation. Target isolation at the specific entry point where possible to avoid unnecessarily destroying other evidence.
Build a timeline around accounts, nodes, time ranges, network sources, and action sequences. Distinguish user configuration changes, automated task behavior, and node events requiring platform investigation.
Remove anomalous entry points, rotate affected credentials, restore necessary configuration, and verify builds, remote connections, and file access. Recheck authorized keys, persistent processes, and open ports afterward.
Use a ticket or support email to share confirmed facts, impact scope, response actions, and the next steps for users. Associate new evidence with the same order and incident scope.
Provide the order number, node, discovery time range, impact description, reproduction steps, and redacted logs. If you cannot access the console, email support@macrents.com. Do not attach private keys, complete access tokens, certificate passwords, or unprocessed personal data.
The platform provides physical-node isolation and administrative controls, but tenants remain responsible for project accounts, network entry points, keys, tokens, and business data. This checklist applies to remote development, Xcode builds, persistent Runners, and AI experiments.
All three plans use dedicated physical machines, not virtual machines, and are available in Singapore, Japan (Tokyo), South Korea (Seoul), and Hong Kong. Actual availability is based on the console’s real-time status.