Build across regions. Keep access accountable.

One machine. Clear ownership.

Your Mac mini is hosted in a data centre, while your team manages its code and signing assets. Each machine is rented to one customer—not shared as a virtual machine.

Run overnight Xcode builds on a physical node that's online year-round, while managing login keys, build credentials, and data exports as part of your team's workflow. Dedicated hardware isolates the machine; day-to-day access still needs clear ownership.

Rent by the day from $19.2/day. Before getting started, decide who owns the machine, who needs access, and how you'll export your data.

Isolation starts with the hardware

Your Mac isn't shared with other customers

A dedicated physical machine keeps customers separate at the device level. You don't share runtime resources on a host with other customers, and no one else shares the machine's storage.

One customer per machine

You get a physical Mac mini, not a virtual machine carved out of a host. Its chip, unified memory, and local storage are dedicated to your workloads for the duration of the rental.

Boundary: machines aren't shared between customers.

Storage isn't shared between customers

Repositories, DerivedData, dependency caches, and build artifacts can stay on the machine during your rental. Your team decides how to organise directories and who can read or write to them.

Boundary: your team still needs to set internal file permissions.

Team workloads still compete for resources

Dedicated doesn't mean every task gets its own resources. Multiple runners, simulators, and archive operations still share the machine's memory, CPU, and disk.

Tip: set build concurrency limits and queue tasks.

Make access ownership clear

Assign keys to people. Rotate desktop credentials.

Once you receive your SSH / VNC credentials, set your access rules before importing source code and signing materials. When teams in Asia-Pacific and North America take turns using a machine, don't rely on one long-lived password as your handover process.

  1. 01

    Use individual SSH keys

    Record a public key for each person who needs access; never share private keys in chat. Remove each person's access when they leave. Keep CI keys separate from keys used for personal interactive logins.

    Before disabling password login, keep your current session open and verify key-based access in a second session. This helps prevent locking your team out of the machine.

  2. 02

    Set your own VNC password

    Set a team-managed VNC password the first time you connect. Don't reuse your console password or repository credentials. Change it when team membership changes or credentials may have been exposed.

    Use the graphical interface for tasks that need human input; prefer SSH and runners for automated builds. When you're done at the desktop, sign out of sensitive tools and don't leave exported passwords visible.

  3. 03

    Enable only the services you need

    Review macOS sharing settings. Turn off file sharing, Remote Apple Events, and other services your project doesn't need. Keep only the remote login or screen-sharing access your team actually uses.

    Check dependencies before disabling services. Before changing firewall or remote access settings, record the current configuration and make sure your team still has a working way to manage the machine.

Handover means more than changing the machine password. Repository tokens, runner registrations, artifact repository credentials, and signing export passwords each have their own access controls. When someone leaves a project, review each one instead of only changing the VNC password.

Track signing assets by project

Keep certificates, private keys, and build logs separate

Certificates can be copied, but that doesn't mean every build task should be able to access them. Treat signing materials as separate assets: decide who imports them, which keychain they're used in, and when they'll be revoked or rotated.

Certificates and provisioning profiles

Store certificates, their corresponding private keys, and provisioning profiles by project. Before importing, check the purpose, expiry date, and target. Never commit an export containing a private key to a code repository.

If you need a backup, use a password-protected export and share its password through a separate channel. Keep backup copies somewhere managed by your team—not only on the build machine.

Track: project, purpose, owner, expiry date.

A dedicated build keychain

Consider keeping CI signing identities in a dedicated keychain, separate from those used for day-to-day work. Configure unlock and access permissions for the build's actual needs; don't give every process access to private keys just for convenience.

If an automated task needs to unlock the keychain, read the password from a protected CI variable. Verify signing with a controlled build before expanding the runner's scope.

Track: keychain, calling task, unlock method.

Limit access to logs and artifacts

Don't print passwords, tokens, or signing export passwords in scripts. When troubleshooting, disable verbose command output for sensitive steps and check logs for credentials before uploading them.

Set storage locations and retention rules for archives, export packages, and debug symbols separately. A completed build doesn't mean your assets are backed up. Verify that you can retrieve the required artifacts from team storage at least once.

Track: artifact location, authorised members, retention rules.

Verify the signing identity before triggering a release build

Run this read-only check as the target build user to confirm that the expected code-signing identity is in the keychain. Use the output for local verification; don't paste your full environment details into a public record.

security find-identity -v -p codesigning

This command only lists identities. It won't import certificates or configure keychain access for you.

The data centre and your team each have a role

We handle power. Your team manages the build environment.

All nodes operate continuously throughout the year, 365 days a year. The data centre handles power, networking, and cooling, so overnight pipelines no longer depend on whether the Mac in your office is switched on.

Infrastructure hosting doesn't replace application-level access controls or backup management
Area Data centre and platform Your team
Physical operation Hosts the machine and provides power, networking, and cooling. Match each instance to its project and record who owns the machine.
System access Provides machine login details through the console. Set up SSH keys, a VNC password, and member access.
Build environment Provides a dedicated physical Mac for remote use. Manage the Xcode toolchain, runners, dependencies, and build concurrency.
Project assets Erases the machine before assigning it to another customer at the end of the rental. Back up code and signing assets, export artifacts, and revoke external access.

Year-round availability describes how the nodes are operated; it doesn't guarantee that every build will succeed. Script errors, expired certificates, full disks, or changes your team makes to system settings still need to be monitored and handled as part of your project workflow.

Complete the handover before your rental ends

Take your assets with you before returning the machine

At the end of the rental, the machine is erased before being assigned to another customer. Erasure clears data from the device, but doesn't revoke access in your repository, CI platform, or other systems. Take care of both separately.

  1. 01

    Export and verify your backups

    Retrieve any unpushed code, build scripts, archives, export packages, debug symbols, and signing materials you need. Check that the files are complete and that your team can access them elsewhere; don't stop at confirming the copy finished.

  2. 02

    Revoke access to external systems

    Remove the relevant runner from your CI platform and revoke deployment keys and access tokens you no longer use. Rotate any shared secrets according to your team's policy. Erasing files from the machine doesn't stop external systems from trusting old credentials.

  3. 03

    Confirm your rental end date

    Check your rental period and instance details in the console. If you need to coordinate the order of data exports or confirm how data will be handled, submit a support request in advance. Don't rely on an expired machine for backups or wait until the rental ends to look for your only copy.

Payment information is handled separately

We don't store card numbers; keep only necessary payment records

All payments are settled in US dollars (USD). We support USDT-TRC20 and Visa / Mastercard / Amex (via Stripe) only. Available payment gateways are confirmed by the backend at checkout.

Card payments are processed by Stripe

Stripe processes card payment details; we don't store card numbers. If you need help with a payment, provide your order number and payment result. Never send a full card number, security code, or card photo through a support request or email.

Share your order details with support, never your card secrets.

Reconcile USDT-TRC20 payments on-chain

Before paying, check the network, receiving address, and amount shown on the page. Payments are reconciled against on-chain records. If there's a confirmation issue, provide your order number and transaction hash—never your wallet's private key or recovery details.

Keep the transaction hash and check payment status against your order.

Send security reports, payment queries, and data handling questions to support@pushmac.com, or sign in to the console to submit a support request. Include your instance ID, node location, relevant actions, and the time the issue occurred, including the time zone. Remove secrets from logs before sharing them.

Leave the build machine to the data centre

Your own dedicated machine, online year-round, 365 days a year. Assign an access owner, then connect your Xcode builds to your team's pipeline.