Protect your project files
A dedicated physical Mac, not a virtual machine.
Bringing client projects, signing certificates, and build credentials to a Mac? Set access controls before uploading. Take your deliverables with you and remove credentials when the work is done.
Dedicated hardware doesn't replace project-level access controls. You’re still responsible for setting up certificates, backups, and team permissions.
Know your hardware boundary
Each physical Mac is assigned to one user. Its CPU and memory aren't shared with other users.
You get a dedicated physical Mac development workstation, not a virtual machine carved out of shared hardware. Your builds and local files stay on the Mac assigned to your rental.
This describes hardware allocation; it doesn't mean your code is automatically encrypted or backed up.
Restrict machine access to people authorized for the current project. For shared team use, manage macOS accounts and SSH public keys separately. Never share one private key among multiple people.
When someone leaves the project, remove their public key and check for any remaining active credentials.
Before uploading, confirm that the client allows project files and signing assets to be used in a remote environment. Transfer only what this build requires—don't copy archives or unrelated data from other clients.
Use support tickets to troubleshoot, not to store complete projects, private keys, or certificate passwords.
Secure your login
Verify these three things in order to avoid locking yourself out before confirming you can reconnect.
When you receive the connection details, verify the instance first, then set a unique password for your macOS account. Don't reuse a password from your code repository, email, or another project.
Share passwords through a secure method approved by your team. Don't include them in chat screenshots, build logs, or commit history.
Generate an SSH key on your own computer and add only the public key to the remote user's authorized keys. Keep the private key local and protect it with a passphrase.
Keep your current session open and use a second session to test key-based login. Once you can reconnect, adjust the existing authentication method.
You can use the graphical desktop to configure Xcode and signing. If you only run command-line builds, disable screen sharing when it's not needed to reduce remote access.
Before disabling it, make sure SSH works on its own. If you need graphical access again but can't connect, sign in to the console and submit a support ticket.
Manage signing assets separately
Flutter, React Native, and Unity use different build tools, but the same steps apply to handling certificates and private keys.
Import only the signing certificates and provisioning profiles required for the current project. Store certificates and their associated private keys in the macOS Keychain. Don't leave exported files containing private keys in your Downloads folder.
Protect exportable signing backups with a strong passphrase, and store the passphrase separately. Use signing assets only after confirming client authorization.
Exclude certificates, private keys, environment files, and temporary export directories from your repository.
Create dedicated credentials for automated builds and restrict them to the required projects and actions. Don't grant a build job lasting, full team access just to complete one Archive.
When injecting environment variables, avoid printing their values to logs. Before sharing troubleshooting screenshots, hide tokens, sensitive parts of connection addresses, and certificate passwords.
Log redaction and access controls are different safeguards. Check logs manually before uploading them.
First confirm that your signing backup works. Then remove unneeded certificates and associated private keys from Keychain, and delete temporary provisioning profiles, exported copies, and sensitive values in build scripts.
Check shell history, logs, temporary directories, and Trash. Revoke or rotate any tokens that were exposed or are no longer within their intended scope, using the issuing service.
Deleting a file doesn't revoke its credentials. Check both.
Keep a copy of your deliverables
If you don't renew, the Mac shuts down and its data is cleared according to the service terms. Take your work with you before your rental ends.
Check the latest project commits, build scripts, dependency lockfiles, Archive, .ipa, and any debug symbols you need to keep. Separately review any local changes that haven't been committed.
Files created only on the Mac aren't automatically backed up just because you've pushed your code.
Copy the backup off the Mac and check that files open, archives are complete, and encrypted backups can be unlocked. Save the relevant tool versions and build commands.
Don't delete the only remote copy just because the transfer shows as complete.
Check the expiry date in the console and review the data handling terms in the service agreement. Don't treat shutdown at expiry as storage, or count on being able to retrieve files afterward.
If you have questions about client handoff requirements or data deletion, ask through a support ticket before expiry. Don't assume there is an extra retention period.
Keep payment details separate
Only these two payment methods are supported, with charges in USD. Available payment gateways are shown in the console.
Visa, Mastercard, and Amex are accepted. We don't store card numbers. Never include a card photo, full card number, or security code in a support email.
For payment troubleshooting, you can provide the order number, billing status, and an error message with sensitive details redacted. Never share complete payment credentials.
Payment details and project files on your Mac are handled separately.
For on-chain payments, keep only the transaction hash. Before sending, verify the network and recipient details shown on the payment page. Transfers on other networks aren't treated as the same payment.
To check a payment, submit the order number and transaction hash. Support doesn't need your wallet's private key, recovery phrase, or signing authorization.
See the Privacy Policy for details on how order and support ticket information is handled.
Use this checklist
Complete each step before moving on. Disk encryption, project backups, and certificate handoff are separate safeguards.
Check FileVault status in System Settings. Before enabling it, confirm how to unlock and recover the Mac after a remote restart. Store the recovery key somewhere secure and off the Mac.
If you're unsure how remote unlocking works, check with support before enabling FileVault. Don't restart the Mac before handoff without testing the process.
Push code as the project progresses and save essential files outside the repository. Check your backups at least after important builds, when signing settings change, and before your rental ends.
Make sure your backups don't accidentally include private keys or plaintext tokens. Restrict access to backups, too.
Check that the certificate includes the associated private key needed for future signing. Export an encrypted backup as required by the project, then verify that it can be imported in a controlled environment.
Confirm the recipient and storage location before removing copies from the Mac. Don't let a client lose its only signing asset when your rental ends.
Set up access, backups, and certificate handoff before renting a cloud Mac.