Dedicated compute & local storage

Define your data boundaries before connecting a cloud Mac to your workflow

Each active order maps to one dedicated physical Mac mini. Its compute resources and local device storage are not shared with other tenants. Security is still a shared responsibility: the platform manages the physical node and service control plane, while you manage your account, connection credentials, code, and third-party tool permissions.

View secure connection guide Report a security issue

1 order maps to 1 dedicated physical node

Not shared compute resources and local device storage

365 days nodes remain in normal operation

Device security record CONTROL / DATA / RECYCLE

Boundaries defined

Compute ownership: One active order
Device type: Dedicated physical Mac mini
Access paths: Console and device credentials separated
Action checks: Sensitive actions verified again
Monitoring scope: Infrastructure status and security events
End of rental: Access revoked and cleanup begins

A physical device still needs a defined security strategy. Dedicated hardware reduces resource sharing between tenants, but account protection, key rotation, least privilege, and backups must still be handled within the project.

Security model

Isolation starts with device ownership

MiniRent provides a dedicated physical machine rather than splitting one device's processor, memory, or local SSD among multiple tenants. Orders, devices, and access records form an ownership chain that can be verified.

Dedicated per device

During an active rental, the Mac mini assigned to an order is used by that order. Compute tasks, memory state, and local device storage are not allocated to other tenants as shared virtual resources.

Control plane separated

The console is used to view order and service records and submit tickets. Device connection credentials provide access to the macOS graphical interface or command line. Never reuse either credential type or store both in the same shared document.

Permissions follow the task

Configure separate permissions for build accounts, CI runners, and human remote sessions. Grant each task access only to the directories, commands, and tokens it needs instead of giving automation long-lived privileged credentials.

Account and console security

Treat login sessions as device-control access

Accounts can view order-linked information and initiate service actions. Assign access by person and avoid having multiple people share the same login details indefinitely.

Account checklist

Check before login, during use, and after team changes

Store login credentials separatelyUse a team-approved password management method. Never pass credentials through repositories, chat history, or build logs.
Sign out after each sessionAfter working from a shared workstation or temporary browser environment, sign out of the console and close pages that remain logged in.
Recheck sensitive actionsBefore changing a billing period, device configuration, or access details, verify the order number, device identifier, and scope of impact.
Remove access immediatelyWhen a member leaves the project, changes roles, or finishes contract work, revoke shared access and rotate any credentials they may have accessed.

Spot unusual activity

Stop sharing the affected credentials, record the time, related order, and observable symptoms, then submit a ticket through the console. Do not include unsanitized keys or complete certificates in the ticket body.

Submit console ticket

Credentials may be exposed

Immediately rotate affected login details, SSH keys, repository tokens, and signing materials. Then check automation tasks, recent login records, and build logs for unusual use.

View response steps

Device access control

Use separate, revocable credentials for every connection method

Design remote access around who is accessing which device, for which task, and when. One shared long-lived key may seem convenient, but it makes revocation and incident tracing difficult.

01

Create a dedicated SSH key for the cloud Mac

Do not reuse the default key from your everyday personal device. Separate keys by team, project, or automation task, and protect private keys locally as appropriate.
02

Record access by person and task

Maintain a clear access list on the device. CI runners, developers, and temporary troubleshooters should use different credentials so each can be revoked independently.
03

Restrict remote access sources

Limit permitted connection sources based on your team's network conditions. Keep unnecessary public services disabled and close temporary ports when the task ends.
04

Rotate keys and verify old access is revoked

After rotation, deploy the new credentials and verify that old keys can no longer establish a session. Rotate immediately after personnel changes or suspected exposure rather than waiting for the normal cycle.

Handle idle sessions When remote work is complete, exit both the graphical session and command-line connection. Do not leave a privileged terminal unattended.

Troubleshoot connection failures Check the device identifier, network source, username, key permissions, and remote service status in order. Do not broaden public access just to troubleshoot.

Data transfer and storage

Manage code, certificates, keys, and build artifacts separately

The local SSD is dedicated to your order, but data security still depends on transfer methods, directory permissions, backup locations, and cleanup habits. Sensitive materials need stricter handling than ordinary source code.

Transfer

Use encrypted channels

Sync data over SSH, encrypted repository connections, or another secure transfer method approved by your team. Never place certificates, private keys, or unsanitized build packages at public download URLs.

Permissions

Apply least privilege

Limit access to sensitive directories and separate build accounts from everyday interactive accounts. Scripts should receive only the file and command permissions required to complete the task.

Backups

Keep necessary copies

Define separate backup policies for source code, build configuration, certificate backups, and artifacts that cannot be recreated. Local device data should never be the project's only copy.

Cleanup

Minimise sensitive data exposure

Delete temporary certificates, exported key files, and one-time artifacts promptly after the task. Check caches, temporary directories, and pipeline workspaces as well.

Common data types and recommended controls
Data type	Primary risk	Recommended storage	Check before leaving the device
Source code and dependency configuration	Expanded repository access, private URLs entering logs	Controlled repository with least-privilege read access	Confirm commits are complete and remove temporary credential files
Certificates and signing materials	Uncontrolled copying, expired validity	Store encrypted and import only for the task	Verify exported copies and remove temporary files
API keys and short-lived tokens	Hard-coding, exposure in build output	Runtime injection or controlled secret storage	Revoke unused tokens and check logs
Build artifacts and debug logs	Exposure of paths, user information, or internal URLs	Classify data and set access boundaries	Export required artifacts and delete data with no retention value

CI/CD credential management

Give automation only the access required for one build

Build pipelines often access repositories, dependency services, signing materials, and artifact storage at the same time. Writing a long-lived privileged key directly into a script can turn one leaked log into access risk across multiple systems.

Pipeline security checklist Check each item before committing configuration

5 CONTROLS

Prefer short-lived tokens

Grant access for one repository, one task, and a defined time limit. Do not let automation retain high-privilege credentials covering the entire organisation.

Inject secrets at runtime

Inject them through controlled variables or secret storage. Do not write them into repositories, images, script arguments, or configuration files readable by ordinary members.

Sanitise build logs by default

Avoid printing complete environment variables, request headers, or certificate paths. Add only the logs needed for troubleshooting, then return to the controlled output level.

Clean the workspace after builds

Remove temporary tokens, extracted signing materials, intermediate artifacts, and sensitive cache contents before handing the runner to the next task.

Isolate projects and identities

Use separate execution identities for different repositories or security levels so one project cannot read another project's data through a shared workspace.

Monitoring and incident response

Monitor device health, not the contents of user work

Infrastructure monitoring focuses on node connectivity, device health, resource anomalies, and security signals. User source code, build contents, and business data are not routine operational metrics.

Platform focus

Infrastructure and service health

Whether the physical node remains connected and operational
Whether critical control-plane services are available
Whether the device or network shows abnormal status signals
Whether service actions match the order and authorisation

User-managed

Project content and tool access

Repository, dependency source, and artifact-storage permissions
Certificates, keys, tokens, and build environment variables
Files and commands used during remote sessions
Auditing and access revocation in third-party CI/CD tools

01
Identify
Use status signals, user reports, and service records to confirm what is affected, when it began, and what can be observed.
02
Isolate
Limit affected access paths to prevent further spread while preserving the records needed for investigation.
03
Investigate
Check the device, order, operation records, and sanitised information provided by the user to distinguish infrastructure, credential, and third-party tool issues.
04
Notify and recover
Share actionable information through a ticket or support email, then rotate credentials, restore access, or complete follow-up checks according to the scope of the issue.

End-of-rental cleanup

Export everything first, then end device access

Before the rental ends, confirm that every item you need to keep has a verifiable copy. Once the device is retired, the original access paths are revoked and the device enters the data cleanup process.

Inventory the data to keep

Check source changes, build configuration, signing-material backups, build artifacts, debug logs, and project files that exist only on the local device.

Export and verify copies

Transfer required content to a team-controlled location. Confirm that files open, repository commits are complete, and backups contain what is needed for recovery.

Revoke external authorisations

Remove repository tokens, runner registrations, deployment keys, and temporary certificates used by the device so no orphaned access remains after the rental.

Retire and clean the device

When the rental ends, revoke device access, verify the device-to-order association, and complete the retirement cleanup so the former tenant's credentials and data are not used for subsequent service.

Responsibilities and reporting

Complete reports speed up isolation and diagnosis

Security issues may originate in infrastructure, account or device configuration, repositories, CI platforms, or dependency services. When reporting, distinguish the scope of impact and never submit unsanitised sensitive material.

Platform responsibility

Physical nodes and service control plane

Manage device ownership, infrastructure operations, order associations, access revocation, and device retirement cleanup. Identify infrastructure anomalies and investigate them through the support process.

User responsibility

Accounts, credentials, and work data

Protect console accounts and device credentials; manage code, certificates, tokens, and build artifacts; and apply least privilege, necessary backups, log sanitisation, and personnel access removal.

Third-party tools

Repositories, pipelines, and dependencies

Third-party services handle tokens, logs, and data according to their own permission models. Verify their configuration, access records, and revocation mechanisms, and keep authorisations narrowly scoped.

Before you report

Include these details in a security report

Provide the order number, device identifier, time of the incident, impact scope, reproduction steps, containment actions already taken, and sanitised logs. Do not send private keys, complete tokens, complete certificates, or credentials that can be used to log in directly.

Open contact details Email support@macminirent.com

Ready to bring a security baseline to your first cloud Mac?

Choose the model and node first, then set up dedicated connection credentials, least-privilege access, and backups for your team. Order and manage devices from the console.

Rent a Mac mini View plans