API Tokens
An API token lets the rux command line act on your registry account without a browser. Publishing
needs one; browsing and installing do not.
Creating a token
Sign in to the registry with GitHub, then open Dashboard → Tokens and create one. A token has:
- a display name, so you can tell your tokens apart later;
- one to three scopes; and
- an optional expiry — 30, 90, or 365 days, a date you choose, or never.
Scopes
A token carries only the permissions you give it. Choose the narrowest set that does the job.
| Scope | Allows |
|---|---|
publish | Publishing new package versions |
yank | Yanking and unyanking a version |
namespace | Managing namespaces, members, and invitations |
A token with the wrong scope is rejected with a clear error rather than partially succeeding. Scopes do
not grant namespace membership: a publish token can only publish into namespaces its owner already
belongs to.
Using a token
On your own machine, hand the token to rux login once and every later
rux publish picks it up:
rux login
You are prompted for the token, and your typing is not echoed. It is stored per registry in a file only
your account can read — %LOCALAPPDATA%\Rux\Credentials.toml on Windows, ~/.rux/credentials.toml
elsewhere — and rux logout removes it again.
There is deliberately no --token flag, and rux login reads the token from standard input rather
than an argument for the same reason: a credential on the command line ends up in shell history and in
the process list, where other users on the machine can read it.
In CI
Set RUX_TOKEN instead. It overrides any stored token, so a job is never shadowed by a file left behind
on a self-hosted runner.
export RUX_TOKEN='rux_pat_...'
rux publish
$env:RUX_TOKEN = 'rux_pat_...'
rux publish
Store the token as an encrypted secret and expose it as RUX_TOKEN for the publishing step only.
rux login to exporting RUX_TOKEN from your shell profile. An exported variable is inherited by
every process your shell starts and shows up in env dumps pasted into bug reports; the credentials
file is read by rux alone, and only when it publishes.Managing tokens
The tokens page lists every token you have created, newest first, including expired and revoked ones. It
shows each token's display name, prefix, scopes, creation time, last use, expiry, and status — active,
expired, or revoked. It never shows a credential again.
Revoke a token the moment you suspect it has leaked. Revocation takes effect immediately, and revoked
tokens stay in the list as history. Revoking is not the same as rux logout, which only
forgets the token on the machine you run it on — a leaked token has to be revoked here. Releases published with a revoked token are unaffected: publication
is permanent and independent of the credential that made it.
Deleting your account
Deleting your registry account revokes every session and token you hold and clears your GitHub identity. Packages you published stay published — see Yanking for what can and cannot be withdrawn.
Namespaces
A published package is identified by two parts: a namespace and a name. The namespace is the account or organisation that owns the package, so Rux/Io and Acme/Io are different packages that happen to share a name.
Publishing
Publishing uploads a package release to the registry, where anyone can depend on it. A published version is permanent.