Physical node security model

Put the Cloud Mac security boundary into practice with every access

RunnerVPS delivers one dedicated Apple Silicon physical node for every order. Security depends not only on dedicated hardware, but also on how your team assigns SSH keys, uses VNC, injects build secrets, updates the toolchain, and completes data export before the rental term ends.

Choose a node and order View connection and troubleshooting docs
Resource boundary
One order maps to one physical machine
Local storage
Not shared with other tenants
Management principle
Minimize credentials and keep actions traceable
Secure delivery receipt NODE ACCESS / READY
Dedicated node
01
Order binding Device matched to order record
02
Credential delivery Rotate immediately after first access
03
Team onboarding Assign a separate key to each member
04
End-of-term exit Export artifacts and remove data
Compute resources
Dedicated
Remote access
SSH / VNC
Review records
Performed regularly by the user
Secret ownership
Your team's own process
Delivery is not the end of the security process VERIFY → LIMIT → ROTATE → REMOVE
Security model overview

Start by defining the dedicated physical machine boundary

RunnerVPS provides dedicated Cloud Mac physical nodes, not shared virtual machines. Compute resources and local device storage are not shared with other tenants, but your team remains responsible for managing accounts, code, keys, and software configuration.

Device-level isolation

Each order maps to one dedicated physical machine. The CPU, memory, and built-in SSD are not shared with other tenants, allowing your team to maintain an asset inventory, access list, and handoff record tied to a clear device identity.

Order ↔ device Dedicated physical resources

Clear access responsibility

You decide who can sign in, which accounts they use, and when keys are revoked. Do not let multiple people share one private key or password long-term, and never put connection credentials in project documentation or automation logs.

Authorize by person Revoke promptly

Keep the data lifecycle under control

Decide before work begins when code, build caches, signing materials, and artifacts enter the device, how long they are stored, and how they are backed up and removed. The end of the rental term is not a substitute for a backup.

Plan before use Clean up before completion
Access control

Give every sign-in a distinct identity

Before onboarding the team, define accounts, keys, permissions, and review frequency. Do not start by sharing one administrator credential and then rely on chat history to determine who did what.

01

One member, one SSH key

Register a separate public key for every member who needs command-line access. Private keys should remain on a member's managed device or an approved team key manager; never send them by email, support ticket, or code repository.

Individually revocable
02

Use least-privilege accounts by default

Routine code pulls, test runs, and artifact transfers do not require continuous use of the highest privileges. Elevate temporarily only for defined actions such as installing software or changing system settings.

Reduce accidental changes
03

Manage passwords and keys separately

Use a unique strong password for the graphical account and prefer key-based SSH authentication. Do not reuse the device password for code hosting, email, or other systems.

Reduce reuse risk
04

Review remote login records regularly

Check login times, sources, accounts, and failed attempts. If a record does not match the team's working hours or member networks, revoke the relevant credentials first, preserve the necessary logs, and submit a security report.

Preserve investigation leads
VNC security

The graphical interface also needs a controlled connection path

VNC is useful for remotely operating the macOS graphical interface, but keeping it permanently open or sharing credentials is not a secure convenience. Prefer connecting through a controlled network or an SSH tunnel.

A

Before connecting

  • Confirm that the target is the device and node listed in the order.
  • Verify the SSH host fingerprint before setting up port forwarding.
  • Limit which local devices and team members can initiate connections.
B

During the session

  • Lock the macOS session when leaving the screen; do not leave an interactive desktop exposed.
  • Do not show passwords, tokens, or private keys in shared screens, recordings, or logs.
  • Confirm the destination directory and access permissions before transferring sensitive files.
C

After a member leaves

  • Immediately revoke the member's SSH public key and system-account access.
  • Rotate any shared graphical-interface password and project tokens.
  • Review recent remote login records and update the access list.
Do not share long-lived credentials

When several people need to collaborate, give each member access that can be revoked separately. Shared credentials make offboarding, activity tracing, and incident investigation difficult.

Build secret management

Inject secrets at job runtime, not into the code flow

Certificates, signing files, access tokens, and environment variables should come from your team's own secret-management process. RunnerVPS provides the device and basic connectivity; it does not replace project credential governance.

Build job injection checklist RUN SCOPE: ONE JOB
Signing certificate Import when the job starts Remove when the job completes
Signing file Restrict file permissions Never commit to a repository
Access token Scope to the project Set a separate rotation policy
Environment variable Injected by the runner Never print to logs
Build artifact Send to controlled storage Clean up copies after verification

Keep secrets out of code repositories

Never commit private keys, certificate passwords, signing files, tokens, or configuration files containing secrets to any branch. Even after deletion, the content may remain in the repository history.

Keep secrets out of build logs

Disable sensitive-value echoing in commands, and redact logs, screenshots, and failure reports. Preserve error context during troubleshooting without copying complete credentials.

Limit the effective scope by job

Grant tokens only the permissions required for the current repository, pipeline, and actions. Rotate them immediately when the job ends, a member leaves, or exposure is suspected.

System and software updates

Validate the toolchain before updating macOS and Xcode

System updates can change SDKs, command-line tools, simulators, and signing behavior. For continuous build nodes, verify compatibility before changing the production environment.

  1. 01

    Record the current baseline

    Save the macOS, Xcode, command-line tools, package manager, key dependencies, and runner versions. Record the smallest passing test job and artifact-validation method for the project.

  2. 02

    Verify project compatibility

    First check project requirements, SDK support, locked dependencies, and signing configuration. For critical projects, use repeatable test jobs to verify compilation, unit tests, signing, and artifact export.

  3. 03

    Prepare a recovery path

    Back up the data, configuration inventory, and build artifacts required by the project before making changes. Confirm dependencies can be reinstalled and secrets can be injected again through your team's own process.

  4. 04

    Choose a low-risk time

    Avoid active release jobs and pause new builds from entering the node. After updating, recheck remote access, the firewall, runner status, and disk space.

  5. 05

    Validate with a minimal job

    Run a controlled validation job first, then resume the full pipeline. If the result differs from the baseline, preserve logs, version details, and reproduction steps before continuing.

Data export process

Take what you need with you before the rental term ends

Before the rental term ends, export artifacts, remove accounts, revoke keys, and clean project files. Do not treat local device storage as your only backup, and do not wait until access is no longer available to clean up.

View support guidance Open console
01 Export

Collect build artifacts, project data, logs, and configuration inventories that must be retained.

02 Verify

In controlled team storage, confirm files open correctly, checksums match, and permissions are correct.

03 Revoke

Remove member accounts, SSH public keys, project tokens, certificates, and signing materials.

04 Clean up

Delete project directories, caches, temporary files, downloads, and local artifact copies.

05 Confirm

Check the rental-term status in the console and save the necessary order-linked handoff records.

Responsibility boundary

The user is responsible for exporting and verifying all required data before the rental term ends. After the term ends, do not assume the device remains available for backups, project-file recovery, or retrieval of unexported build artifacts.

Security incident reporting

Provide enough information to start the investigation with facts

If you discover an unusual login, suspected credential exposure, incorrect access scope, or another security issue, first revoke necessary credentials and restrict access, then select the security-report category on the contact page.

01 Impact scope

Describe the devices, nodes, accounts, projects, and potentially affected data types involved. Do not submit passwords, private keys, or complete payment credentials.

02 Incident timeline

List when the issue was first discovered, how long the anomaly may have lasted, the revocation or isolation actions already taken, and the most recent time normal operation was confirmed.

03 Reproduction steps

Describe the entry point, actions, expected result, and actual result in the order they occurred. If the issue cannot be reproduced consistently, state its frequency and trigger conditions.

04 Redacted evidence

Provide necessary log excerpts, error messages, request times, and screenshots. Cover tokens, keys, passwords, certificate contents, and unrelated personal information.

Start with a physical node with a clearly defined boundary

Choose Runner M4 or Runner M4 Plus, a rental term, and a node, then onboard it after delivery using your team's own key and secret-management processes.

Choose a node and order View plans and pricing