Security Model & Shared Responsibilities

Separate isolation, access, and status first—then protect every build.

Each order corresponds to one dedicated physical machine, not a virtual machine. Device isolation is only the starting point; account credentials, remote sessions, signing materials, backups, and project configuration must still be managed separately through engineering workflows.

Rent a Cloud Mac Now View Troubleshooting Paths

Isolation Baseline

1 order corresponds to 1 dedicated host

Compute and local storage are dedicated to the order

Upstream network links are shared infrastructure

Accounts, keys, and project permissions are controlled by the user

A dedicated device does not automatically isolate the network, repositories, upload targets, or team accounts. Each layer requires its own permissions and monitoring signals.

Isolation Model

The host is dedicated—not the entire network path.

When evaluating isolation strength, review the device, network, accounts, and external systems separately. A dedicated physical machine does not mean every layer is inherently exclusive.

Device Layer: Dedicated per Order

Each valid order corresponds to one dedicated physical machine. Its CPU, memory, and local storage are not split with other rental orders into multiple virtual instances. The macOS graphical interface and command line are available directly for builds, debugging, and task execution.

Other rental orders cannot log in to or schedule work on this host.
Build caches, work directories, and local logs remain within the current device environment.
Before releasing the host, the user should migrate any data that needs to be retained.

Network Layer: Shared Infrastructure

Data center egress, carrier links, and Internet routing may be shared by multiple devices. A dedicated host does not mean a dedicated public network path, so connection quality and access policies must be monitored separately.

Allow only the addresses, ports, and services required by the workflow.
Continue applying separate permission controls to repositories, artifact upload targets, and dependency sources.
When an issue occurs, record host status, connection status, and target-service responses separately.

Accounts & Credentials

The first task after connecting is to tighten the access surface.

Do not use delivery-time connection details as a permanent shared team entry point. After the first login, establish access methods that are traceable, revocable, and rotatable.

Update Initial Credentials

Update system credentials after the first login, and confirm that the old credentials are no longer used in automation scripts, terminal history, or team documentation.

Prefer Keys

Use dedicated keys for command-line connections. Assign separate keys to different members and automation tasks so a single access source can be revoked independently.

Avoid Shared Accounts

When multiple people share one system account, the source of actions becomes unclear. Assign permissions by role rather than allowing everyday development access to include administrative operations.

Review Permissions Regularly

When members change, projects end, or automation tasks are retired, check whether accounts, keys, repository tokens, and upload credentials are still necessary.

Minimum Permission Review

After every member or pipeline change, check five access points.

System accountKeep the current operator
SSH public keyRemove obsolete keys
Repository permissionsRestrict to required projects
Environment variablesLimit read scope
Upload credentialsAuthorize separately per task

Remote Access Protection

Keep connection entry points within the minimum scope required by the workflow.

SSH, VNC, and macOS Screen Sharing serve different purposes. After choosing a connection method, also configure its exposure, session behavior, client version, and credential rotation schedule.

Remote Access Protection Checklist
Check	Action to take	Avoid	Verification signal
Exposure	Keep only the entry points required by the current connection method and automation tasks.	Leaving temporary troubleshooting access open indefinitely.	Unused entry points cannot establish a connection.
Session locking	Lock the interface when leaving a graphical session and actively sign out when the task ends.	Keeping an authenticated session open on a shared terminal.	Re-entry requires authentication again.
Client updates	Use supported SSH, VNC, or Screen Sharing clients.	Keeping old clients with unverifiable origins indefinitely.	The client version matches the team baseline.
Anomaly checks	Review login times, sources, active sessions, and recent configuration changes.	Assuming access is normal simply because the host is online.	Each active session maps to the actual operator.
Credential rotation	Rotate credentials immediately when a member leaves, a key may be exposed, or permissions change.	Copying the same credential across multiple projects and member devices.	Old credentials are invalid, and new credentials exist only where necessary.

Weak-network optimization should not expand the access surface

Lowering graphics quality, fixing the resolution, or reducing animation can improve remote experience without adding open entry points. Check latency, bandwidth, client settings, and concurrent sessions one by one first.

View Remote Access Methods

Data Lifecycle

Preserve a path to final migration from the first synchronization.

During the rental period, the user organizes and backs up source code, build caches, models, assets, and artifacts. Do not wait until host release to identify the data that must be taken with you.

Connect

Define data sources and destinations

Record repositories, asset sources, dependency caches, and artifact targets. Separate regenerable data from data that must be retained; do not treat the entire host as the only copy.

Run

Make backups follow the build cadence

Sync source changes, exported artifacts, and key configuration according to the project cadence. Automation tasks should specify which logs to retain after failure and which results to upload after success.

Migrate

Verify that copies are usable

Do not merely confirm that files were copied. Check that archives can be extracted, projects recognize required configuration, and artifacts are complete, and record the versions needed for recovery.

Release

Finish use only after checking each item

Before releasing the host, confirm that artifacts, source code, certificates, provisioning profiles, project configuration, and necessary caches have been handled according to team rules. Revoke external tokens and keys that are no longer needed.

Build Materials Protection

Signing, repository, and upload permissions should not rely on the same secret throughout the workflow.

Separate source-code access, build execution, signing, and artifact upload into different permission domains. Even when materials must enter the host, limit their visibility, lifetime, and appearance in logs.

Build Materials: Access Separation & Redaction Principles
Material	Recommended access	Injection method	Log handling
Signing certificate	Authorize only the tasks and operators that need to sign.	Import during a controlled step; do not scatter it across shared directories.	Do not output certificate passwords, export passwords, or complete identifying information.
Provisioning profile	Manage separately by project and target environment.	Have the build task select an explicit file; avoid ambiguous matching.	Retain the file type and match result while hiding sensitive fields.
Environment variable	Provide it only to processes that actually use it.	Inject at runtime; do not write it into source code or public configuration.	Redact command echoes, error stacks, and debug output.
Repository token	Prefer read-only access and restrict it to required repositories.	Read it from the task environment; never commit it to version control.	Remove token content from remote URLs and request headers.
Upload key	Allow writes only to the specified artifact target.	Separate it from source-reading credentials and load it by pipeline stage.	Retain the response code and task identifier; never log the complete key.

Permission separation

Each task receives only the permissions required for its current step.

A source-fetch task does not need upload access; a test task does not need signing materials; and an artifact-upload task does not need to modify the repository.

Redaction principle

Keep troubleshooting context while removing reusable secrets.

Logs may retain timestamps, steps, exit codes, file types, and error locations, but must remove passwords, private keys, tokens, complete request headers, and unredacted source snippets.

Runtime Reliability

A healthy node does not mean every connection and build task is healthy.

All nodes operate normally 365 days a year. When troubleshooting, monitor node, host, connection, and task status separately instead of letting one green status represent the entire workflow.

Node status

Is the infrastructure reachable?

Observe the node’s overall network and management capability to determine whether the issue affects foundational services on the same node.

Cannot prove on its own

That a host’s system session or a project task is already working normally.

Host online status

Has the device completed startup?

Confirm that the host is online and that the management entry point can read the device’s current status.

Cannot prove on its own

That the SSH, VNC, or Screen Sharing address, port, and credentials are all correct.

Connection status

Was the session established successfully?

Record the connection method, client, target address, port, local network, and session utilization.

Cannot prove on its own

That Xcode, dependencies, signing materials, and project configuration can complete the current build.

Task status

Did the build steps complete?

Assess task execution using step logs, exit codes, artifact verification, and upload results.

Cannot prove on its own

That the node or network experienced an infrastructure failure; use the first three signal types together.

Node Infrastructure signal

Host Device online signal

Connection Session reachability signal

Task Project execution signal

Incident Reporting Process

Establish the facts first, then submit reproducible context.

High-quality feedback helps support quickly distinguish node, host, connection, and project issues. Writing only “it doesn’t work” omits key routing information and creates unnecessary back-and-forth.

Record Before Submission

Seven items form the minimum incident package.

01 Time of occurrence

Record the time zone and the time range when the issue first appeared.

02 Node

Specify Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or the US East Coast.

03 Order identifier

Provide the order or host identifier shown in the console for verification.

04 Impact scope

State whether one task, the entire host, or multiple members are affected.

05 Reproduction steps

List inputs, actions, and the point of failure in the order they actually occurred.

06 Status comparison

State node, host, connection, and task status separately.

07 Redacted logs

Keep error context while removing passwords, private keys, tokens, and source-code secrets.

Issue with an Existing Order

Submit a ticket through the console and include the order identifier. Suitable for connection failures, host status, additional storage, renewals, and release workflows.

Submit a Console Ticket

Security & Privacy Questions

Send the incident time, impact scope, and redacted materials to support. Do not include passwords, private keys, complete payment credentials, or unredacted source code.

support@minidebug.com

Shared Responsibilities

The platform manages nodes and management capabilities; users manage access and data within their workflows.

Defining responsibilities is not about shifting blame. It ensures that when an incident occurs, the right control point, evidence, and action can be found immediately.

MiniDebug Is Responsible For

Physical Nodes & Management Access

Physical host delivery
Provide a dedicated physical machine for each order and display host and order status in the management console.
Node infrastructure
Keep the five nodes—Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East Coast—operating normally 365 days a year.
Connection information delivery
Provide connection information for the current host and the necessary management capabilities.
Infrastructure incident investigation
Use the order identifier, node, time, and redacted logs to locate issues with the physical node and management entry point.
Order lifecycle management
Handle ordering, renewals, host status, and release workflows. Actual availability is based on the console’s real-time response.

Users Are Responsible For

Accounts, Code, Credentials & Project Configuration

Account and member permissions
Protect login credentials, control team-member access, and promptly revoke accounts and keys that are no longer needed.
Code and materials authorization
Confirm that source code, models, assets, certificates, provisioning profiles, and other build materials have the appropriate usage rights.
Project environment configuration
Maintain Xcode versions, dependencies, scripts, paths, signing rules, environment variables, and upload targets.
Data backup and migration
Back up source code and artifacts during the rental period, and complete required migration and recovery verification before releasing the host.
Log redaction and incident collaboration
Submit enough reproduction context while removing passwords, private keys, tokens, payment credentials, and unredacted source code.

Quick Routing

Use the affected layer to determine the next step.

Node or host status issue

Record the order identifier, node, time, and impact scope, then submit a console ticket.

Connection cannot be established

First check online status, address, port, local network, credentials, client, and concurrent sessions.

Build command failed

Check Xcode, dependency caches, disk space, signing configuration, exit codes, and step logs.

Material or permission risk

Revoke the relevant credentials and restrict access first, then preserve redacted evidence and submit the incident details.

Next Steps

Deploy your build environment with clear boundaries.

Choose a node and rental term first, then establish separate controls for members, automation tasks, signing materials, and backups. Orders and host management are handled in the console.

Choose a Node and Order Open the Console