MiniRent provides dedicated physical cloud Mac nodes with no shared virtual-machine resources between renters. This page explains who manages platform controls, device accounts, SSH connections, build materials, and third-party development tools—and what to do when something goes wrong.
Dedicated physical hardware removes tenant resource contention found in shared virtual machines, but it does not replace account permissions, key rotation, or build artifact cleanup. A secure model requires all three layers—platform, renter team, and tools—to work together.
Responsible for physical node allocation, console access, connection details, order and device status records, and handling confirmed service incidents.
Responsible for device accounts, SSH public keys, code repository tokens, signing materials, environment variables, member permissions, and data cleanup before the rental ends.
Xcode, fastlane, dependency managers, and pipeline Runners each store their own configuration, caches, and logs. Teams should set versions, permissions, and cleanup policies according to each tool’s capabilities.
A first connection is not simply a matter of entering an address and continuing. Get the connection details from the console, verify the host fingerprint, and establish the session with a registered SSH public key. Never forward private keys through chat history, public documents, or repository files.
Generate separate keys for each person or automation task; never let multiple members share one private key.
On the first connection or whenever the access point changes, compare the host fingerprint shown locally with the console record.
Use a standard account for routine builds and elevate privileges temporarily only when installing components or changing system settings.
The most common automation build risk is not shared device resources, but long-lived tokens ending up in scripts, logs, or caches. Design permissions, lifetimes, injection points, and cleanup actions for sensitive materials together.
| Material | Access boundary | Recommended injection method | Action after task completion |
|---|---|---|---|
| Code repository token | Limit to required repositories and operations; prefer read-only access | Inject through controlled environment variables or pipeline secrets | Revoke short-lived tokens and check the workspace and remote URLs |
| Signing certificate and private key | Allow access only to the signing-task account | Import into a controlled keychain when the build starts | Delete the temporary keychain and imported files |
| Provisioning profile | Limit to the target app and build purpose | Copy to a temporary directory through a controlled job | Clear the temporary copy and verify archived contents |
| Environment variable | Separate by project and environment; do not reuse across tasks | Write to the process environment at pipeline runtime | End the process and delete temporary configuration and shell history remnants |
| Build artifacts and logs | Readable only by project members and the delivery workflow | Output to a dedicated task directory | Move required artifacts and delete the rest according to retention rules |
When a build only needs to pull code, do not grant repository write or member-management access. Keep signing materials for one project unavailable to tasks from other projects.
Do not retain task-scoped credentials long term. Store fixed credentials in controlled secret storage and define clear rotation triggers.
Check temporary directories, keychains, environment files, shell history, dependency configuration, build logs, and artifact directories—not just the source code.
Both MiniRent models are available in Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the Eastern United States. Choose a node near your main development team or code repository; actual availability is shown in real time in the console.
Ideal for Southeast Asian teams and regional pipeline entry points.
Ideal for development and build workloads in Japan and East Asia.
Ideal for Korean teams and regional collaboration environments.
Ideal for cross-region collaboration across South China and Southeast Asia.
Ideal for workflows in the eastern US and across the Atlantic.
Used for orders, device status, connection details, and support tickets. Administrative operations should not be used as a data channel for build scripts.
SSH and VNC sessions provide direct device access. Teams should restrict source networks, verify connection details, and end sessions when leaving the device.
Submit a ticket through the console when you need to change nodes. Before migration, back up required artifacts, revoke temporary credentials, and verify the new host fingerprint.
Verify the device identifier, node, time zone, and time window in which the anomaly occurred.
Check for recently added public keys, device accounts, Runner registrations, and permission changes.
Revoke suspicious keys and tokens, pause the related automation tasks, and retain redacted logs.
Submit reproducible details through a console ticket or to support@minirents.com.
All nodes are provided for continuous operation. Service incidents are assessed using console records, node status, and confirmed support findings.
When reporting a security issue, the most valuable details are the device identifier, node, time window, reproduction steps, impact, and redacted logs. Complete keys, passwords, and access tokens do not help investigation and may increase risk.
Record the symptoms, device identifier, node, time zone, first occurrence, and last known normal action. Distinguish connection failures, permission changes, unusual processes, and exposed build materials.
Revoke related SSH public keys, repository tokens, and pipeline keys, and stop suspicious Runners or tasks. Do not overwrite logs in bulk before recording key information.
Save command times, error codes, process information, and necessary context; hide passwords, private keys, complete tokens, signing materials, and command lines containing sensitive parameters.
Sign in to the console to submit a ticket, or email support@minirents.com. Put “Security report” in the subject and include the impact, reproduction steps, and containment actions already taken.
Rotate affected credentials, review member permissions and automation settings, then use a minimal test task to verify connections, dependencies, signing, and artifact output. Restore full concurrency only after confirming there are no anomalies.
This checklist applies to individual development, team build farms, and self-hosted Runners. Assign each item to an owner and automation script instead of keeping it only in internal documentation.
Get connection details from the console and verify the node, device identifier, and host fingerprint.
Enable strong authentication for work email, code repositories, and pipeline systems, and protect recovery credentials.
Use a separate identity for every member and automation task to avoid untraceable shared keys.
Pin versions and assess updates, prioritizing security fixes for build tools, dependency managers, and Runners.
Prevent build caches from filling the disk and check that logs do not accidentally contain environment variables or access tokens.
Remove code, keys, tokens, signing materials, temporary keychains, build artifacts, and unnecessary caches.
Both physical machine models support the five available nodes. After ordering, retrieve device status and connection details from the console; submit a ticket for issues with an existing device.