cargo login stores your crates.io token in credentials.toml inside CARGO_HOME, by default $HOME/.cargo. Treat the file as a secret. In CI, pass the token through an environment variable from your secret store, and revoke the token at once if it leaks.
Where tokens live
| Item | Detail |
|---|---|
| File | $CARGO_HOME/credentials.toml, written by cargo login and cleaned by cargo logout |
| Default location | $HOME/.cargo on Unix, %USERPROFILE%\.cargo on Windows |
| crates.io token section | The registry table with a token key |
| Other registries | A named table per registry, each with its own token |
| Environment variable for crates.io | CARGO_REGISTRY_TOKEN |
| Environment for others | CARGO_REGISTRIES_NAME_TOKEN, with the name in uppercase |
The configuration reference says a registry token should appear only in the credentials file, not in the normal config file that people commit.
Why it matters
A publish token lets whoever holds it release new versions of your crates. Every project that depends on you then pulls what they publish. That makes a token an entry point into your users' builds.
Protecting it on a laptop
- Create the token on the crates.io settings page and copy it once. It is not shown again.
- Run the login command and paste it.
- Restrict file permissions on the credentials file so only your account can read it.
- Keep
CARGO_HOMEout of any backup or sync folder that others can see. - Run
cargo logouton machines you no longer use for publishing.
Protecting it in CI
- Store the token in your secret manager, and inject it as the environment variable only in the publish job.
- Do not echo environment variables in logs.
- Limit which branches or tags can reach the publish job.
- Avoid putting a token in a repository config file, a Dockerfile or a build argument.
- Prefer short lived credentials where your setup offers them. See crates.io trusted publishing for that route.
After a leak
- Revoke the token on the settings page immediately.
- Create a new one and replace it where used.
- Review recent versions and owners of your crates for anything you did not publish.
- Check CI logs and image layers where the token may have been printed.
- If a malicious version was published, yank it and notify users. Remember yanking does not delete code.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing monitoring surfaces a change you did not make.
Quick check
Can I put the token in Cargo.toml?
No. Never put secrets in a manifest. Use the credentials file or an environment variable.
Does revoking a token undo versions it published?
No. It stops future publishes. You still need to yank bad versions and tell users.
Safeguard compliance and evidence automation can help record how publishing credentials are managed, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
