Dedicated Node Security Model

Define the physical boundary first, then control every access

Every MangoVM rental corresponds to one dedicated Apple Silicon physical node, not a virtual machine. Security is more than a claim of isolation: customer permissions, platform operations, and data center facilities each have clear, verifiable responsibilities.

Rent a Dedicated Mac Now View Connection & Troubleshooting Guide

Rental Boundary One order = one physical node

Customer Access Layer

Customers manage accounts, keys, software, tasks, and business data.

Platform Operations Layer

Node provisioning, status management, and necessary support follow authorization and least-privilege principles.

Facility Protection Layer

The data center provides power, networking, and physical facilities. Nodes are available in Singapore, Tokyo, Seoul, and Hong Kong.

Physical Resources Compute nodes are not shared with other tenants

Responsibility Boundaries

Dedicated hardware provides resource isolation; correct configuration manages access risk

Physical isolation prevents multiple tenants from using the same compute node, but it does not replace key management, account permissions, software updates, or business data backups. Security controls must be handled separately by the customer, MangoVM, and the data center facilities.

Customers Control Access and Workloads

Customers decide who can log in to a node, which keys to use, which service ports to expose, and which code, certificates, logs, and data enter the machine. Customers are also responsible for software configuration and task activity during the rental period.

Assign separate accounts and keys to people and automated tasks
Limit administrator privileges so routine builds do not continuously use privileged accounts
Keep independent copies of business data, build artifacts, and critical configuration

MangoVM Manages Provisioning and Platform Controls

The platform provisions physical nodes according to the order, displays node status, manages the service lifecycle, and handles support requests only when authorized and necessary.

Verify the model, memory, storage, and node region before delivery
Operational actions follow authorization, auditing, and least-privilege access
Unusual actions enter a review process; convenience does not replace control

Data Center Infrastructure

Data center facilities provide power, network access, environmental controls, and physical space. The city where a node is located indicates the service access location and does not constitute a promise of permanent customer data storage there.

Keep the facility layer separate from customer business accounts
Nodes operate normally 365 days a year
The console's real-time status determines actual availability for ordering

Access & Credentials

Manage human logins, automated tasks, and recovery access separately

A shared key reused over the long term is difficult to audit and difficult to revoke precisely when people change roles. Create separate credentials by user and purpose, and manage interactive logins, CI Runner access, deployment tasks, and emergency recovery separately.

Human Access

One person, one account; one device, one key

Do not let multiple people share the same login identity. Create a separate account for each authorized person and generate different keys for different devices. When a member leaves the project, revoke the corresponding account and keys instead of replacing everything and continuing to share access.

Automated Tasks

Give the Runner only the permissions it needs

CI/CD accounts should be restricted by executable scope, concurrent tasks, and readable directories. Build scripts that do not require system administration privileges should not receive them; temporary credentials should be removed after the task ends.

Rotation & Revocation

Rotation must include verification and rollback

Add the new key and complete a connection test before revoking the old key. If a device is lost, a member changes, or credentials are used suspiciously, revoke the relevant access immediately and review recent login and task logs.

Console-Side Checks

Before retrieving or changing node access details, confirm the order ID, node region, and current status. Do not identify the access target solely from chat screenshots or forwarded text.

Open the Console to Verify the Node

Keep Sensitive Information Out of Public Channels

Do not place passwords, private keys, signing materials, or complete access credentials on public pages, in public repositories, or in ordinary discussion channels. When support is needed, submit a summary first; the support team will confirm the secure process for any follow-up.

Learn How to Submit a Security Report

Node Lifecycle

Set checkpoints for provisioning, rental, and recycling

A node does not leave the control process once delivery is complete. Verify delivery conditions before the rental begins, define ownership of permissions during the rental, and complete migration and credential revocation before it ends to close the lifecycle loop.

01

Pre-Delivery Verification

The platform verifies the model, memory, storage options, and node region against the order and completes basic status checks. After receiving the delivery status update, customers should verify the node identifier first and then use the connection details provided in the console.

Output: Verifiable Node Record
02

Permission Ownership During the Rental

Customers manage operating system accounts, project dependencies, business data, and task permissions. The platform does not allocate the physical node's compute resources to other tenants; support intervention requires a clear request and a necessary scope.

Boundary: Customer Workloads Run Independently
03

Migration Before the Rental Ends

Before the rental ends, move out source code, build artifacts, logs, project caches, and any other data to retain; revoke external systems' trust in the node; and remove the relevant Runner and deployment targets from your pipelines.

Customer Actions: Migrate, Verify, Revoke
04

Post-Recycling Processing

After the node is recycled, data processing and preparation for redeployment follow the applicable service terms. Customers should not treat recycling as their only backup mechanism or continue relying on any copy left on the node after the rental ends.

Basis: Applicable Service Terms

Encrypted Transmission

Verify the target before connecting, then reduce exposure after connecting

The risk of remote connections is usually not simply whether encryption is present. It is whether the correct host was verified, sources were restricted, and unnecessary services were kept from being exposed. Recheck these details on every first connection or node information change.

View SSH Connection Steps

Verify Host Identity

On the first connection, cross-check the address and node identifier against the console record and verify the host fingerprint. If the fingerprint changes unexpectedly, stop the connection; do not bypass the warning.

Enable Encrypted Protocols

Use encrypted connections such as SSH for command-line access. When transferring build artifacts and logs, use an authenticated encrypted channel as well, avoiding plaintext credentials or project content.

Restrict Public Services

Open only the ports required for actual tasks and restrict the allowed source ranges. Close temporary debugging services immediately after use, and do not bind development services to all network interfaces by default.

Retain Connection Records

Record key access times, sources, operators, and changes. Logs should allow correlation with the order ID and node region, but must not contain private keys, passwords, or complete signing materials.

Platform Operations Controls

Support intervention must have a reason, a scope, and a record

MangoVM limits operational access to what is necessary for provisioning, troubleshooting, security response, and explicit customer requests. We explain our control principles publicly without disclosing internal implementation details that could help bypass controls.

Authorization

Confirm the Request and Target First

Before intervening on a node, confirm the associated order, node scope, purpose, and permitted time window. If the target or authorization source cannot be confirmed, verbal convenience does not replace the necessary verification.

Minimization

Access Only What Is Needed to Resolve the Issue

Diagnosing network status does not mean reading project files, and verifying delivery status does not mean entering a business account. The operational scope should match the issue, and temporary access must end when the task is complete.

Auditing

Keep Correlated Records of Critical Actions

Operational records should link the request, node, operation type, and result for later review. Records follow the principle of minimum necessity and must not copy customer-sensitive materials into ordinary ticket descriptions.

Review

Unusual Actions Enter a Review Process

Pause and review actions that expand scope, fail repeatedly, come from an unusual source, or do not match the request. During a security incident, control the impact first, then restore service and investigate the cause using the records.

Service Availability Target

99.9%Availability Target

All nodes operate normally 365 days a year. The applicable scope, calculation method, exclusions, claim materials, and compensation terms for availability are governed by the corresponding rules in the applicable service terms.

90 days Daily Status Observation Window

Four Node Locations Singapore, Tokyo, Seoul, Hong Kong

Daily Status Bar for the Past 90 Days Each cell represents one calendar day

Normal

The status bar illustrates how the service target is observed; it does not replace specific order and node records. To request service compensation, provide the order ID, affected node, time range, symptoms, and troubleshooting steps already performed.

Review Eligibility and Compensation Terms

Security Incident Response

Control the impact first, restore service next, then document the cause

Security incidents proceed through five stages: detection, confirmation, containment, recovery, and review. Each stage has a defined output, preventing conclusions from expanding before facts are confirmed and ensuring root causes are tracked after recovery.

01

Detection

Receive customer reports, platform alerts, or operational anomaly records, then preserve the time range, node identifier, source, and reproducible symptoms.
02

Confirmation

Verify whether the incident occurred, which nodes and functions are affected, and whether the issue involves networking, authentication, system services, task processes, or security controls.
03

Containment

Within the necessary scope, restrict abnormal access, pause relevant tasks, or revoke suspicious credentials, prioritizing prevention of further impact.
04

Recovery

After removing the confirmed cause, restore necessary services, check connections, tasks, logs, and data integrity, and monitor for recurrence.
05

Review

Document the impact, response actions, recovery results, and follow-up improvements so similar issues can be identified faster and handled within a narrower scope.

Before Submitting a Report

Provide Information That Can Go Straight Into Investigation

Do not send passwords, private keys, or signing materials. Start with the minimum necessary information; the support team will confirm a secure submission method if more material is needed.

Order & Node: Order ID, node region, and affected node identifier
Time Range: Time first detected, most recent reproduction time, and time zone used
Impact Description: Operations that could not be completed and the affected accounts or task scope
Troubleshooting Performed: Results of checks on networking, authentication, system services, and task processes

Customer Security Checklist

Build security actions into launch, daily operations, and offboarding

One-time hardening quickly becomes outdated. Add the checks below to your team's runbook and record the owner, trigger conditions, and verification results.

Open the Operations & Troubleshooting Guide

System Updates

Before updating, verify compatibility among Xcode, SDKs, build scripts, and critical dependencies. Back up necessary data, run the update and smoke tests, and prepare an executable rollback plan.

Key Management

Separate keys by person, device, and automation purpose; define rotation and revocation procedures; and address relevant credentials immediately after personnel changes, device loss, or unusual access.

Protect Signing Materials

Restrict signing materials to the accounts and tasks that genuinely need them. Do not place them in code repositories or ordinary build logs. Remove temporary copies after tasks finish and review the access scope.

Log Retention

Retain critical login, permission-change, build, and deployment records, use a consistent time zone, and ensure they can be correlated with nodes and tasks. Logs must not contain passwords, private keys, or complete sensitive materials.

Independent Backups

Keep copies of source code, build artifacts, configuration, and critical logs outside the node. Regularly verify that backups can be read and restored instead of only confirming that the backup job completed.

Offboarding Migration

Move out data that must be retained in advance, verify the destination copy, revoke node keys, Runner registrations, Webhooks, and deployment permissions, then confirm the rental end status.

You need dedicated compute resources—and clear security boundaries

Choose a configuration from MangoVM M4 or MangoVM M4 Pro. Manage orders, node status, and access details in one console; all prices are charged in USD.

Start Renting a Cloud Mac View Both Plans