Security & Credentials

ShipItSwifty handles the most sensitive material in your release pipeline — App Store Connect keys, signing certificates, and Google Play service accounts. This page explains exactly where each secret lives, how it is protected, and how to wire credentials up safely. Nothing here requires trust in a third party: the CLI runs entirely on your machine and collects zero telemetry.

Security principles

• Never log secrets — the logger automatically redacts any value from environment variables matching *KEY*, *SECRET*, *TOKEN*, or *PASSWORD*, so secrets cannot leak into CI logs.
• Temporary keychains — CI runs create an ephemeral keychain scoped to the process and destroy it afterwards (shipit sign sync --ci / shipit sign cleanup).
• Minimal token scope — App Store Connect JWTs use a scope claim that limits the API surface per operation.
• Short token lifetime — JWTs expire after 15 minutes by default and auto-refresh.
• Encrypted at rest — the certificate vault uses AES-256-GCM with a key derived from your team passphrase via scrypt (N=2¹⁷, r=8, p=1) and a random per-file salt.
• No telemetry — ShipItSwifty collects zero usage data and never phones home.

Where each secret lives

Threat model

The encrypted certificate vault

Certificates and provisioning profiles are stored encrypted in a shared Git repository, so your whole team signs with the same assets. The AES-256 key is derived from the VAULT_PASSWORD passphrase — only teammates who know the passphrase can decrypt anything.

# One-time setup: create the encrypted cert repository
shipit sign init
 
# On each machine / CI run: fetch and install signing assets
shipit sign sync --ci
 
# After a CI run: remove the temporary keychain
shipit sign cleanup

App Store Connect credentials (iOS)

Only Apple-backed commands need these: upload, testflight, metadata, and provision. Local commands like build, test, archive, and export work without them.

Note: team_id and ASC_ISSUER_ID are different values. If shipit generate or Xcode already resolves the correct team, you usually don't need to set team_id at all.

Local development:

export ASC_KEY_ID=XXXXXXXXXX
export ASC_ISSUER_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
export ASC_PRIVATE_KEY_PATH=./.secrets/AuthKey_XXXXXXXXXX.p8

CI (store these as encrypted secrets, never in the repo):

env:
  ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }}
  ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
  ASC_PRIVATE_KEY: ${{ secrets.ASC_PRIVATE_KEY }} # raw .p8 contents

Google Play credentials (Android)

shipit play-store authenticates with a Google Cloud service account that has Play Console permissions.

Setup flow:

1. Open the Google Cloud Console and create or select a project.
2. Enable the Google Play Developer API.
3. Create a service account and download a JSON key for it.
4. In Play Console → Users and permissions, invite the service account's email address.
5. Under App permissions, add your app and grant release permissions for the tracks you use (internal, alpha, beta, or production).

Important: Only the Play Console account owner can invite users — admin access is not enough.

Troubleshooting 403 PERMISSION_DENIED

1. Check app-level permissions — the service account needs permissions for your specific app under the App permissions tab; account-level permissions alone are not enough.
2. Verify the API is enabled in the same Cloud project that owns the service account.
3. Confirm the correct key — the client_email in your JSON key must match the email invited in Play Console.
4. Wait for propagation — permission changes can take a few minutes.

Verifying your setup

# Print every resolved credential source (values are redacted)
shipit env
 
# Check for expired certificates, missing keys, and common misconfigurations
shipit doctor

Related pages

• CI Setup — wiring these secrets into GitHub Actions, Bitrise, and self-hosted runners
• Configuration Reference — every Shipfile.yml key
• iOS Quickstart and Android Quickstart