Treat FASTLANE_PASSWORD, MATCH_PASSWORD, FASTLANE_SESSION and FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD as secrets. FASTLANE_USER is an account identifier, not a secret but still sensitive. The locale variables and the interactive 2FA flag are plain settings. Store the secrets in a secret manager and scope them to the jobs that need them.
What the CI page lists
The fastlane continuous integration guide names the variables most setups need:
| Variable | What it is | Treat as |
|---|---|---|
| FASTLANE_USER | Store account user | Sensitive identifier |
| FASTLANE_PASSWORD | Account password, used with the user | Secret |
| MATCH_PASSWORD | Password of the match encryption | Secret |
| FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD | App-specific password for uploading when 2FA is on | Secret |
| FASTLANE_SESSION | A pregenerated session from the spaceauth command when 2FA is on | Secret, regenerate when needed |
| LANG and LC_ALL | UTF-8 locale for the shell | Setting |
| SPACESHIP_ONLY_ALLOW_INTERACTIVE_2FA | Stops 2FA prompts in non-interactive mode | Setting |
The page says FASTLANE_PASSWORD is usually only needed if you also set the user variable. It also says many CI systems come with an unset or ASCII locale, which is why the locale variables matter.
Reduce how many you need
Each password variable is a reason for a credential to exist. The fastlane docs describe the App Store Connect API key path as avoiding 2FA, with better reliability. If your lanes support it, an API key replaces the user, password, session and app-specific password variables with a key file, key ID and issuer ID, and the key can be role-scoped. Our post on API key versus Apple ID compares them.
Scope them
- Define secrets at the narrowest level your CI allows, a single environment or job, not the whole organization.
- Do not export them in a step that also runs third-party code or scripts you did not write.
- Give the beta lane and the release lane different credentials where the platform allows.
- Keep MATCH_PASSWORD apart from the signing storage, since together they open the certificates.
- Never echo variables or print the environment for debugging.
Watch the logs
CI platforms redact exact matches of known secrets, but not transformed values. A hosted CI service's guidance says automatic redaction is not guaranteed because a secret can be transformed in several ways, and tells you to register generated sensitive values as secrets too. If a secret reaches a log, delete the log and rotate the secret. See our post on log masking limits.
Rotation checklist
| Event | Rotate |
|---|---|
| Someone with access leaves | All store credentials they could read |
| Suspected log leak | The leaked value, then delete the log |
| Quarterly review | MATCH_PASSWORD and keys, on your schedule |
| CI compromise | Everything the environment could reach |
Where Safeguard fits
Safeguard does not store these variables. It scans the dependencies of the code that uses them and enforces release policies. Try a free scan.
Quick check
Is FASTLANE_SESSION safe to keep for months?
No. It is a pregenerated session token, so regenerate it when it is exposed or stops working, and treat it like a password.
Can I put all of these in a plain config file?
No. Keep secrets in a secret manager and inject them at run time.
Sources
- fastlane docs: continuous integration
- fastlane docs: using the App Store Connect API
- GitHub Docs: secure use reference
Last reviewed: 19 October 2026.
