NoMacKeep your Apple signing secrets safe on a rented Mac
What to send to a cloud Mac for signing, what never to send, and why a VM that is deleted on stop changes the risk. Certificates, API keys and keychains.
· 8 min read
Need a Mac for this? NoMac gives your agent full macOS with Xcode for $0.90 an hour, billed per minute. Start now →
Signing an iOS or Mac app means putting secrets on the machine that signs it: a private key, a certificate, sometimes an App Store Connect API key. On your own Mac that is routine. On a machine you rent, and especially one an AI agent drives, it deserves a minute of thought. This guide covers what to send, what never to send, and how the kind of Mac you rent changes the risk.
Three rules: send the narrowest credential that does the job, send it only for the step that needs it, and prefer machines that are destroyed afterwards.
What each secret is and what it can do
| Secret | What it allows | If it leaks |
|---|---|---|
| Apple ID password | Everything on your account | Never send it. Use an API key instead. |
| App Store Connect API key (.p8) | API actions at the key's role | Revoke it in App Store Connect; issue a new one |
| Distribution certificate and key (.p12) | Signing apps as your team | Revoke the certificate; re-sign future builds |
| Developer ID certificate (.p12) | Signing Mac apps outside the store | Revoke it; Apple can also revoke notarization trust |
| Provisioning profile | Nothing alone; it is not secret | Low risk |
| Repository token | Reading or writing your code | Revoke it in your Git host |
What never goes on a rented Mac
- ·Your Apple ID password or a session cookie. Nothing in a build pipeline needs them. Automatic signing that asks you to log in to Xcode is the wrong tool on a remote machine.
- ·An Admin-role API key when App Manager or Developer will do. Create a key per purpose. See the App Store Connect API key, explained.
- ·Long-lived tokens with broad scope. Use short-lived, single-repository, read-only tokens to clone.
Dedicated vs disposable Macs
On a dedicated Mac you keep
A certificate imported into the login keychain stays there until someone deletes it. So does an API key in a download folder, and so does a token in shell history. Over months, a long-lived machine accumulates credentials. If you rent one, create a separate keychain for signing, delete it after each release, and keep a list of what you put there.
On a disposable VM
On NoMac, each session is a fresh VM, and stopping it deletes the VM and anything your agent installed or received outside ~/drive. A certificate sent for one release does not survive into the next session. That does not make it free to be careless, since the secret still existed on a remote machine for a while, but it bounds the exposure to the length of the session. The one exception is the account's drive at ~/drive, which is kept between sessions on purpose, for projects and caches. Keep keys and certificates out of it.
A safe signing flow on a session
Since CLI 0.22.0, nomac sync keeps secrets on your computer: .env files, .p8 and .p12 files, keystores and private keys stay behind, and each sync names what it kept. What it sends goes to ~/drive/src, which outlives the session, so a key you bring back with a ! line in .nomacignore stays there too. Send signing material on purpose, for one step:
# 1. Build and test first, with no secrets on the Mac nomac sync . nomac ssh -- xcodebuild -scheme MyApp -destination 'generic/platform=iOS' \ CODE_SIGNING_ALLOWED=NO build # 2. Only when releasing: open a shell and use a throwaway keychain nomac ssh read -s KC_PASS; read -s P12_PASS # typed, not logged security create-keychain -p "$KC_PASS" build.keychain security unlock-keychain -p "$KC_PASS" build.keychain security list-keychains -d user -s build.keychain login.keychain security import dist.p12 -k build.keychain -P "$P12_PASS" -T /usr/bin/codesign security set-key-partition-list -S apple-tool:,apple: -s -k "$KC_PASS" build.keychain # 3. Archive, export, upload # 4. Delete the keychain and the .p12, leave the shell, stop the Mac security delete-keychain build.keychain && rm dist.p12 exit nomac stop --json
Copy the .p12 over the session's SSH connection with scp or rsync immediately before step 2 (the CLI reference covers native SSH). Type passwords at a prompt rather than putting them in commands an agent logs, and do not paste them into chat with the agent.
Rules for agents
Put these in your AGENTS.md or CLAUDE.md:
- Never ask for or use my Apple ID password. - Do not copy signing certificates or API keys to a remote Mac unless I ask for a release. - When you do: separate keychain, delete it after, stop the session, confirm cleanup. - Never print secrets, write them to files in the repo, or include them in support reports.
Or keep the API key off the Mac entirely
If what you want is “signed build on TestFlight,” you do not need to send the API key at all. Connect an App Store Connect team key once at nomac.app/dash/apple: it stays on NoMac's server and never reaches a Mac or the chat. set_up_signing (CLI: nomac sign) then registers the bundle IDs, makes the App Store profiles and installs them with the account's distribution certificate in a keychain on the Mac, and send_to_testflight uploads the signed build. Other values go through request_secret, a one-use link where you type them, never the chat. See iOS code signing without a Mac. Use the manual flow above when you need control over the signing step.