Four providers, one flow
GitHub, GitLab, Azure DevOps and Bitbucket. Same command, same configuration, wherever your skills repo lives.
Git providers
Your skills, where your code already lives
The same flow whatever your Git host. STH talks directly to provider APIs — no proxy, no third party between you and your code.
$ sth init ? Provider › GitHub GitLab Azure DevOps Bitbucket STH Cloud # Aucun secret stocké : token résolu via $STH_TOKEN, OIDC ou git credential
What you can do
Zero stored secrets
STH persists no keys. Tokens are read from your environment variables, just like git or gh.
Cascading credential chain
Inline token, STH Cloud keychain, STH_TOKEN, GitHub Actions OIDC, provider-specific variables, git credential fill, then an interactive prompt — in that order.
Multiple providers in parallel
A GitHub PAT for client A, a GitLab PAT for client B: each project keeps its own configuration.
Frequently asked questions
- Does STH store my tokens?
- No. Credentials are resolved per request from the environment, keychain or git, and never written to the project config.
- What's the minimum token permission?
- Read access to the repository: Contents: Read (GitHub), read_repository (GitLab), Code (Read) (Azure DevOps) or Repositories: Read (Bitbucket).
- Does STH work in CI?
- Yes. In CI, STH reads STH_TOKEN or GitHub Actions OIDC, with no interactive prompt.