You get a dedicated physical Mac mini, not a virtual machine. Its CPU, GPU, unified memory, and storage aren't shared with other tenants. Your team manages source code, certificates, and build artifacts according to its own policies.
Start by defining resource ownership, then set access permissions and plan for backups and offboarding.
Physical isolation prevents tenants from sharing machine resources. Within the operating system, your team still needs to manage permissions for users, processes, CI jobs, and secrets. Keep these two layers separate to make your security policies actionable.
Builds, simulators, and inference workloads run on a physical node assigned to you. Its compute resources aren't split with other tenants, and your workloads aren't constrained by virtual machine quotas.
Whole-machine allocationUnified memory and node storage belong to your environment for the duration of your rental. Project folders, DerivedData, keychains, and runner caches aren't shared workspaces accessible to other tenants.
Tenant isolationA dedicated machine doesn't mean everyone on your team should share admin credentials. Use separate system accounts for interactive development and automated builds, limit which directories runners can access, and don't expose production secrets to every build job.
Role-based accessTreat system resets, secure erasure, and business backups as three separate things. The first two establish tenant boundaries; backups ensure your projects and certificates are ready to use on another machine.
After a physical node is assigned, its system is reset to create a fresh rental environment. Once you receive the connection details, verify the instance ID and system version before importing code and certificates. Don't reuse shared passwords from another environment.
You can initiate a system reinstall from the console. A reinstall affects local files and development settings, so export anything you need to keep, stop running builds, and check that no team jobs depend on this node before you proceed.
Nodes are securely erased after a rental ends, before they enter the next provisioning process. Export your data before expiry; don't rely on keeping the disk or recovering files after your rental ends as a backup plan.
SSH, the graphical desktop, and the console are separate entry points. Manage their credentials separately and revoke each one when someone leaves, hands over work, or finishes a task. Don't use the same password across all of them.
Give each team member and automation job its own key. Verify the host fingerprint on first connection, review authorized keys after a handover, and remove the corresponding public key when revoking a team member's access.
Never commit private keys to a repository or include them in build logs.
Use a unique, strong password for the graphical desktop. For nodes that only run command-line builds, you can disable public VNC access. When graphical access is needed, configure the connection path for the use case.
After rotating a password, check for clients still using the old credentials.
Your console account controls your instances and billing. Follow the prompts for two-step verification at sign-in and during sensitive actions. Secure the email account that receives verification codes, and don't forward codes to other team members.
Use your own account for admin tasks; don't share sessions.
Don't let unreviewed external pull requests access signing keychains or publishing credentials. Separate test and release jobs, and expose only the secrets needed for release jobs on trusted branches.
Runner labels are scheduling criteria, not security controls.
All nodes operate year-round, 365 days a year. The uptime commitment covers service availability, not the success rate of a particular project's builds. It also doesn't guarantee the same connection speed over every network.
Monthly uptime commitment
99.9%
If monthly uptime falls below 99.9%, service credits are calculated as rental time based on the duration below the commitment.
These 13 time periods show the reporting range only; they don't indicate days with successful operation or outages. This page doesn't display unverified daily statuses or present the service commitment as measured results.
Open a support ticket in the console with your instance ID, the affected start and end times with time zone, connection method, and error details. Keep redacted logs to help verify the duration of any service outage.
Service issues are assessed separately from user actions, project failures, and force majeure events. Eligibility is determined under the Terms of Service; this reporting-range chart isn't used to calculate credits.
We accept only the two payment methods listed below, and all charges are settled in US dollars (USD). Available payment gateways are determined by the response from our backend. Check payment status in your console order history; email screenshots and browser messages aren't a substitute.
Card payments are processed by Stripe; MergeMac doesn't store card numbers. Pay through the order checkout, and never send a full card number, security code, or payment verification details by email or support ticket.
Processed by StripeTransfer funds using the network, address, and amount shown in your order. Once the on-chain transfer is confirmed, check your order status. For payment queries, provide your order ID and transaction hash—never your wallet's private key or recovery phrase.
Verify on-chain receiptSource code can be checked out again; secrets can't be recovered by guesswork. Document who can import signing materials, which jobs can unlock them, and when to revoke access. Don't wait until a node expires to discover that your certificates have no usable backup.
Create a separate keychain for CI signing and import only the certificates and private keys needed for the current project. Unlock it only when a build requires it, then lock it again when the job finishes. Don't give every interactive session access to release materials.
Store sensitive values in your CI platform's encrypted secret variables, scoped to protected branches or release environments. Disable debug commands that print secrets, and check logs for tokens, paths, and environment variables before sharing them.
Before your rental ends or you reinstall the system, export any signing materials you need to keep and encrypt them off-node. Once you've verified the backup, deregister runners and revoke tokens and connection keys you no longer use.
If you find exposed credentials, an unusual sign-in, or suspected unauthorised access, revoke the relevant keys and tokens first and restrict the affected entry point. Keep necessary logs, don't expand the scope of testing, and don't access or share other users' data.
For issues involving an existing order, contact us through the console first. Include your instance ID, the time and time zone, steps already taken to limit the impact, and the minimum steps needed to reproduce the issue.
Sign in and open a ticketEmail support@mergemac.com with “Security report” in the subject line. Start with a redacted summary. Don't attach certificate private keys, verification codes, full connection passwords, or wallet secrets.
Email security supportWe prioritise security reports based on risk and potential impact, and follow up through the original ticket or email thread. An initial reply doesn't mean the issue is resolved. Keep the same report thread and add new details there so the context stays together.
Your dedicated physical node isolates machine resources; your permissions, backups, and certificate processes protect your workloads. When you're ready, choose the rental term that fits your needs.