Atlas credentials

A credential gives Atlas the access it needs to read a private source. Public repositories need no credential; everything else does.

The two kinds

Kind	What you provide
git	An access token (e.g. a GitHub PAT with classic `repo` scope, or a fine-grained read-only token), plus a username on hosts that need one — see below.
jira	Your Jira account email, an API token, and the Jira base URL (e.g. `https://your-org.atlassian.net`).

The git username

Git authenticates as username:token. On GitHub and GitLab, leave the username blank — tela fills in the right one (x-access-token and oauth2).

For other hosts, set it yourself. Bitbucket uses x-token-auth; a self-hosted GitLab wants oauth2; some servers want your actual login.

When a source stops updating

[!IMPORTANT] The most common cause is an expired token. Fine-grained GitHub tokens in particular default to a short expiry, so a source that worked for weeks can stop on its own with nothing having changed.

Check the source's error in the Atlas UI:

Error	What it means
`Invalid username or token`	The token is expired, revoked, or lacks access. Create a new one and re-add the credential.
`Write access to repository not granted` / `403`	The token is valid but not scoped for this repository. Widen its repository access; no need to replace it.
`could not read Username`	No credential is bound to the source at all. Bind one.
`could not read Password`	An older tela build's way of reporting a rejected token. Upgrade; it now reports the first message instead.

Ownership

A credential belongs either to you (personal) or to an org:

Personal credentials are visible and usable only by you.
Org credentials are visible to org admins, forming a reusable pool for that org's projects.

The token value is write-only

[!IMPORTANT] Once you save a credential, its token value is never shown again — not in the list, not when you edit it. Others ever only see a credential's name, never its value.

Tokens are encrypted at rest, and Atlas never writes one into a generated page, a log, or a run's events.

There is no way to edit a credential in place: to change a token or a username, delete it and create a new one, then re-bind it to its source.

Lending a personal token to an org project

You can bind a personal credential to an org project's source without that token entering the org's reusable credential pool. This lets an org project use your private access while keeping the token yours.

Other org admins can run the project — a run uses the token to clone or fetch — but they cannot see its value or reuse it on other sources.
On an org project, a bound personal credential is flagged "personal — private to you".

[!WARNING] Anyone who can run a project can use whatever credential it's bound to. If you want a token that only you can use, keep the project personal rather than binding the token to an org project.

[[Atlas projects & sources]] — where a credential gets bound to a source.
[[API & personal access tokens]] — tela's own PATs (a different thing from the source credentials here).