OSXBuild Cloud Mac Build Farm provides a dedicated physical Mac, not a virtual machine. CPU, memory, and storage aren't shared with other customers. You control where signing certificates, source code, and build artifacts are stored, who can access them, and how they're exported.
Confirm how isolation works before configuring signing and access permissions. Never include private keys or passwords in support tickets.
You get a dedicated physical node—not a slot on a shared host. For the duration of your rental, the entire Mac mini runs your workloads.
No other customer runs build, test, or inference workloads on your machine. Your build processes use its resources without competing with other customers for CPU or memory.
Your runner and build scripts determine how many jobs run in parallel on the node.
Your source code, DerivedData, dependency caches, and exported IPAs are stored on your node. Another customer's jobs won't overwrite them, and you don't need to hand signing files to a shared build queue.
A cache isn't a backup. Keep separate copies of important artifacts and recovery materials.
A dedicated machine isolates your resources from other customers. Manage team permissions by project, use dedicated accounts and keys for routine builds, and never put admin credentials in your pipeline.
You have full access to the macOS GUI and command line; you configure the access scope.
Code and build artifacts on the machine belong to you. We don't access this business content. When asking for help with an issue, share only the necessary error snippets, and remove tokens, signing materials, and project secrets first.
Your working directory isn't handed directly to the next customer. Reclaiming a node includes secure disk erasure and a fresh system installation.
Before your rental ends, export any source code, IPAs, configuration, and signing recovery materials you need to keep. Check that the files can be opened in another environment—don't just confirm that the copy command ran.
After your rental ends and the node is reclaimed, its disk is securely erased. Reclaiming isn't an archiving service, so don't rely on being able to retrieve files after the rental expires.
The node is redeployed only after the system has been reinstalled. Your project directories, build caches, and signing assets aren't kept as part of the next customer's initial setup.
Add backup checks to your project handoff checklist. Revoke repository access, runner registrations, and distribution tokens the node no longer needs. Erasing the local disk doesn't revoke active permissions in external systems.
Give build jobs only the permissions they need to complete a release. These three steps are more effective than hiding files in an obscure directory.
Create a dedicated Keychain for the build account. Unlock it only for signing, then lock it again when the pipeline finishes. Clean up on failure too, so an unexpected exit doesn't leave the Keychain unlocked.
Read the unlock password from a controlled secrets store; don't expose it as a command-line argument.
When uploading artifacts to App Store Connect, use an API key scoped to the task instead of storing an account password in automation scripts. Keep the key file separate from project code, and update your build configuration when rotating it.
Never put key contents in logs, build artifacts, or error screenshots.
Never commit a .p12 file containing a private key or store its export password in the same repository. With Fastlane match, manage encrypted materials and decryption credentials separately, and restrict access to the signing repository.
If a file is committed by mistake, assess whether to revoke and rotate the credentials. Deleting the current file doesn't remove it from the repository history.
This command uses an example Keychain path. Replace it with the actual name, and add the same cleanup action to your pipeline's finalization step.
security lock-keychain "$HOME/Library/Keychains/build.keychain-db"Console credentials and node login keys serve different purposes. Don't reuse them or give either to a task that doesn't need that access.
Set a unique console password and secure the email account used for login and verification messages. Sign in only on trusted devices, and never enter credentials on a page someone else has forwarded to you.
Check delivery details, order status, and related activity in the console. If you spot an unexpected change, note the order number and time, then open a support ticket. Never include full credentials in your message.
Use an SSH public key to sign in, and keep the private key on a controlled local device or in your CI secrets store. Use a separate key for each team member and pipeline so you can revoke them individually; don't share an untraceable private key.
Confirm the key works and keep a recovery access method before changing password login or port settings. Remove access promptly when a team member leaves or a runner is retired.
Associate each release with a commit, pipeline run, and artifact version, and restrict access to build logs. When requesting support, include the time of the error and relevant log excerpts. Remove environment variables, access tokens, and repository URLs containing credentials.
All orders are billed in US dollars (USD). Only the two payment methods below are supported. Actual availability depends on the gateway returned by the backend.
Credit card payments are processed by Stripe. OSXBuild doesn't store card numbers. Order records retain the payment status needed for fulfillment and reconciliation; card numbers aren't collected for technical support.
For payment issues, provide the order number, payment time, and any error shown on the page.
Use only the payment details shown on the live checkout page. Check the network, amount, and recipient details before sending. Don't use an address from an old screenshot or someone else's email instead of the current order page.
For help reconciling a payment, provide the transaction ID—not your wallet's private key or recovery materials.
Check invoices, renewals, and payment status in the console. Never share your full card number, card security code, or private key with anyone claiming they need it to investigate a payment.
Submit security reports, access issues, and suspected credential leaks through the support email or a ticket in the signed-in console. There is no separate security reporting email address.
If you haven't placed an order or can't sign in, email support. For an existing order, submit a ticket so we can link it to the node and delivery details.
support@osxbuild.com
If you suspect a key has been exposed, revoke its permissions and rotate the credentials before submitting a report. Test only resources you're authorized to access. Don't access other customers' data or run destructive tests.
Get a dedicated node and manage your own signing assets. Choose your configuration, then build key management, backups, and reclaim checks into your workflow.