Access tokens
Scoped, revocable tokens for CI and scripts.
Creating a token
Create tokens under Settings → Connections → API tokens. Give the token a name, choose its scopes, and set an expiry of 30 days, 90 days, a year, or never. You must be signed in and enter your password again. Another token cannot create one.
The token is shown once. Provisore stores only a hash, so it cannot show it again. If you lose it, create a new one. The list shows a masked identifier for each token, the same one the audit log records.
Scopes
servers:read · servers:write
registration, provisioning, reboot, tags, config files
sites:read · sites:write
sites, aliases, forced HTTPS, maintenance, redirects, certificates
deployments:read · deployments:write
deploy, roll back, and the site's deploy script
operations:read · operations:write
databases, daemons, cron, firewall, commands, recipes, backups
observability:read · observability:write
metrics, logs, jobs, alerts, monitors, channels, audit entries
secrets:read · secrets:write
environment files, database passwords, deploy-hook tokens, SSH keys;
write also runs anything as the provisore account
account:read
the team record and integration status- Write includes read in the same area. A token that can create a deployment can also list deployments.
- Secrets stand apart. No other scope grants secrets:read, including secrets:write. A token can ship a new environment file without reading the current one, and a CI token can deploy without reading the environment at all.
What a token cannot do
- Manage tokens, change a password, enrol or disable two-factor authentication, or access billing. These need a signed-in session.
- Change team membership or roles.
- Run a command or recipe as root.
- Run anything as the provisore account without secrets:write. That account can use sudo, so commands and recipes run as it, and daemons and cron entries that run as it, need the scope.
- Act on another team. A token belongs to the team it was created in.
- Exceed its owner's role. If the owner is demoted, their tokens drop to the new role on the next request. If the owner leaves the team, the tokens stop working.
Using and revoking a token
curl https://provisore.com/v1/servers -H "Authorization: Bearer pvs_…"Revoking takes effect on the token's next request. Revoked tokens stay in the list, marked revoked. The audit log records requests made with a token, including denied ones. Signing out, changing your password and resetting it leave tokens working.
A deploy pipeline needs deployments:write to deploy, sites:read to find the site by its domain, and observability:read to follow the job. A team pin in .provisore.yml adds account:read. If it also updates the environment file, add secrets:write, not secrets:read.