Documentation

Credentials and tokens

Choose Git credentials, SSH keys, API tokens, or CLI sessions for each client.

Upstream uses different credentials for Git transport and HTTP APIs. Use the narrowest credential that fits the client.

Git credentials

Repository-scoped HTTPS credentials can allow read or write. They expire, can be revoked, and are shown only once. Use them as the password with any non-empty Git username.

SSH keys

Account SSH keys authenticate Git remotes when SSH is available. Add and revoke keys in SSH key settings. Use HTTPS while the repository's Clone menu shows SSH as unavailable.

Personal access tokens

Personal access tokens call the REST API as you and also work as a Git HTTPS password. Each has scopes, an optional list of repositories and an expiration. The token is shown once and stored hashed. Create tokens in Tokens settings and read API authentication for the scopes.

Workspace keys

Workspace keys belong to a namespace instead of a person. They report external checks with the upstream.checks.write scope. Create them under Workspace keys in Tokens settings.

CLI sessions

The Upstream CLI uses a browser-approved session and the operating system credential store. Its Git credential helper requests short-lived repository credentials and clamps requested access to your actual repository role.

Automation guidance

  • Never place a user session cookie in a runner.
  • Use read-only repository credentials for checkout unless the job must push.
  • Give API tokens only the scopes the integration calls.
  • Rotate credentials when ownership or provider configuration changes.
  • Keep one credential per service and repository so revocation is precise.