Security boundaries you can verify

Dedicated-node security controls, from physical boundaries to incident response

Each order includes one dedicated physical Mac mini, not a virtual machine. HexVM manages node delivery, core networking, and platform-side operations; customers manage accounts, build keys, code-repository access, and data on the node.

Rent a dedicated Mac now Contact the security team

Security reports are accepted only through console tickets or support@hexvm.com. Do not send real private keys, complete access tokens, or unredacted credentials.

HexVM dedicated Mac mini node and security-status control panel

Node boundary check Normal

Resource ownership: Dedicated per order
Compute type: Physical node
Management access: Credentials and tickets controlled

Node isolation 1 per order

Service coverage 365 days

Service target 99.9%

Reporting channels 2

Responsibility split

Clarify who controls what

A dedicated physical machine reduces shared compute resources, but security still depends on both the platform and the customer. The sections below explain responsibilities for resources, permissions, platform operations, and customer actions.

Physical resource boundaries

Each order maps to one independent Mac mini. Its CPU, memory, and local storage are not divided among other customer instances. The two available configurations are the base M4 configuration (16GB, 256GB) and the M4 Pro configuration (64GB, 2TB).

Each node is dedicated to a single order, with no metering by virtual CPU or shared memory.
The node region and model are selected at checkout; availability is based on the console’s real-time response.
Complete data migration, key revocation, and local backups before the rental term ends.

Customer-managed access

Customers control the development environment, member permissions, SSH keys, repository credentials, build caches, and automation tasks on the node. The order owner should record and review permission changes.

After the first connection, update temporary credentials and switch to key-based authentication as the priority.
Set separate permission boundaries for CI runners, manual operations, and release tasks.
Do not let multiple people share the same administrator credentials over the long term.

Platform operations boundaries

HexVM handles order delivery, node health checks, core network connectivity, service-status tracking, and ticket handling. Before any node operation, order ownership and request scope must be verified.

Customers will never be asked to send real private keys or complete tokens by email.
Node-operation requests should include the node ID, region, time of occurrence, and impact scope.
Platform-side actions aim to restore a secure state and confirm service impact.

Shared responsibility baseline

HexVM provides dedicated physical nodes and platform-side operational controls; customers manage accounts, code, certificates, keys, third-party repository permissions, and backup policies on the node. When an anomaly is found, both parties should share a redacted timeline and reproducible evidence.

Access control

Turn long-term risk into five standard actions

Access security cannot rely on a one-time setup. Teams should build credential updates, least privilege, member offboarding, and environment isolation into onboarding, release, and offboarding workflows.

Update temporary credentials immediately

After receiving node connection details, verify the node ID, region, and host fingerprint before changing the temporary password. Never copy initial credentials into team chats, public documents, or pipeline logs.

Prefer SSH keys

Assign a separate key to each member or automation task, and record its fingerprint and purpose. When a member’s device or role changes, or a key may be compromised, immediately remove the corresponding public key and issue a replacement.

Scope permissions to each task

Build tasks should receive only the permissions needed to read code, write to build directories, and upload artifacts. Limit tool installation, system configuration, and member-management privileges to a small group of owners.

Revoke access immediately when someone leaves

Revoke personal public keys, repository deploy keys, CI runner registration tokens, and shared-directory permissions, then review recent login records. Do not disable only one collaboration tool while leaving the node access path open.

Separate development, testing, and release

Use different accounts, key sets, and repository permissions for each environment. Keep release credentials out of everyday development scripts, and do not let test tasks read write credentials for production artifact storage.

Data protection

Define the path out before data enters the node

Code, build artifacts, and signing materials have different sensitivity levels. Define the transfer method, storage location, authorized users, and deletion point for each.

Transfer

Use protected SSH or VNC connections to transfer data, and verify the host fingerprint on the first connection. Check the integrity of large transfers and avoid exchanging build materials through public links.

Handle

Store code, caches, artifacts, and sensitive materials in clearly designated directories. Temporary scripts must not write keys to shell history, terminal output, or test reports.

Store

Authorize build keys and certificates only for tasks that perform signing or releases. Restrict export permissions and record who is responsible for import, rotation, and revocation.

Remove

Before the node rental term ends, export required artifacts and audit records, revoke repository and CI credentials, and delete working directories, caches, temporary files, and local key copies.

Recommended controls for common data types
Data type	Recommended storage location	Permission boundary	Action before removal
Source code and dependencies	Controlled working and build-cache directories	Development members and designated runners	Confirm commit status and delete untracked sensitive files
Build keys and access tokens	Restricted credential storage or runtime injection	Only the relevant pipeline tasks and owners	Revoke, rotate, and remove local copies
Certificates and provisioning profiles	Access-controlled signing environment	Signing tasks and release owners	Export required backups and remove node copies
Build artifacts	Artifact directory or team-approved storage	Testing, release, and audit roles	Verify checksums and remove temporary versions after migration
Logs and diagnostic packages	Log directory with a defined retention period	Operations, security, and task owners	Redact and archive; delete originals containing credentials

Networking and logs

Give every anomaly a timeline, scope, and evidence

Connection records and build logs should support investigation, not be kept indefinitely. Standardize timestamps, fields, and retention rules so node events can be cross-checked with repository, CI, and artifact systems.

Connection auditing and anomaly detection

Record connection time, source range, access method, account, and result. Pay particular attention to repeated failures in a short period, logins at unexpected times, unfamiliar public keys, sudden privilege increases, and repeatedly offline runners.

Use consistent fields for successful and failed login events.
Use separate accounts for administrator actions and automation tasks.
When the source appears anomalous, restrict access first and preserve evidence.

Time synchronization and log format

Nodes, repository platforms, CI schedulers, and artifact systems should use a consistent time zone or clearly record the time-zone offset. Ticket timestamps should be accurate to at least the minute and identify the first discovery and last reproduction times.

Retain the node ID, task ID, commit identifier, and exit code.
Remove passwords, tokens, private keys, and personal information before sending logs.
Store raw logs separately from human analysis findings.

Recommended log retention

Set retention periods based on code sensitivity, release frequency, and internal audit cycles. Keep only the fields needed for troubleshooting in build output; shorten retention and restrict downloads for diagnostic packages containing sensitive content.

Set separate retention rules for development, testing, and release environments.
Regularly verify that logs can be linked to a specific task owner.
When deleting expired logs, also remove exported diagnostic copies.

Customer-side monitoring integration

You can connect existing team monitoring for processes, disk space, build queues, and runner health within the node. Alerts should include the node ID, region, threshold, duration, and recovery status—not just an untraceable screenshot.

Monitor available disk space, critical processes, and queue wait times.
Alert separately for service failures and individual build failures.
After an alert recovers, retain the same event ID for review.

Operational stability

99.9% service target and the last 90 days at a glance

All nodes operate normally 365 days a year. The status view shows daily service availability; if an impact occurs, an event marker links its scope, duration, and handling record.

Service target 99.9%

Review platform-side service impact under the applicable service terms. Issues caused by customer configuration, credential actions, third-party systems, or force majeure are excluded from platform availability.

Observation window: 90 days
Status granularity: Daily
Current event marker: None

Daily service status

Normal Service event

90 days ago 60 days ago 30 days ago Today

Service credit request summary

If you believe platform-side service impact meets the scope defined in the terms, submit a console ticket with the node ID, region, start and end times, connection or task results, and redacted logs. HexVM will verify the event timeline, order ownership, and applicable conditions, then process service credits for eligible orders.

Submit a console ticket

Incident response

A six-step path from discovery to review

Incident handling prioritizes access-boundary protection and evidence integrity. Accurate node details and redacted logs from the customer reduce repeated verification and speed investigation.

01

Discover

Confirm the symptoms, first discovery time, affected nodes, and business scope. Preserve original errors, login records, and task identifiers; avoid repeating actions that could overwrite evidence.
Customer support: Provide the node ID, region, timeline, and source of discovery.
02

Isolate

Narrow connection entry points according to risk, remove suspicious public keys, pause related automation tasks, and protect unaffected build and release pipelines.
Customer support: Confirm which accounts, repositories, and tasks may be paused.
03

Investigate

Correlate node logins, permission changes, build tasks, repository actions, and artifact records to determine the entry point, duration, affected parties, and data scope.
Customer support: Provide redacted logs, reproduction steps, and recent change records.
04

Remediate

Revoke affected credentials, correct permissions and configuration, remove anomalous tasks, and verify that connection, build, signing, and artifact-upload paths are operating normally again.
Customer support: Complete any necessary rotation of repository tokens, keys, and certificates.
05

Notify

Use a verified order contact path to share the impact scope, current status, completed actions, and next update point. Avoid exchanging sensitive information through unverified channels.
Customer support: Appoint an owner who can confirm technical and business impact.
06

Review

Document root causes, detection gaps, recovery steps, and follow-up owners. Add long-term improvements to access reviews, monitoring, and release checks.
Customer support: Verify that the improvements are actually implemented in team workflows.

Security reporting

Report vulnerabilities, suspicious logins, or credential risks

Security issues are accepted only through console tickets or support@hexvm.com. For existing orders and node anomalies, use a ticket first so ownership can be verified and the case tracked continuously.

Console security ticket

For anomalous connections, node-permission changes, service impacts, and incidents requiring platform-side investigation on existing orders. Include the node ID, region, time of occurrence, impact scope, and redacted evidence.

Security report email

For vulnerability leads, reproducible security issues, or credential-risk questions not yet linked to an order. The subject should summarize the issue type and affected component; redact all attachments first.

Send to support@hexvm.com

A report we can act on should include

Issue type, discovery time, and whether it is still reproducible.
Affected node ID, region, page, or feature path.
Minimal reproduction steps, expected result, and actual result.
Redacted requests, error messages, log excerpts, or screenshots.
Isolation actions already taken and any changes that may affect the investigation.

Do not include with your report

Real private keys, complete access tokens, full passwords, unredacted certificate files, or credentials that directly access repositories or artifacts. If sensitive fields must be verified, describe the field type in the ticket first; the support team will provide a safe handling path.

Dedicated Apple Silicon

Deploy your Cloud Mac with clear boundaries

Compare the configurations and rental terms of two dedicated physical nodes and choose the right fit for Xcode builds, CI/CD, or continuous development. All charges are settled in USD.

Rent a dedicated Mac now View rental plans