Automation tokens
For everyday development, use rvs auth login. The CLI stores your session in a secure credential store and supplies temporary credentials to package tools, so you do not need to handle an automation token.
Choose the right token
Section titled “Choose the right token”| Token | Who owns it | What it can access |
|---|---|---|
Personal-account PAT (rvs_ust…) |
You | Selected resources in your personal account |
Organization-account PAT (rvs_uot…) |
You | Selected resources in one organization, limited by your current membership access |
Organization automation token (rvs_oat…) |
The organization | Selected organization resources for CI or a secret manager |
A personal access token (PAT) always targets one account. Your personal-account PAT never gains organization access. Create a separate organization-account PAT for work you perform as an organization member. Removing that membership removes its access; organization-owned automation does not depend on its creator remaining a member.
Only organization administrators can create organization-owned automation tokens. Use those for shared builds and release jobs.
Create and restrict a token
Section titled “Create and restrict a token”- Open your personal-token settings and select the personal or organization account the token will access. For shared CI, open the organization’s automation-token settings instead.
- Give the token a name that identifies its purpose.
- Choose an account boundary or restrict the token permanently to one namespace.
- Select whole namespaces, individual repositories, or a combination. A whole-namespace selection includes future repositories there; selecting the whole account also includes future namespaces. An individual repository selection stays restricted to that repository.
- Choose Read, Publish, or Admin access. Read downloads packages; Publish also uploads them; Admin also manages repository configuration. Private mirrors offer Read or Admin.
- Copy the one-time secret into your approved secret manager.
Token grants never give a member access beyond their current namespace and repository permissions. Repository Admin does not grant account administration.
Use the token with rvs
Section titled “Use the token with rvs”Expose the secret to the CI job as RVS_TOKEN. rvs uses it to obtain temporary package credentials. A present RVS_TOKEN overrides the stored login session; an invalid or empty value fails instead of using that session.
Keep a separate token for each workflow so it can be restricted and revoked independently. Never commit or log a token, bake it into an image, or put it in a cache key.
Direct package-tool access
Section titled “Direct package-tool access”Prefer the rvs wrappers. Direct use of a PAT or organization automation token in a native registry is strongly discouraged and may be removed in the future. If a tool cannot run through rvs, generate a short-lived token and use it only for the required operation.
Direct use is enabled by default but can be disabled independently for personal-account PATs, organization-account PATs, and organization-owned automation. You control the personal-account setting; organization administrators control the two organization settings. Disabling direct use does not disable exchanging an otherwise authorized token through rvs.
Rotate or revoke
Section titled “Rotate or revoke”Rotation shows a new secret once and replaces the old secret. Update the secret manager promptly. To migrate jobs without an interruption, create a separate replacement token, move and test the jobs, then revoke the old token.
Access edits, rotation, and revocation invalidate existing derived credentials. Check the operation’s completion status before assuming cached access has stopped everywhere. Rotate or revoke credentials after suspected exposure.