Project tokens
The credential a publishing job presents, and where it belongs.
One token per publishing job
Publishing presents a bearer token to the endpoint you name. The token is read
from MOKLY_TOKEN or from --token, and it is sent in the request’s
Authorization header and nowhere else.
Where to keep it
Keep the token in your CI system’s secret storage and expose it to the job as an environment variable. Prefer the environment variable to the option: a command line ends up in shell history and in job logs, and an environment variable does not.
A token that begins with - needs the assigned form so it is not read as an
option:
npx mokly publish --token=-TOKENWhat the token controls
The service that receives the upload decides what a token may do. The upload names the repository, the branch and the revision it came from, and it is the receiver that checks whether that token is allowed to publish for that repository before it exposes anything.
Mokly never prints the token, including in error messages and diagnostics, and it never writes it into the export.
Rotating
Because the token lives only in your CI secrets, rotating it is a change in
one place. A rejected token fails the job with the upload-unauthorized
category rather than a partial publication.