Physical Nodes & Access Boundaries

Security starts with a dedicated physical machine—not vague promises

Every valid order is assigned one dedicated Apple Silicon physical node. VMOak separates platform management, delivery, and customer workloads, using credential issuance, operations approvals, and activity records to constrain administrative actions.

Security is not a one-sided feature. We handle node delivery, platform accounts, and essential operations controls; customers handle repository permissions, deployment tokens, work files, remote endpoints, and team access.

Rent a Cloud Mac View Secure Connection Guide

Node ownership: 1 valid order = 1 dedicated physical machine
Access method: Customer updates temporary credentials after delivery
Support boundary: We never request complete private keys or repository tokens

Order and node binding Confirm the model, node, and ordering party; physical computing resources are not shared with other orders.

Complete

Pre-delivery checks Verify system startup, network connectivity, storage capacity, and access account status.

Complete

Temporary credential issuance Delivered through a controlled path, with an immediate update required after the first connection.

Issued

Restricted operations access Access is granted only within the necessary scope for authorized troubleshooting, with the reason and outcome recorded.

Restricted

Trust model

Platform and customer controls have clearly defined boundaries

VMOak’s foundation is physical node ownership, not logical quotas carved from a shared host. While an order is active, the Mac assigned to it is dedicated to that customer; the management layer handles orders, delivery, and essential operations, while customer workloads run on the assigned node.

Physical node isolation

Each order maps to a dedicated physical machine. Its processor, memory, and local storage are not shared with other customers. Remote desktop sessions, SSH tasks, and build processes all run on the same assigned device.

Node identity linked to order records
Verify the model and storage capacity before delivery
Disable existing access paths when the order ends

Management and workloads kept separate

The console handles order status, credential delivery, and support requests; it is not a working directory for customer code, build artifacts, or project files. Customer tasks run on the assigned physical node.

Support requests collect only information needed for troubleshooting
Administrative actions are performed within the necessary scope
Temporary permissions are withdrawn when troubleshooting ends

Customer responsibilities

Customers decide who can connect to the node, which repository tokens are usable, and which data enters the remote Mac. Team permission changes, key revocation, and business-data backups should be part of internal procedures.

Limit repository token scope and lifetime
Remove access immediately after departure or role changes
Encrypt sensitive files and keep an independent backup

Delivery checks

Complete five device checks before access details are issued

Delivery checks confirm that the physical node assigned to an order is ready for use. They cover the device, system, network, storage, and access account—not unverified benchmarks.

01

Device status

Verify physical node identifiers, the ordered model, and basic hardware status so the delivery record matches the device actually assigned.

Issue after passing
02

System startup

Confirm that macOS starts normally, the graphical interface and command line are accessible, and system time and core services meet delivery requirements.

Startup confirmed
03

Network connectivity

Confirm the node has required inbound connection paths and outbound access, and verify services needed for remote desktop and SSH.

Connectivity confirmed
04

Storage capacity

Verify included storage and selected add-ons, including visible capacity and filesystem status, so configuration records match the node’s actual capacity.

Capacity verified
05

Access account

Confirm the temporary account can be used for the first connection, record its issuance scope, and make the first credential update the first security action after delivery.

Awaiting customer update

Credential security

Temporary credentials are for first access only; customers take over long-term access

Access details should be treated as a one-time issuance record, not a permanent password to forward indefinitely. Update credentials immediately after the first connection, then separate access by person and automation task to reduce the untraceable risk of shared passwords.

Credential lifecycle From issuance to revocation

Issue

Enter with a temporary account

The access address, username, and temporary credentials are provided in the delivery record. Do not forward them to public groups, code repositories, or build logs.

Update

Change after first connection

Use credentials of sufficient length that are not reused with other services. When a team shares access, do not permanently share the same interactive login details.

Separate

Authorize people and automation separately

Interactive remote desktop, SSH administration, and CI/CD Runner access should use separate permission paths. Automation tokens should expose only the repositories and operations required for the task.

Revoke

Clean up immediately after membership changes

When someone leaves, changes roles, or loses a device, revoke the corresponding public keys, tokens, and account permissions, then review recent login records.

SSH keys

Upload public keys only—never submit complete private keys

Private keys should remain on a customer-controlled endpoint or in a controlled key system. Use identifiable, separate keys for each person and automation task so revocation can be precise.

Name public keys by user or task
Restrict local read access to private-key files
Delete the corresponding public key when no longer used

Permission review example

identity: build-runner
scope: repository-read
interactive-login: false
expires: project-policy
owner: mobile-ci-team

This example illustrates least privilege; it does not mean the platform creates repository access policies for the customer.

Operations access

When people must intervene, access needs a reason, scope, and end point

A support request does not automatically grant access to customer workloads. Manual troubleshooting begins only with explicit customer authorization and when a remote issue cannot be resolved through status information, redacted logs, or customer-side actions.

Confirm the issue and authorization

Record the order number, node, issue time, impact scope, and checks already performed by the customer. If node access is needed, explain its purpose first.

Limit access to what is necessary

Access covers only the system status, service configuration, or log scope required for the current issue; unrelated code and business files are not reviewed under the guise of troubleshooting.

Record the work performed

Keep records of key actions, observations, and configuration changes so later review can distinguish customer actions, system state, and support actions.

End access and withdraw permissions

When troubleshooting is complete, close temporary access paths and tell the customer the outcome, changes made, and signals worth monitoring.

Common support scenarios and permitted information
Scenario	Provide first	Possible operations action	Do not submit
Remote connection failure	Time of occurrence, client network, error message, node identifier	Check service status, port paths, and account status	Complete private keys, unredacted repository tokens
Build process interrupted	Command, exit code, redacted logs, resource-usage symptoms	Check system processes, disk space, and core services	Complete project source code, production keys
Unexpected storage capacity	Directory usage summary, order configuration, expected capacity	Check the filesystem, mount status, and order add-ons	Business-file contents, unencrypted data copies

Network & remote sessions

Connection security depends on transport, ports, endpoints, and session closeout

Network controls for a remote Mac are not just about whether it connects. Endpoint capabilities, exposed ports, client-device status, and how a session ends together determine practical risk. Customers should prefer encrypted connections and restrict unnecessary network entry points.

Remote desktop sessions

Confirm that the client supports the required encryption, and avoid storing long-lived credentials on untrusted endpoints. When work is done, actively sign out and close client windows you no longer use.

Before connecting: Verify the address, account, and client source; ensure the local device is updated and screen locking is enabled.
While connected: Avoid transferring long-term keys through the clipboard, and do not display sensitive configuration during screen sharing.
After connecting: Exit the graphical session, remove temporary downloads, and confirm that sensitive applications are no longer left in the foreground.

SSH and automation connections

Use separate public keys and least-privilege tokens for automation. Services that do not need to be public should not have extra ports opened; temporary debugging entry points should be closed when the task ends.

Port control: Keep only entry points the task actually needs; do not leave unrelated services open for convenience.
Key separation: Separate user keys from Runner keys, and repository read access from release access.
Anomaly investigation: After detecting an unfamiliar login, revoke the relevant keys first, then preserve the timeline, source address, and process information.

Billing data boundaries

Payment status enters the order; complete card details do not enter VMOak pages

Payment processing retains only the information needed to complete orders, verify status, and resolve billing issues. The two payment methods use different verification paths, but both settle in USD; the gateway available at checkout controls the actual flow.

Card billing

Visa / Mastercard / Amex

Card payments are processed by Stripe. VMOak pages avoid storing complete card numbers, security codes, or other complete card details; the order system receives only the status information needed to complete payment and handle billing.

Settled in USD
Order records contain payment status and necessary transaction references
Billing issues are handled through console tickets or the support email

On-chain billing

USDT-TRC20

USDT-TRC20 orders are verified against on-chain transaction records. For billing questions, customers may provide the order number, transaction ID, and payment time, but should never include wallet private keys or other control credentials.

Priced in USD
Verified against the order and on-chain transaction ID
Private keys and recovery phrases remain under the customer’s control

VMOak needs Order number, payment status, necessary transaction references VMOak does not need Complete card details, wallet private keys, unrelated account credentials

Security incident response

Confirm facts first, contain impact, then recover and review

Security incident handling does not replace evidence with guesswork. Once a report is received, VMOak first confirms the order, node, account, and time range involved, then narrows access paths according to risk, preserves necessary information, and advances the investigation.

01

Confirm

Verify the reporter, order number, node, first discovery time, symptoms, and ongoing impact; distinguish connection issues, account issues, and potential security incidents.

Build the timeline
02

Contain

Narrow suspicious sessions, credentials, or network entry points according to the impact. Containment aims to stop further spread while preserving evidence needed for follow-up investigation.

Limit the impact
03

Investigate

Review relevant login records, process information, configuration changes, support actions, and redacted evidence supplied by the customer to determine the entry point, affected objects, and duration.

Verify the evidence
04

Recover

After closing the risk entry point, restore necessary access, update affected credentials or configuration, and specify the repository-token revocation, key rotation, and file checks the customer must perform.

Restore availability
05

Notify and review

Explain confirmed facts, actions taken, remaining risks, and recommended steps to affected customers. Unconfirmed points are clearly labeled; speculation is not presented as a conclusion.

Create the incident record

Submit an incident report

Provide the minimum evidence set needed to rebuild the timeline

Prioritize the order number, node, first discovery time, last known normal time, source address, error messages, relevant accounts, containment actions already taken, and redacted logs. Do not submit complete private keys, repository master tokens, or unredacted business data.

Customer security checklist

Complete these actions before connecting the node to your team

This checklist applies to remote development, CI/CD, self-hosted Runners, AI experiments, and creative workflows. The larger the team, the more important it is to assign a traceable owner and cadence to every item.

Update first-use credentials

Change temporary credentials immediately after the first connection. Do not reuse the same password for personal email, code hosting, or another server.

Owner: Node administrator

Restrict repository tokens

Grant only the permissions required for the current project and task. Separate read, build, release, and administrative access, and set an internal rotation schedule.

Owner: Repository administrator

Separate user and Runner keys

Do not let automation reuse user login keys. Give each Runner a separate identity for easier deactivation, investigation, and rotation.

Owner: CI/CD administrator

Review access regularly

Review local accounts, SSH public keys, repository tokens, and automation configuration; remove entry points for completed projects or unused services.

Owner: Team access manager

Encrypt sensitive files

Before moving files to the node, decide whether upload is truly necessary. Use customer-controlled encryption for sensitive data and keep an independent backup.

Owner: Data owner

Remove member access promptly

When a member leaves, changes roles, or finishes contract work, revoke remote accounts, public keys, tokens, and shared-directory permissions together.

Owner: Team manager

Every personnel change Review accounts, public keys, and repository tokens

Every project end Clear caches, build artifacts, and temporary credentials

Every incident Preserve evidence first, then revoke entry points and submit a ticket

Start with clear boundaries

Choose a Cloud Mac dedicated to a single order

Confirm the M4 or M4 Pro configuration, six available nodes, and billing cycle, then complete the order in the console. Actual node availability is determined by the console in real time.

Rent a Cloud Mac now View Configurations & Pricing