Security model and responsibilities

Security starts with a dedicated physical Mac—and clear operating boundaries

BookaMac assigns one dedicated physical Mac mini to each order, rather than dividing a shared host into virtual machines. Physical isolation reduces the scope of computing resources shared with other tenants, but credentials, code, certificates, dependencies, and remote sessions still need to be managed by the user according to sound engineering practices.

This page explains what we are responsible for, what you need to control, and how both sides can provide verifiable information when something goes wrong.

Rent a dedicated Mac mini Connection & troubleshooting docs
1 order maps to 1 dedicated physical machine
Not virtualized no shared operating system instance
Clear accountability platform and user responsibilities are defined separately
Isolation is not hands-off security

What a dedicated physical machine solves—and what remains yours to manage

When assessing security, consider hardware isolation, identity controls, workload management, and data governance separately. No single promise of “dedicated” replaces responsibility at the other layers.

Order-level physical isolation

Each active order maps to one dedicated physical Mac mini. Your workloads do not share an operating system instance, memory space, or local disk filesystem with other orders. This differs from shared computing environments where multiple tenants depend on isolation mechanisms on the same host.

  • The physical processor, memory, and device-local storage are dedicated to the order
  • A running device is never assigned to multiple orders at the same time
  • Configuration and delivery details can be verified against the order

Isolation cannot fix weak credentials

Shared administrator identities, reused private keys, credentials committed to repositories, and long-running remote sessions can all bypass the advantages of physical isolation. Users must actively reduce identity and permission exposure.

Isolation is not a backup plan

A dedicated local disk does not mean a second copy exists. Repositories, build artifacts, model files, and media assets should be stored in locations controlled by the user according to recovery goals, and verified before the order ends.

How to assess the boundary: If the risk comes from sharing computing resources with other tenants, a dedicated physical machine reduces that risk surface. If the risk comes from weak passwords, accidental deletion, malicious dependencies, excessive permissions, or unbacked-up data, it needs to be managed separately in the workflow.
Access control

Separate identities first, then grant only the access each task needs

A secure remote Mac should not rely on one administrator entry point shared by multiple people indefinitely. People, automation, and temporary troubleshooting should use separate identities and credentials with distinct lifecycles.

01 / IDENTITY

Give every operator individual credentials

Create distinct local identities for everyone who needs to log in instead of having people share an administrator account continuously. When someone leaves a project or changes responsibilities, revoke their access individually without replacing everyone’s credentials.

  • Separate human and automation identities
  • Set a clear end point for temporary troubleshooting access
  • Never send complete credentials through chat history
02 / KEYS

Generate a separate SSH key for each node

Do not copy the same private key across multiple projects and devices. Use keys scoped to a team, environment, or node, and protect private keys locally. If a key may be exposed, remove the corresponding public key immediately and issue a replacement.

  • Keep private keys only on controlled endpoints
  • Test a login once after changing a public key
  • Record the operator and completion time for each rotation
03 / PERMISSIONS

Do not grant standing administrator access

Routine code pulls, builds, and log reviews rarely require continuous administrator access. Elevate privileges temporarily only to install system tools or change protected settings, then review the scope of the changes.

  • Limit build services to the directories they need
  • Do not store long-lived privileged credentials in automation scripts
  • Record environment changes in the team’s runbook
Remote access protection

Turn first connection, daily sessions, and anomaly checks into repeatable steps

SSH and graphical connections serve different purposes, but both require verifying the target node, protecting credentials, actively ending sessions, and keeping enough evidence for investigation.

SSH ROUTE

Verify command-line access

  1. Verify the connection target

    Confirm the address, port, and username from the order delivery details. Do not use forwarding addresses from unknown sources.

  2. Verify the host fingerprint

    Before logging in for the first time or after a fingerprint changes, stop and recheck the delivery details. Never ignore a warning simply to continue connecting.

  3. Replace temporary credentials

    After first access, install your own public key, verify that a new session works, and remove temporary access that is no longer needed.

  4. Check for anomalies

    Look for unfamiliar sources, unusual times, and repeated failed attempts. If you see suspicious activity, restrict access first and save redacted evidence.

GRAPHICAL SESSION

Manage graphical sessions

  1. Keep credentials out of scripts and repositories

    Store graphical access credentials in a controlled local credential manager. Do not put them in project configuration, build logs, or shared documents.

  2. Clear sensitive content before screen sharing

    Before remote collaboration, close windows containing keys, certificates, payment information, or internal addresses. Show only what is needed to resolve the issue.

  3. Exit actively when the task is complete

    Closing an application window does not end a remote session. Sign out when finished and confirm that no temporary forwarding or background tools remain.

  4. Check the docs first when access fails

    Use the connection guide to check your local network, target address, port, fingerprint, and credential status, then submit redacted logs through the console.

View first-connection steps
Data lifecycle

Classify data before import and complete a verifiable export before the order ends

Data security does not begin when an order expires. Before using a node, define the data categories, recovery location, and person responsible for cleanup.

A

Before import

Sync only the repositories, dependencies, assets, and model files required for the task. Apply stricter access controls to keys, certificates, and production data, and do not copy your entire personal Downloads folder to the node.

Verification: the data on the node matches the task checklist.
B

During use

The user is responsible for directory permissions, version control, backups, and compliance for their work. Important artifacts should be synced to user-controlled storage rather than treated as having their only copy on the device.

Verification: critical code and artifacts have an independent recoverable copy.
C

Before expiry

Export repositories, build artifacts, logs, and necessary configuration. Verify file counts, checksums, or repository status, then remove keys, credentials, certificates, and temporary files that are no longer needed.

Verification: the new location is readable and sensitive access materials on the node have been revoked.
D

After the order ends

The node enters the service handling process and is no longer available to the original order. The platform handles device status according to the needs of delivery, security, and service operations. Users should not treat a device from an ended order as a data retention plan.

Verification: business recovery does not depend on the ended order.

Exit rule: export and verify first, then delete local copies; revoke access materials first, then close the responsible operator’s records. Do not confuse “copied” with “recovery verified.”

Network and logs

Keep operational records separate from user work

Support and security investigations require limited connection and service records, but these records should not be understood as routine review of user code, documents, or build content.

Boundaries for handling operational logs and user work
Information type Typical contents Purpose What users should do
Connection records Connection time, source information, target service, and result status Support connection troubleshooting, identify unusual attempts, and keep the service running Provide accurate timestamps when reporting an issue and redact source addresses as needed
Order and device status Order identifier, configuration, region, delivery status, and basic operating status Verify delivery, renewals, fault diagnosis, and the scope of security incidents Provide only the necessary order identifier; never send complete access credentials
Support communications Issue description, redacted logs, reproduction steps, and handling records Answer questions, track resolution, and avoid repeating investigations Remove private keys, access tokens, certificate contents, and unrelated personal information
User work Code, assets, models, project documentation, and build artifacts Managed by the user for their own workflow, not collected as routine operational logs Set permissions, backups, compliance scope, and exit cleanup rules yourself
Before submitting troubleshooting material: Keep commands, error codes, timestamps, and necessary context; remove private keys, complete credentials, certificate contents, access tokens, business data, and unrelated personal information.
Payment boundaries

Limited payment methods, with every order settled in USD

BookaMac supports only USDT-TRC20 and Visa / Mastercard / Amex (via Stripe), with all orders settled in USD. The checkout flow shows which gateways are actually available in real time.

Payment processing collects only the information needed to complete transactions, verify payment status, handle billing issues, and meet necessary security requirements. Payment credentials and the code, files, and build content on user nodes are handled separately.

USDT-TRC20

On-chain payment

Check the order amount, network, and recipient details before paying. A transaction ID can be used to verify status, but should not be sent together with node access credentials.

CARD / STRIPE

Card payment

Visa, Mastercard, and Amex are supported. The payment flow handles the transaction information required by the relevant process, and the console determines the order status.

Security incident response

Use evidence to move through five stages instead of making absolute claims too early

Unusual connections, exposed credentials, device status changes, or suspicious activity require confirming the scope of impact first. Unverified information will not be presented as an absolute security conclusion.

  1. 01

    Detect

    Record the time, order identifier, region, observed behavior, and minimum reproduction conditions. Keep the original logs after redacting sensitive information.

  2. 02

    Contain

    Based on the risk, revoke keys, end unusual sessions, restrict network access, or pause related automation to prevent further exposure.

  3. 03

    Investigate

    Review connection records, configuration changes, user actions, and service status along a timeline. Distinguish credential issues, workload issues, and platform issues.

  4. 04

    Remediate

    Replace affected credentials, correct configuration, remove unusual persistence, and verify the fix through a new connection or build task.

  5. 05

    Notify

    Once the facts are confirmed, provide the necessary explanation, actions taken, and next steps for users based on the scope of impact. Avoid spreading unverified assumptions.

Responsible disclosure

When reporting a vulnerability, provide reproducible evidence and keep testing contained

Security research and issue reports should minimize impact. Do not expand access, obtain unrelated data, or disclose an unresolved issue publicly.

A report ready for investigation should include

Affected target

The website page, order flow, connection method, or device function involved, along with the impact you can confirm.

Reproduction steps

The shortest path from initial conditions to the observed result, including necessary request order, inputs, and expected behavior.

Evidence and timing

Provide redacted screenshots, error messages, relevant timestamps, and environment details. Do not attach private keys or third-party data.

Contact window

State the email address, time zone, and times when you can receive follow-up questions so that verification details can be completed efficiently.

Prohibited testing activities

  • Accessing, downloading, modifying, or deleting data that is not yours
  • Obtaining other users’ credentials or expanding to unrelated orders
  • Interfering with the normal operation of nodes, networks, payments, or support
  • Obtaining personnel access through deception, impersonation, or inducement
  • Publishing exploitable details before remediation and communication are complete
Quick boundary check

Common security questions

Use these answers to decide what to do next. For a specific order, include the order identifier, region, timestamp, and redacted logs.

Does a dedicated physical machine mean access controls are unnecessary?

No. A dedicated physical machine reduces the scope of computing resources shared with other tenants, but it cannot prevent weak passwords, exposed private keys, excessive permissions, malicious dependencies, or accidental actions. Every operator should still use an individual identity and receive the minimum permissions required for the task.

What should I do first if I suspect an SSH key or remote access credential has been exposed?

Contain the impact first: revoke the relevant public key or replace the credential, end suspicious sessions, and stop using the related automation. Then record the time, source, order identifier, and actions taken, and submit redacted information through a console ticket.

What must be removed before submitting logs?

Remove private keys, complete passwords, access tokens, certificate contents, business data, and unrelated personal information. Keep commands, error codes, necessary paths, accurate timestamps, and the minimum context needed to explain the issue.

What is the most important data action before an order ends?

Export code, build artifacts, logs, and necessary configuration to a user-controlled location, then complete read, checksum, or recovery verification. After that, revoke keys, credentials, and certificates on the node before closing out order-related work.

Next step

Confirm the security boundary, then choose the physical Mac that fits your workflow

See the two available configurations, full pricing by billing period, and four regional options. For questions about an existing order, sign in to the console and submit a ticket.

View rental plans Open console